The software development circle of doom

Building and scaling a product development and engineering organization is not an easy task. Most founders of startups and high growth companies indicate that “there is something wrong with the engineering team.” But is there? In a lot of cases, when you start to pay closer attention, you notice different problems. There is not something wrong with a team or the people in the organization. But you see that there is a lack of trust, people don’t communicate, and there is the (perception) of no progress.

Before you know it, you end up in a vicious circle. You end up in the software development circle of doom.

software development circle of doom

The software development circle of doom has three distinct parts that feed each other, and it’s hard to break out of this vicious circle:

No progress
In most cases, the circle of doom starts with progress, or more precise: the lack thereof. Or in some cases, there is too much progress, so there “should be something wrong.”

Because there is no progress, the level of trust degrades, “they say they will release tomorrow, but they’re always late anyway.” “Yeah sure there is a new version, but it’s full with bugs.” “Our competitors already have this feature.” “Why should this take multiple weeks/months to build? It such a simple thing.”

Lack of communication
And with no trust, people stop communicating. There is no longer a feedback loop; different visions and multiple truths become a reality. There is no transparency in status or outcome anymore. People start to hide mistakes; wins are not shared wins and are not celebrated. Resulting in less progress or progress in the wrong direction, and the circle of doom continues.

How to break out of the software development circle of doom

Get to a shared vision.
It’s critical that everyone in the organization understands the vision, knows what the end goal is and what the real jobs to be done for the customer are and why we focus on the first three items on our list and not on the other things on our to-do list. That is the job of the product manager (more on that in Product Management: what people don’t tell you). Here it’s critical that there is a proper balance and understanding on what the level of desired quality is: regular downtime that interrupts customers? Unacceptable. Relying on a manual release process since implementing CI/CD takes a few weeks: we can live with this in the short term but will address it later. A good product manager also educates the organization on why it takes time to create this new feature: it’s not a one-off for one customer but a module that will be reused by all customers. It needs to handle a certain amount of load; it needs to support and be tested on multiple underlying platforms; it needs to be ready for customers in different countries/locales as well, etc.

Value transparency.
Bring transparency to the software development process. Have clear how time is spent (new features vs. bugs vs. tech debt vs. process). Have a good feedback loop where the development team can work directly with customers to get instant feedback. Bring insights in cost and results; maybe you can drop an underused platform if it saves you three days in your release process? Challenge if a feature is really for everyone or perhaps just an overpromise for one customer. And on the other hand: communicate delays, critical issues, and problems early, directly, and with a clear post-mortem and plan of action to gain trust and show you’re on top of it. Work on making clear what is being delivered per release, and link this to actual customers and use cases. Have clear which people work on what, and be open to getting feedback on the prioritization. But also educate on your predicament: “You want more off A? That is possible if I cancel B.” Show progress by having a hit list of bugs you are squashing each week, demonstrate progress in real user performance, etc. Work with numbers, not with anecdotes: “we released ABCD for customer X” is more powerful than “people are working the evening to get the release out.”

Demo real progress.
Have a recurring session where the teams demo real progress. Not a sprint demo where nobody shows and only a terminal or code is visible, no. Real use cases of software that is released. Have the complete management team attend and focus. This demo day is the monthly day where you can make sure the team focuses on the right things; you can understand why the velocity is what it is, and focus on real outcomes and not on anecdotes.

Leave a comment

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.