How Startups Become 10x Less Efficient at Releasing New Features (or, nSpeed)

nSpeed

nSpeed = the velocity at which a startup is able to build and release new features.

To be clear, the nSpeed estimates below are my personal estimations and not scientific fact. However, I hope they illustrate my main point which is software and business complexity severely slow down the rate at which a technical team can release new features. A fact that many non-technical folks find hard to grasp.

Phase 1  Moving from idea to prototype [nSpeed = 1]

The maximum possible nSpeed is during prototype phase. One developer is able to build huge swaths of product at a break neck pace. There is nothing to impede the developer from thinking about and building new features. No users, no maintenance, no sysops, etc. 100% of efforts result in new features.

Phase 2 – Releasing an alpha version to friends and family [nSpeed = 0.75]

The first group to use a software product is usually a small group of friends and family. At this point developers can no longer devote 100% of effort to building new features. They need to start fixing bugs, supporting users and being mindful of not breaking the working product.

Phase 3 – Releasing a beta version to early adopters [nSpeed = 0.5]

During this phase, a user-base will typically grow from tens to hundreds of users. Developers now need to start thinking about building a stabilized production environment. Code needs to become more tightly controlled, testing servers need to be used, more time is taken up by sysops, more bugs are reported and more support requests are initiated.

Phase 4 – Releasing version v1.0 to the general public [nSpeed = 0.25]

With successful user adoption comes many challenges. Developers need to start coding with “scale” in mind. They need start adding things like job queuing, asynchronous code, load balancing, database sharding and other scaling related sub systems. From this point forward all new code needs to work within the context of a highly distributed architecture. Also, business overhead increases during this phase i.e more product meetings etc.

Phase 5 – 1+ year after releasing V1.0 [nSpeed = 0.125]

After 1+ year, a codebase can grow to 100k+ lines of code. Testing and deployment procedures are now much more complex. There are hundreds of bugs in the backlog. Support systems have now taken on their own life. Systems operations is a full time occupation. Adding new code now requires an unprecedented amount of time consuming forethought, discussion and attention to detail.

 Phase 6 – Becoming a medium to large company – [nSpeed = ?]

A company with 50-100+ employees suffers from all of the above overhead with the additional resistance factor of working with lots of people. What used to be one person’s job now becomes an entire department. Inter-departmental roadblocks, red-tape and meetings slow everyone down massively. The molasses effect is so great, I haven’t even bothered to guess at an nSpeed.

 nSpeed, In Context

Let’s imagine that Mark Zuckerberg was the only developer who ever worked on Facebook. If you think about him as sole developer, moving from one phase to the next, it’s not hard to picture how the nSpeed of each new phase becomes slower. For example, if he had single-handedly worked on the product to get it to phase 5 (with millions of users, a distributed architecture, etc.) it seems highly likely that he would be pushing out new features far slower than during his zero responsibility prototyping phase. I’m going to venture a guess of at least 10x slower.

Conclusion

I think many people understand that it’s much slower to develop within a complex system than it is to develop within a simple one. However, I’m not sure it’s common knowledge just how much slower it can become over time.

If you are a developer, I would be very interested to hear your guess as to what the nSpeeds of phases 1-6 might be.

At the very least, I hope this article helps illustrate why your tech team is gradually getting slower ;)