Why development teams slow down
As startups scale, software development speed tends to slow. If you can’t ship product improvements quickly, you can’t quickly solve problems for your business, and you have a higher chance of failure1.
This sentiment is one of the most common conversations I have with founders: “We used to move so quickly, but now we’ve barely delivered anything all year.” Let’s look at some of the most common causes of reduced software delivery.
- Engineers understand customer needs and existing product functionality less. Scoping takes longer, and we release many features that need significant rework to meet customer needs. This decline in customer empathy is usually the result of reduced exposure to customers, with middlepeople like designers and product managers monopolising customer contact.
- Engineers tackle too many initiatives simultaneously2, making extremely gradual progress on many things and rarely completing anything. This problem is usually the result of poor prioritisation. More focus is always better.
- The team has committed to far too many customer deliverables3, leaving them no room to set their strategy, pivot based on their learnings, or address the needs of the broader customer base. These teams should only sell existing functionality, never making promises about future functionality to prospects. Teams should also avoid product commitments to existing customers.
- The product has become too broad4, with too many features to maintain and improve, making it impossible to meaningfully improve the product for most customers within a short period. This problem results from teams expanding their product more aggressively than they expand their engineering team. These teams should ruthlessly deprecate features or grow their team (if they can afford it).
- Leadership constantly sends teams down rabbit holes, chasing shiny new ideas and rarely finishing anything, rather than following customer and market needs5.
- Releases are manual or infrequent, or customer upgrades are opt-in. This infrequency elongates feedback loops, making it impossible to quickly iterate on features, forcing teams to build and deploy big-batch changes loaded with untested product decisions and risky technical changes. These teams should prioritise DevOps6, particularly continuous deployment.
- The team has failed to create reusable patterns (like a design style guide7, utility functions, standardised methods/APIs), so they must start from scratch every time they build something new.
- The team is inundated with bugs and incidents and lacks new feature development capacity. These teams should shift to maintenance-first development, focusing on rebuilding chunks of the product individually, eliminating bugs in bulk and improving functionality as they go. A zero-bug policy for rebuilding parts of the system will help to avoid falling into this situation again.
- When the CEO made most product strategy decisions, they made these decisions quickly and decisively. Now that product managers and designers make these decisions, they are overly careful and hedge their bets, fearing being blamed for a misstep. More iterative development and scoping deadlines can help with this issue.
- Product managers, designers, and engineers spend excessive time communicating and managing the perception of their delivery when they could spend much more time on delivery. This distraction is usually because leadership, boards, investors, customers, or peer teams require them to create roadmaps, progress updates, marketing content, and company-wide presentations as a reflexive solution to slow development when they should spend more time on delivery.
- Product managers, designers, and engineers don’t spend enough time communicating what they deliver, so they are perceived to be less productive than they are.
- Engineers over-index on career advancement or intellectual stimulation when making technology and architectural decisions. When a simple and more pragmatic alternative is available, they needlessly migrate to a hot new framework, architecture (microservices), or language. This distraction adds unnecessary complexity to the development process.
- Product managers, designers, and engineers work hard to look good rather than do good. When individuals act out of self-interest, towards promotions or status, rather than real business outcomes, management must realign incentives towards business outcomes. When a business incentivises real outcomes, even the most self-serving individuals can deliver great results.
- Product managers, designers, and engineers spend excessive time in meetings, discussing problems rather than solving them.
- Decision-making requires too many approvals, and approvers are unresponsive. These organisations should empower teams to make decisions, noting that effective empowerment balances autonomy and accountability8. Make it clear what type of decisions teams can make and what type of decisions sit with management.
- To manage costs, leadership has hired more affordable and, therefore, less experienced or effective engineers, watering down the output capacity of the team.
There are also some good reasons to slow down software development speed.
- The team is now more focused on outcomes than outputs9, so while they ship fewer features, the features they do ship attract much more usage and, therefore, better business outcomes.
- Quality gradually becomes more important as the customer base grows. The team used to deploy untested code, refactor features overnight, and deploy half-finished features to individual customers. Now, the cost of a major bug in production is severe. Similarly, the cost of poor product decisions is greater10. So, teams must be more careful and thorough, writing automated tests and testing features more completely before release.
- The product has a more diverse customer base, making it more arduous to survey customer needs11 and more complex to build a feature usable by a large chunk of the customer base.
- By under-investing in maintenance, the team has let technical debt accumulate and has a legitimate need to pay this debt down. These teams should shift to maintenance-first development to deliver product improvements while paying down technical debt.
- The business previously took far too many legal/regulatory and cybersecurity12 risks and now must consider these risks as teams scope and build new features.
- The team previously worked with unreasonable intensity for unreasonable durations, leading management to expect burnout-inducing speed.
Footnotes
The negative impact of cognitive overload on productivity is well-established in research, but startup leaders rarely factor this into their strategy and operations. ↩︎
Promising future features to new and existing users almost always leads to poor outcomes and a lack of control over your product strategy, because they build up over time and eliminate opportunities to adjust course. ↩︎
The ideal state for product-market fit is to have an extremely narrow and focused product that satisfies a very broad market. ↩︎
You need organisational discipline to focus on the right things and not be distracted by the wrong opportunities. You also must be capable of determining how common and complex the problems you are prioritising are. ↩︎
DevOps is more than product management, and you should invest in it first when facing scaling issues. ↩︎
Investing in product design can lead to fantastic outcomes for product development teams of all sizes because it reduces the number of iterations required to produce a great product or feature. ↩︎
Autonomy and accountability are intrinsically tied together. To achieve great results, people need control over what they do (autonomy) and they need to be motivated by real business outcomes (accountability). Effective delegation requires a balance of these two forces. ↩︎
When starting an initiative, it’s important to focus on the desired outcome before jumping to solutions. By focusing on the problem to be solved, we can ensure all ideas are considered and that we are all working towards a common goal. ↩︎
Teams can stay ambitious with the help of experimentation. ↩︎
To make effective decisions when developing products, engagement with customers is critical. Building this into your way of working should be the priority of any product leadership. ↩︎
Many startups never outgrow their poor security habits. For every high-profile breach, many early-stage startups face existential risk due to poor security posture. ↩︎
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.