A Framework for Diagnosing Slow Engineering Teams

Slow teams are rarely a people problem. A systems-first approach, using the Theory of Constraints, helps founders identify the single bottleneck holding back their entire development process.

An engineering manager confesses his frustration. His team is full of smart, capable developers who work hard. Yet they are always behind schedule. "Every sprint feels like we're running through mud," he says. The instinct in this scenario is to scrutinize the people. The reality, according to a framework outlined by Gavin Cettolo, is that the problem is almost never the people. It is the system.

The 94% problem: blaming people for systems

The first mistake managers make is attempting to optimize the performance of individuals. This leads to more process: more standups, more detailed tickets, more approval gates. Each step, intended as a solution, adds friction. Compounded across a team, this friction is what creates the drag.

The author cites quality systems theorist W. Edwards Deming, who estimated that 94% of organizational problems are caused by the system, not the people within it. Deming's formulation is direct: "A bad system will beat a good person every time." Hiring more talented developers into a broken system does not fix the underlying issues. It only creates frustrated high-performers. The critical question shifts from "who is slowing us down?" to "where does work get stuck, and why?"

Applying the Theory of Constraints to code

To answer that question, the author applies Eliyahu Goldratt's Theory of Constraints. First detailed in the 1984 business novel The Goal, the theory's central premise is that the output of any system is limited by a single bottleneck or constraint.

Any effort to optimize a part of the system that is not the constraint is wasted effort. It will not increase the overall throughput. For a software team, this means that making code review faster is useless if the actual bottleneck is waiting for QA environments to become available. The entire system's speed is dictated by its slowest, most constrained part. Identifying and elevating that single constraint is the only way to increase the team's velocity.

What We'd Change

The framework is a powerful diagnostic lens, but it remains high-level. The provided text introduces the Theory of Constraints without detailing the specific software development patterns or metrics (like DORA) needed to apply it. A founder needs to know how to find the bottleneck in practice.

The theory's origin in manufacturing also requires careful translation to software. Unlike a factory floor, the "inventory" in software is often intangible knowledge work, and constraints can be harder to spot. A bottleneck might not be a slow machine but a single person with unique domain knowledge, a brittle deployment pipeline, or an ambiguous product requirements process. The framework is the correct starting point, but it must be paired with concrete measurement to be effective.

Landing

The solution for the frustrated engineering manager is not a performance improvement plan or a new hire. It is a change in perspective. Instead of managing people, the task is to manage the flow of work through the system. This requires mapping the process from idea to deployment, identifying the single point where work consistently slows down, and focusing all improvement efforts there. The team is not slow because the developers are bad. The team is slow because a constraint in the system is dictating the pace.

The investor read

Investors underwriting a seed or Series A round are betting on a team's ability to ship product. This framework provides a diligence tool beyond resumes and technical interviews. A team that cannot articulate its development process, measure its throughput, or identify its current constraint is a high-risk investment. Conversely, a founding team that actively manages its system of work, using frameworks like Theory of Constraints or metrics like DORA, signals operational maturity. This capability is a leading indicator of scalable execution and is often more valuable than the raw talent of any single engineer.

Pull quote: “Hiring more talented developers into a broken system does not fix the underlying issues.”