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.
The IT Risk Manager 
March 2nd, 2014 at 10:00 pm
Other behaviours that can be observed:
– poor quality, struggling to get releases out
– long integration periods
– cross team work is inefficient
– difficulty delivering significant product features
– frequent releases, but little value in them
March 2nd, 2014 at 10:15 pm
Interesting. As I read it, the TL:DR summary is something like: invest most heavily (certainly in experience/rates terms) in setting up the sustainable working culture and practises that can scale (crappy code doesn’t scale, nor do crappy practises).
But this happens *after* you’ve proved basic fitness for purpose of the model, which can (should?) be done string and sellotape.
This is congruent with the Fred Brooks maxim: plan to throw one away. You’re going to do it anyway, so accept the reality & plan for it.
Which may mean that you should plan that your first release can be ultra crappy and pivoting off a codebase already available, but the second release could be spent in a ground up, clean rewrite/significant refactor. Much later than that and the invested time, energy and money will make it very hard to do and you’re left with the legacy of the decisions you made when you didn’t know enough.
If I recall correctly, that’s what Twitter did. My first recollection of it (mid 2007) was a trusted friend complaining that it was a great idea but the performance was utterly rubbish. Shortly after that, they rebuilt it from a CMS architecture to a messaging one, and the rest is history.
March 5th, 2014 at 1:07 pm
I’m loving this Staff Liquidity thing, Chris (although hope you don’t mind, but I’ve mentally renamed it “Skills Liquidity” when I think about it).
Some interesting points in this post. In particular, I’m reflecting on the fact that “liquidity debt” and “technical debt” really are the same thing.
I’ve been staring at some code this morning, which I had no direct or even indirect hand in designing or writing. It’s extremely difficult for me to understand, because the architecture is non-obvious, and the code is not self-documenting. Both may be considered items of “technical debt”. The net effect is that the cost of anyone _other than the original author_ working on that part of the system is prohibitive. This is a liquidity problem. Effectively, an area of “expertise” has been created where none really had to exist. If care had been taken to consider _future development_ (but not future requirements) then development of that part of the system would now not require any particular expertise.
I guess this is what your Marines end up managing, as you describe it.
What’s more intriguing though, is that the capacity to manage this risk is actually available from the outset, and persists well past the “teenage” stage. Without sufficient management, I think it’s fair to suggest that all active software projects will suffer from this degradation of technical liquidity. The rate at which this occurs on any given project is surely very relevant to exactly when we “deploy the Marines”. We may even want Marines to be involved from day 0 if the risk of critical degradation is high enough; and we may never want them to leave for the same reason.