Your Team Isn't Slow, It's Constrained
Why telling your team to 'stop writing code' is the secret to going faster.
The stand-up has the same feeling of pressure it had last week. Everyone looks busy. Yet, the "Done" column is not growing. Deadlines are being missed, the pull request queue is very long, and a stakeholder just asked, "Any update on Project X? We're still waiting."
As a leader, you see the problems first. Delivery dates on the roadmap start turning red. Stakeholders become worried. Your first reaction is often to apply pressure: ask for more updates, tell the team to "pick up the pace," or suggest working extra hours. But this approach, while well-intentioned, only treats the symptoms, not the cause. It leads to more stress, more context-switching, and finally, to burnout.
We've talked before about how a lack of discipline can make Agile feel chaotic in our post, Chaos, Discipline, and Agile. That feeling of chaos is often a symptom of a deeper problem. Here’s the secret: your team isn't slow. They are confusing being busy with making progress. They aren't lazy; their workflow has a bottleneck. Pushing harder on a system with a bottleneck only increases the pressure. It doesn't improve the results.
Stop trying to make everyone faster. It's time to find the single bottleneck that controls your team's speed. By using the Theory of Constraints, a staff+ engineer can guide their team from a state of stressful chaos to a calm and steady flow of work.
The Diagnosis: Finding the Problem Spot
The Theory of Constraints (ToC), from Eliyahu Goldratt, is a powerful mental model with a simple idea: every complex process has one main limiting factor, or constraint. Any improvement that is not focused on that constraint is a waste of effort. (read more about ToC on Wikipedia or Goldratt's book).
Think of your team's workflow like a highway. If a four-lane highway becomes a single-lane bridge, it doesn't matter how fast cars drive on the rest of the road. The bridge controls how many cars get through. Trying to get more cars to the bridge faster only makes the traffic jam worse. To improve the flow, you have to manage the bridge.
In software development, these bottlenecks are everywhere, but they are often hard to see. Common examples include:
The Review Queue: Code is written much faster than it can be reviewed well. PRs pile up, waiting for a few senior engineers.
The Staging Environment: A single, unreliable, shared environment that everyone needs for testing. This creates constant problems and delays.
The Expert: A single person, who must approve or give advice on all major changes.
The Manual Test Process: A QA step that is too slow and cannot keep up with development. This creates a backlog of work that is "finished" but cannot be released.
The Fix: 5 Steps to Improve Your Team's Flow
As a staff+, your job is to help the team see the system clearly and guide them to fix it. The Theory of Constraints gives a simple, five-step process for this.
Step 1: IDENTIFY the Constraint.
How to do it: Teach the team to see the queues. Look at your Kanban or work board. Where is the biggest pile of tickets? Where does work wait the longest before moving to the next step? That is your starting point. The data will show you the truth. The constraint is the step in the process where the most items are stuck.
Step 2: EXPLOIT the Constraint.
How to do it: Before you do anything else, make sure the bottleneck is working as efficiently as possible on the right things. The time of the bottleneck is the most valuable resource in the system. It should never wait for work, and it should not be wasted on bad inputs.
If code review is the bottleneck, then every PR that is ready for review must be perfect. It should be tested, follow the style guide, have a clear description, and meet the team's Definition of Done. The goal is to make sure the reviewer can focus on the important parts of the change, not on fixing small mistakes.
Step 3: SUBORDINATE Everything Else.
How to do it: This is the most unusual and difficult step. The rest of the team must now match the speed of the bottleneck. If the bottleneck is code review, then developers must stop writing new code when the review queue is full.
The goal is to increase the output of the whole system, not to keep every person "busy." If developers are waiting for reviews, they should not start a new feature. Instead, they should focus on the bottleneck. They can help with other reviews, improve documentation, or build tools that make the reviewer's job easier.
Step 4: ELEVATE the Constraint.
How to do it: Only after you have made the constraint as efficient as possible should you invest in improving it. This is where a staff+ uses their influence in the organization.
If the bottleneck is a manual testing process, you can now make a strong case for hiring a test engineer or buying a tool for automation. If the bottleneck is a single expert, you can create a mentoring program to share their knowledge. You have earned the right to ask for help because you have shown that you are using your current resources well.
Step 5: REPEAT the Process.
How to do it: When you fix one bottleneck, a new one will appear somewhere else in the system. This is not a failure; it is a sign of success! Your system can now handle more work. The goal of ToC is not to fix a problem once, but to create a culture of continuous improvement. Now, you go back to Step 1 and find the new constraint.
Handling People's Reactions
This process can feel strange, and you will get pushback from people who are used to old habits.
Objection: "But my performance is measured by how much code I write! I can't just stop working."
Your Response: "That's a problem with the system, not with you. Let's work with management to change how we measure success. We should focus on team output and how long it takes to deliver value, not on individual activity like lines of code."
Objection: "Why should I be idle? That feels like a waste of time."
Your Response: "We are changing the meaning of 'idle' time to 'system improvement' time. When you are not coding, you are helping the whole team move faster. Helping with a review, improving a test, or documenting a service is very valuable work."
From Stress to Success
The Theory of Constraints changes a team's focus from individual effort to a shared understanding of the system. The goal is not to treat talented engineers like parts in a machine, but to remove the problems in the system that stop them from doing their best work.
It replaces the worry of "we're not working hard enough" with the calm focus of "where is the work stuck?"
So, here is a task for you. Find the biggest pile of work in your team's process this week. Get the team together and ask one question: "What is stopping this from moving smoothly?"
You have just taken the first step.