I was chatting to my good friend Jamie O’Shaunessey about start ups and enterprises. I explained the 20 – 20 – 20 rule* that the american army use as a strategy for any engagement. The rules are…
1. Within twenty hours, they will have special forces on site to provide recon and intel.
2. Within twenty days, they will have the navy and marines on site to control strategic positions.
3. Within twenty weeks, they will have had the whole army on site if necessary.
The key point is what are you optimising for? Initially, you want to optimise for speed. Hang the cost, hang the risk, just get eyes on site. Then, you want to optimise for risk. Rebalance the response network so it can be ready for the next crisis. Free up special forces and replace them with marines. Then cost (and risk) become an issue and you supplement the marines with regular army so that you free up some of the marines for the next action.
This maps very closely to the optimal strategy for a successful start-up. In its early days, the startup should be optimised for speed. The startup needs to get to market as fast as possible, prove the existence of the market and secure the customers. Who cares about tomorrow when you are trying to stay alive today. As a result, key man dependencies are not a concern and it likely that a skills matrix like this will exist with several significant key man dependencies.
At this stage, the startup may be acquired or receive significant investment, both of which facilitate a rapid growth phase. The teenage years of a startup so to speak. This is the riskiest time for the startup. Its customers will be looking for signs of deterioration of the product if it is acquired by a new owner. At this time, the startup should be focused on risk. They should be ensuring the stability of the product (pay down technical debt) before the product grows / expands, and they should be paying down key man dependencies (liquidity debt). It is at this point it needs to bring in the marines. It needs to hire those developers with enough experience to shave the Yak. Those developers who can quickly pay down the technical debt, establish a solid test automation/continuous integration framework, establish a mature self responsible development culture and acquire the knowledge to address the liquidity debt. The established startup developers have the most options so they should be assigned no work other than to be instantly available to answer the questions of the marines. (This frees the original team members up to work on developing new markets.) After this period, the skills matrix should look something like the following.
Note that there are no key man dependencies.
However Marines ain’t cheap. Anyone looking for developers with five plus years of experience in Agile development skills (Ok, Ok, I mean eXtreme Programming, So sue me) will know that they are not cheap, and they are often contractors/consultants (especially in London where I’m based. Other parts of the world may be different but I’m guessing there is a still a premium to be paid). Once your startup has reached this state, it can look to reduce the costs per head. They can start to hire cheaper developers who do not have extensive Agile experience. They can hire graduates and bring them up to speed. The team can then use the skills matrix to decide if and when to release the expensive marines.
Sadly, the common pattern I’ve observed is that startups switch from optimisation for speed to optimisation for cost, missing out optimisation for risk. How can a company spot whether it is has missed the optimise for risk step? The have the following behaviours:
- They have dragon slayers/hero developers. A simple skills matrix will reveal these key man dependencies.
- They do not have a consistent culture focused on quality and risk, with self disciplined developers and product owners who appreciate the value of quality and risk.
- It will take longer and longer between product releases. They will have infrequent major releases rather than the continuous delivery of small releases (i.e. They will be waterfall rather than Agile as the management will not trust the quality of the application.). Every one will hold their breath when they do a release rather than treat it as a business as usual activity.
- There will be (at least) two cultures. One, a start up culture focused on speed that is in constant conflict with new joiners who feel frustrated at how slowly they come up to speed.
- Others that I cannot think of now as I have a cold.
So what does a company do when it discovers that it has missed out the stage of optimising for risk?
Simple. Call in the Marines. Go hire enough of those experience Agile developers to make a difference to the culture and pay down the liquidity debt and technical debt. It ain’t cheap, but then again, neither is failure.
* Like all good thought leaders I never let facts get in the way of a good story. If you want to see the real thing, check out the right stuff. I cannot find the link and it would great if someone let me know what it is.