Developer velocity drives business growth

Rapid product development drives outcomes in startups. McKinsey claims that companies with great developer velocity achieve:

The best way to improve developer velocity is to reduce the time developers spend on unnecessary manual work — when an engineering team moves slowly, it’s usually because they’re busy with work other than building software. In some startups, developers spend a tonne of time manually testing their work, reading bad documentation, manually releasing/deploying code, and troubleshooting issues.

These two teams spend the same time developing software in each iteration. Because team two has a high degree of automation, they can get through two iterations in the same time that the first team can complete just one.
These two teams spend the same time developing software in each iteration. Because team two has a high degree of automation, they can get through two iterations in the same time that the first team can complete just one.

Reduce wait times

Software engineers spend a lot of their time waiting:

When developers wait, they either sit idly or work on something else. Both of these are terrible:

Startup leaders should prioritise developer experience to reduce wait times and keep developers focused on developing.

Tighten feedback loops with automation

The best wait to improve developer experience is through automation. With automated frequent releases, developers no longer need to wait for their work to make it to production. With automated testing, developers no longer need to manually test their work or wait for someone else to do it.

Startup leaders who prioritise automation through DevOps build more productive teams.

Cut out intermediaries to tighten feedback loops

After a feature is released, additional work is usually required to improve it. Customer feedback and the measured performance of the feature (adoption, load times, conversion rates) informs this work. Developers spend a lot of time waiting for this feedback (though they may not realise it because they typically move on to something else while they wait).

While insulating developers from unnecessary distractions is a good idea, leaders often take this too far by adding distance between engineers and customers. Product people often toil over processes and research/communication efforts to help engineers understand customer feedback and customer needs. There is a simpler solution here: expose engineers to customers.

A good software development process features customer feedback at every stage. Engineers should consult quantitive customer data and qualitative anecdotes directly from customers. This exposure doesn’t mean every customer should have constant direct access to engineers; developers must focus on development. But as they build, they should demo and deploy directly to customers who can provide valuable feedback and advice.

Maintaining short wait times

Teams that win over the long term continuously shorten developer wait times. Startup leaders should regularly ask themselves what roadblocks, barriers, and distractions keep their engineers from building software. Try to measure this, and ask your developers for feedback. The less time developers spend waiting, the more they spend building. That’s how you outpace the competition and deliver value to customers.

Subscribe for updates

Subscribe for weekly advice covering product strategy, development operations, building teams and more.

Privacy and terms

I care about privacy as much as you do. I will only use your email address to send you this newsletter or to reach out to you directly, and you can unsubscribe at any time. I will not share, sell, or rent your email address to any third party, though I do store it the software I use to dispatch emails.

The information provided on this blog is for informational purposes only and should not be considered investment advice. The content on this blog is not a substitute for professional financial advice. The views and opinions expressed on this blog are solely those of the author and do not necessarily reflect the views of other organizations. The author makes no representations as to the accuracy, completeness, currentness, suitability, or validity of any information on this blog and will not be liable for any errors, omissions, or delays in this information or any losses, injuries, or damages arising from its use. The author may hold positions in the companies or products discussed on this blog. Always conduct your own research and consult a financial advisor before making any investment decisions.