Who Moved My Bottleneck

Folks like to talk about bottlenecks and especially how AI has removed them. What I see is a lot of people with poor understanding of what bottlenecks are and how capacity works.

The Development Bottleneck

Most folks talk about how now "the bottleneck of development has moved." This is maybe true, but also depends on a lot of factors. First, let's talk about what a bottleneck is and isn't. A bottleneck is a step in a process chain where work gets stuck. This is very different from what folks tend to mean, which is, "I feel like it's taking a long time."

So, was development a bottleneck? What is the process chain we're looking at? Is it from what a development team sees from their backlog to done? It might be a bottleneck here. But then, it might be code review or deployment. What if we zoom out to a larger project or product scale, is development the bottleneck? Could be. Then again there is a whole lot of hurry up and wait that might add months of time before and after development. For example, many companies do large releases, so the deployment process might take as long as the development. What if we zoom out further from idea to delivered? I can almost guarantee it isn't the bottleneck. Approvals, legal, check-ins, budget, allocations, scoping, etc. can all take just as long as the entire development "step."

Generally, folks feel the bottleneck is the most visible step that comes after them. This almost always puts technical delivery in the spotlight, even if the data doesn't support it.

Overproduction Is Real

The opposite of a bottleneck is overproduction. In fact it's one of the wastes in lean. How can there be overproduction in development if it is a bottleneck? All processes have a bottleneck, but not all bottlenecks prevent overproduction.

Overproduction means we produce more than the demand. I bet you're reading that and thinking there is no way we could have overproduction for development. Except we did before AI and we do after.

How do we know we saw overproduction? Because we had to throttle how we released new work to customers. Not for technical reasons, but because we were producing change too fast.

Feature flags are the tool the industry created to manage overproduction. It allowed our industry to produce as much as possible while also getting the benefit of controlling when the changes landed.

The problem with overproduction is that we've built more than the market needs or wants. The problem with managing overproduction is non-trivial too. If we were a factory overproducing paper towels we would now need a facility to store it, a way to transport to and from, a way to track those inventory levels, and ensure the inventory was safe. That's a lot of crap when it just sits there. In software we have to manage lots of configurations to control who sees what, manage the permutations for testing, and work with features that nobody uses yet while fixing ones that do. That's a lot of crap for code that is just sitting there.

Demand Isn't Desire

Organizations have always overwhelmed their processes with work. It is free to ask for more. Product and engineering groups have always had more things to work through than anyone ever can.

The goal was never, and should never be, to do it all.

This is the framing that leads people to believe development was a bottleneck. We desired more than we can produce. Overwhelming a process puts it into a survival mode where anything that can be abandoned will. This is why for decades engineering groups have struggled with quality and eroding trust with peers and leadership. They've been put into a position of survival.

Demand is entirely different. Demand is what the market creates. Demand is a force that pulls on an organization for a change. Consider customer support for a moment. This is a demand force that is a squandered opportunity. Support gets requests, sees trends, asks for changes and then those are magically deprioritized. Demand is subjugated to desire.

There are other demand forces, but the idea is that they create a tug on the organization. There is an ask out in the market that prompts a change. This is different from desire where we push our desires into it. We can always desire more.

Takt Time for Software Teams

Who cares about any of this? Anyone running a company or product group should care. Not understanding how overproduction hurts, how bottlenecks work, and missing demand forces is a great way to build your organization into an early grave.

The good news is that this isn't all that hard to see or measure. The bad news is that it is almost impossible to get someone to listen.

Takt time is one measure that will help you realize if there is a bottleneck worth solving, or you're overproducing. Takt time is a ratio of availability and demand. How do you know what the demand is? Well, this might be an imperfect measure, but it is highly likely you can detect the rate at which your market wants change. They want a meaningful improvement every 6 months. They want their bugs fixed within 2 weeks. It's what the market demands, not what you desire though.

Let me give you an example.

We have a customer base that wants a meaningful improvement every quarter. You work at a company that mostly does annual planning. Which you might argue leaves plenty of time to wiggle, but we'll keep it simple and say your annual plan was to ship these updates to the product.

This means you have 91.25 days to deliver a meaningful improvement. Now look at how long it has historically taken your group to ship an improvement. If it's under that 91.25 days, then you don't need to hurry up or add pressure because you'll overproduce. If you can't ship within that time, now you have a reason to look for and improve real bottlenecks to meet market demand.

Using Takt Time

The reason I'm writing about this is that our industry is obsessed with speed. There is serious risk of this becoming unsafe and unhealthy.

Every leader has an opportunity to look at the system through this lens to make the way work happens smooth and without the waste of overproduction. Minimally it helps leaders contextualize the pressure everyone feels to ship more and ship faster. More than likely you're already shipping too much too fast.

Read More

• How to Use the Metrics and Signals Worksheet: How to use the Metrics and Signals Worksheet. Develop signals, balanced metrics, and operational thresholds that turn your data into decisions.
• How to Measure Developer Productivity: How to measure developer productivity without wrecking your team. Measure the system and team, not the person. What Google's frameworks actually measure, and what changes when AI writes the code.
• Why DORA Metrics Are Bad: DORA metrics aren't bad, but the worship is. What the four metrics can and can't tell you, how teams game them, DORA vs SPACE, and what to build instead.
• Constant Wip Limits: -
• Test Or Die: -