Why is our IT development so slow?

Have you ever asked or been asked that question?

Have you ever experienced a decrease in your IT department's productivity over time?

Do seemingly small tasks take an unbelievably long time, with your software developers giving reasons that you either don't fully understand or find infuriating?

Why do greenfield projects progress so much faster?

Explaining these issues as a technical person to non-technical stakeholders can be incredibly challenging. After literally hundreds of discussions and numerous attempts to articulate this phenomenon, I’ve developed a model that has consistently been the most effective in clarifying the situation and securing buy-in on how to proceed.

Definitions

Slow development, means low productivity.

Let's start by defining productivity.

Productivity is the ratio between what you put into a system and what you get out of it.

In this article, the primary input is development hours, but it can also include money, political favors, hype, and willpower.

The output is business value, as defined by your organization.

Quick question: Are we talking about technical debt here?

Yes. I define technical debt as anything that reduces productivity.

Technical debt isn’t the only factor that can diminish productivity. Unclear policies, overworked employees, poor communication—especially between stakeholders and developers—and frequently changing requirements can all contribute to complexity.

Introducing Carlsson's Productivity-Complexity Model

There is a relationship between productivity and complexity that can be illustrated with this graph.

Productivity starts out high and remains steady for a while. However, as complexity rises in the system, productivity gradually declines.

Zones

This model defines four distinct zones, each with its own possibilities, traps, and challenges.

Greenfield Zone

You're just getting started—there’s little complexity in the system, and development productivity is high.

Note that the marginal change in productivity is low, so you can add a fair amount of complexity without significantly degrading productivity.

How to Proceed in the Greenfield Zone

The Greenfield Zone can be a trap.

1. You can add quite a bit of complexity before it noticeably impacts productivity, making it easy to fool yourself into thinking your architecture and processes are solid—even when you're adding more complexity than necessary.

2. Similarly, high productivity in the Greenfield Zone can in some organizations be dangerous, since stakeholders may get used to the high velocity of deliveries and have difficulty understanding that things naturally slow down when moving to the Normal Zone.

You can handle the first trap by having people above senior-level on your team or as advisors. You can handle the second by having good communication with stakeholders, or if good communication is impossible, you should hold back on delivering business value.

Normal Zone

The marginal change in productivity is increasing, so when you add complexity, you will start to feel a decrease in productivity.

If you can stay in the Normal Zone, it means you've set up good processes.

How to Proceed in the Normal Zone

Being in the Normal Zone is a sign of a healthy project.

You are free to make decisions on whether to focus on delivering business value or removing complexity.

Danger Zone

The marginal change in productivity has reached an unsustainable level. Any small increase in complexity will result in a significant drop in productivity.

A clear sign that you are in the Danger Zone is when small, localized changes trigger cascading issues in parts of the system that logically shouldn't be impacted.

How to Proceed in the Danger Zone

At this stage, you need to collaborate with stakeholders to find ways to improve. Without a good relationship with stakeholders, returning to the Normal Zone is nearly impossible.

One recommendation is to focus on immediate business needs while limiting long-term commitments. From there, shift your attention to getting complexity under control.

Important: A low velocity of business value can stem from various causes, with lack of resources and high complexity being the most common. However, it's crucial to understand that adding more resources will not solve the problem of high complexity. While extra resources might help manage the workload, they often exacerbate complexity rather than reduce it.

Deadlock Zone

In the Deadlock Zone, everything has broken down.

It is not a graphical error that the graph dips below zero on productivity—this is intentional. It illustrates that attempts to improve the situation will decrease business value.

You experience that adding almost any new feature takes a very long time and carries significant risk.

Even maintaining the status quo requires developers on staff to keep the system running; otherwise, it will stop functioning.

It is nearly impossible to reach the Deadlock Zone without underlying issues between development and stakeholders.

How to proceed in the deadlock zone

Since the Deadlock Zone almost always involves a breakdown in the relationship between developers and stakeholders, rebuilding that relationship must be the first step to escape it.

Often, you need to make aggressive decisions, such as:

• Replace IT management
• Replace stakeholders
• Add more resources
• Implement a feature freeze
• Remove features
• Rebuild the system
  • However, rebuilding is often not the right solution. It is frequently underestimated how much effort rebuilding requires. Additionally, if you haven't identified all root causes of the initial breakdown, you are likely to repeat the same mistakes.
• Consider whether the entire product should be scrapped

Considerations

Reflections on the 'How to Proceed' Sections

I really thought about whether I should include the How to Proceed sections. They contain valuable information and pointers on handling different situations, but I worry they might be taken as gospel. Anyone who dares to recommend a different approach could be met with the question, "Do you really think you're smarter than Martin?!?" As a rule of thumb, if someone responds, "Yes, I actually do think I'm smarter than Martin," that person is usually correct. (Think about it – that person has the business context, and I don't.)

Strategic technical debt

The Carlsson Productivity-Complexity Model is meant as a communication tool for explaining complexity and technical debt to non-technical stakeholders.

However, it can also serve as a mental model for yourself when deciding whether to pay down technical debt or focus on delivering business value.

There is a concept called strategic technical debt—it essentially means allowing some accumulation of technical debt, particularly in the Greenfield and Normal Zones, while being deliberate about what to pay down and when.

By understanding the marginal change in productivity, you can make strategic decisions about where to add complexity.

Overengineering is Not Paying Down Technical Debt

A small word of warning — overengineering is not paying down technical debt. Too often, senior-level developers focus heavily on the technical aspects of a problem and forget that every technical decision should ultimately serve the business.

• Don’t automate if building the automation will take longer than performing the task manually.
• If you don’t have at least one dedicated infrastructure person, you don’t need Terraform.
• If you aren’t moving terabytes of data, you don’t need Kafka.
• If you’re not handling streaming, real-time, or big data, your data team doesn’t need Luigi, Airflow, Dagster, or Prefect.
• You don’t need Kubernetes.

Use the Assets

Download PDF, PowerPoint, and PNG files, including transparent background and dark mode versions.

Figma.

Excalidraw.

License

Carlsson's Productivity-Complexity Model is licensed under the Creative Commons Attribution-ShareAlike 4.0 International license, which means you are free to share, copy, and redistribute the material in any medium or format for any purpose, including commercial use.

Attribution under this license only requires that the model's name, Carlsson's Productivity-Complexity Model, is used. There is no need to link to this page or include my full name.

Carlsson's Productivity-Complexity Model © 2024 by Martin Carlsson is licensed under CC BY-SA 4.0