#TheFTAs Sir Clive Woodward: ‘Who wins in IT, wins’.
Categories
Author: Aleks Kudic
If analysis is important, do it all the time. If design is important, do it all the time. If implementation is important, do it all the time. If testing is important, do it all the time. If communication is important, do it all the time.
At Apple “design is part of every conversation”.
Categories
Loser’s Game Programming
Tennis pros win based on the positive actions they take: unreturnable shots down the baseline, passing shots, service aces, and so on. We (beginners) try to emulate our heroes and fail… We hit our deep shots just beyond the baseline, our passing shots just wide of the sideline, and our killer serves into the net. It turns out that mediocre players win based on the errors they don’t make. They keep the ball in play, and eventually their opponents make a mistake and lose the point.
Tennis pros are playing a Winner’s Game, and average players are playing a Loser’s Game. These are fundamentally different games, which reward different mindsets and different strategies.
The smart novice programers play a Loser’s Game, where the greatest reward comes to those who make the fewest and smallest mistakes. That’s not very exciting but works.
What is the best way to succeed? As in all Loser’s Games, the key is to make fewer mistakes: follow examples closely, pay careful attention to syntactic details, and otherwise not stray too far from what you are reading about and using in class. Another path to success is to make the mistakes smaller and less intimidating: take small steps, test the code frequently, and grow solutions rather than write them all at once. It is no accident that the latter sounds like XP and other agile methods; they help to guard us from the Loser’s Game and enable us to make better moves. Search Eugene Wallingford for more info.
My interview for LinkedIn Pulse with Frederique Prevost.
Use Kaseya to manage internal IT (asset management, IT config management, for example).
Most IS best-practices advocate a separation of concerns between management and direction. The IS team are responsible for managing and auditing compliance with IS policy. The Risk Committee are responsible for providing direction to the management of information risk within the business. While the Head of Information Security, heads and owns all IS related policies/tasks reporting into the CTO. The CTO is ultimately responsible for the information security.
How do you aligned your remote and in-house dev teams? Alignment the lowest level (at the code or module level) lets you test and learn quickly what works and what needs attention. The CTO defines who owns what code based on the modules that a given location creates or maintains. Overtime the remote and in-house dev teams alignment needs to be assessed and if necessary further optimised using other remote working alignment models (delivery date, architecture or API, for example).
TeamViewer is super useful when reviewing / running / debugging code with a remote dev. Use it.
To be in control is being able to influence outcomes well in advance making the end result predictable. Not being 100% of the time in control is one of the realities of the modern CTO.
Sometimes you will be faced with issues that are outside of your control (migrating a live service which 1000s of customers use from an old supplier to the new one, for example).
A way to mitigate the unknowns is to map out outcomes and plan of action for each. At minimum set up a reliable support network (develop relationships with supliers, say). You can always scream later.
Working with designers producing Photoshop psd files but don’t want to own Photoshop? Open psd files in paint.net with PSDPlugin.