Card

Slow delivery

Slower-than-expected delivery of new technology products is one of the most common issues in tech companies. Teams that are moving too slowly cause frustration, delay the capture of new value, and enable competitors to catch up. Fixing slow delivery is essential to the success of the company.

What challenges are linked with Slow delivery?

I'd put Slow delivery on your radar and read on, if you're facing these challenges:

  •

    High Technical Debt is a state of your technical systems where accumulated shortcuts, outdated code, and quick fixes significantly slow down development and increase maintenance costs. Learn more

  • Too many team dependencies can slow progress, as teams must wait for each other to complete tasks before moving forward. Learn more

  • High cognitive load means that the team has too many things on their shoulders, making them slower to move or to think. Learn more

When is Slow Delivery likely to occur?

In the lifecycle of a tech company, the first stage of "Startup" is characterized by a founder moving as fast as possible to try to find product-market fit. They are often the software engineer themselves or are working side-by-side with the engineer and are always the product manager at this stage.

It's very unusual for slow delivery to occur at this stage as it's a matter of life or death for the company; the founder must move fast, or the company will run out of money and die!

It's more common for the problem to occur at the next stage of the lifecycle, once the company has reached product-market fit and the main focus is scaling the usage and revenue.

At this stage, the company has more people --- engineers, product managers, designers, marketing, sales, and other functions. The founder is typically not the product manager or engineer at this stage as they are busy with other things. This is where you will often start to identify slow delivery.

How to spot Slow Delivery, and is it real or perceived

We all have expectations of how long things should take based on our prior experiences, and this is no different when delivering software.

Therefore, "slow" is a relative measure, and there is a significant element of instinct involved, as no two projects are ever the same in all their attributes. One crucial question to answer at this diagnosis stage is, "Is the delivery actually slow, or is it a perception of slowness but not reality?"

To answer this, it's important to recognize the main attributes that form delivery:

  • Scope - what needs to be built? Is this touching many other parts of the business and technology stack, or is it a greenfield?
  • Complexity of the project - Are we creating something that has many business and technical problems to solve? Is there a playbook on how to solve these problems?
  • Team - how many people are working on this (engineers, product managers, designers, others), and what is their experience level and tenure with the company?

All of these things influence the actual delivery and form the perception of delivery speed. For example, if the team thinks that the scope of what they are building is "x," but leadership thinks the team is building "y," then it's potentially a perception rather than an actual problem, and the real issue is the alignment within leadership. Similarly, having more people (up to a point) typically speeds delivery up, but if those people are all new to the company, they will take weeks to learn the context before they are effective.

You can ask the following questions to assess whether there is a real or perceived slow delivery:

  1. Who is judging? Is the delivery team classifying their work as slow (in which case it is likely slow), or is it coming from outside (a higher chance of a perception issue)? If outside, how well-informed is that view on the nature of the work?
  2. What was the expectation of delivery by this time? Given all the context around the time frame, complexity, and team, is that a reasonable expectation?
  3. Do I have comparable projects to benchmark against with similar complexity, scope, and teams involved?

Once you have considered those questions, you will better understand whether it's actually slow or a perception problem.

Causes of Slow Delivery

Now, let's presume that you have verified the delivery is actually slow, not just a perception. Next, you need to pinpoint the exact cause and resolve it. Hint: there could be more than one.

Here are the potential causes, ranked by most commonly occurring:

  1. Process and Planning Issues - This is the most common cause, where the engineers are unclear on what they need to build, why they are building it, or what factors they must consider. The excessive planning process is equally costly, which forces team members to create unnecessary documents or meetings to appease specific stakeholders. Look out for the following:
    • Unclear or constantly changing requirements
    • Poor sprint planning and estimation
    • Excessive meetings and ceremonies
    • Heavy processes that create unnecessary bureaucracy
    • Lack of clear prioritization and decision-making frameworks
  2. Technical Challenges - Engineering is part art, part science. There is no single formula for creating technology. So it is likely that the engineers will need to solve specific problems they haven't worked on before, using particular technology or tools they haven't used before, all of which take time to learn. Look out for the following:
    • accumulation
    • Complex legacy systems requiring workarounds
    • Inadequate testing automation
    • Poor development infrastructure and tooling
    • Suboptimal deployment processes
  3. Dependencies, Team, and Organization Factors - How your teams are organized ( ) affects how fast they can deliver. Generally, the more autonomous they are, the quicker they can deliver. Look out for the following:
    • Dependencies on other teams or external vendors
    • Context switching between multiple projects concurrently
    • Knowledge silos and bottlenecks
    • Insufficient resources or wrong skill mix
    • Poor communication between product, design, and engineering
  4. Management and Leadership - Leadership is accountable for setting the context for what needs to be done; if this is missing, teams are poorly prepared to deliver. Over-involvement from leaders is also a tax on delivery. Look out for the following:
    • Lack of clear product vision and strategy (learn how to fix it with )
    • Micromanagement slowing decision-making
    • Unrealistic deadlines and pressure
    • Insufficient empowerment of teams
  5. Quality and Testing issues - Delivery of working software is what matters. Therefore, checks and balances around quality, whether the checks are missing or too onerous, are other causes for delivery to slow. Look out for the following:
    • Insufficient testing early in development
    • Manual testing processes
    • Bug fixes taking priority over new features
    • Unclear quality standards
    • Late-stage discovery of issues
  6. Work Environment - Finally, are the working conditions optimal for fast delivery? Consider the human factors at play. Look out for the following:
    • Frequent interruptions and context-switching
    • Lack of managerial support
    • Lack of focused development time
    • Insufficient psychological safety for raising issues

Want to work on this?

Want to work on Slow delivery in your team or company?

Your deck stores the challenges and solutions you're working on, tracks your progress, and recommends other cards you can adopt.

Linked cards

All of these challenges are solvable. It's about finding the specific one/s that are impacting your delivery and addressing them. Use the cards suggested below to explore the right solutions for you.

  •

    Team Topologies is an approach for organizing people in tech companies into effective teams. Most known for introducing four team types and three interaction modes, it aims to reduce team dependencies and manage cognitive load. Learn more

  • ICE prioritization is a framework for ranking ideas based on their Impact, Confidence, and Ease of implementation. Learn more

  • Small (Pizza) teams are cross-functional groups of around 5-8 people who work together closely on a project, promoting quick decision-making and effective collaboration. Learn more

  • Strategic Pyramid documents your entire strategy (Mission → Vision → North Star → Strategy → Goals → Roadmap). Learn more

  • Feature toggles are switches in code that allow developers to enable or disable specific functionalities of a product without deploying new code. Learn more

  • Cross-functional teams are teams permanently containing all roles necessary to deliver product work without relying on different teams. Typically that’s PM, Designer, Tech Lead and engineers. Learn more

  • Teams that remain stable (do not change people because project change) for at least 6 months. Learn more

Hope that's useful!

Nick Kenn