Monthly Archives: June 2014

CTO Rules for software product development teams

Software product teams that work well can be amazingly productive. The following rules have helped me grow high performance teams – most of the time they are all appropriate.

1 – Building the right thing is more important than building things well – but building things well is also important.

2 – Customers almost always ask for incremental improvements to what already exists. Your job is to figure out what will wow them – what they didn’t even know they wanted.

3 – Every team member should be able to do a reasonable demo of their product. This tends to get engineers more involved in design from the end users/business perspective.

4 – Product release cycle time <= 90 days. Faster is generally better. Software product development is an attempt to predict the future. The quicker to market, the shorter timeframe you have to predict.

4a – Products/projects going more than 1 year without a release have a dramatically higher probability of cancelation – total waste. Release often so you can learn/re-vector faster.

5 – Talent, not resources. Resources are things like servers, software, networks and money. People are different – they can figure out how to solve problems and do things better. That is talent at work. Instead of a project resource plan, build a talent plan.

6 – Every team member is treated with respect. We tend to attract folks to product development that are, shall we say, socially challenged. However, these socially challenged engineers tend to be really good at things that are difficult to get done. Keep them focused, and make them feel like valuable team members.

7 – Engineers get the best gear. Things like laptops/tablets/software/phones have become status symbols in many organizations – executives get the best gear. If you want better team productivity, then engineers get the best gear.

8 – Most decisions should be made by teams – not dictated by the CTO, except for the rare occasions when it really matters that the CTO should override the team. There are usually a number a ways to get something done. Let the teams be creative where your standards allow.

9 – Team roles are defined out of necessity, but every team member is responsible for their total product – its never not my job.

10 – Automation often improves team throughput more than adding team members. Make sure you spend enough time and money on speeding up the team.