How would you identify and elevate a team's primary constraint?

What's really being asked

This question tests your ability to diagnose a complex system, not just a single team's problem. It assesses whether you understand that optimizing a non-bottleneck adds no value to the overall system's throughput. The interviewer is looking for a structured, data-driven approach (the 5 Focusing Steps from the Theory of Constraints) rather than gut-feel solutions.

The full answer

The five focusing steps, in order. First, Identify the constraint, often by visualizing the workflow (e.g., a Kanban board or value stream map) and looking for where work queues up the longest. Second, Exploit the constraint by making the most of what you have, like improving coding standards to reduce rework at a code review bottleneck. Third, Subordinate all other processes to the constraint's pace, for example, by limiting upstream Work-In-Progress (WIP) to match the testing team's capacity. Fourth, Elevate the constraint by adding resources, such as automating tests or hiring another specialist. Fifth, Repeat the process, acknowledging that once one constraint is removed, another will become the new bottleneck.

The mistakes people make

A major red flag is jumping directly to Step 4 (Elevate). Candidates will say "If testing is the bottleneck, we should hire more testers" or "We need to buy a better CI/CD tool." This ignores the cheaper, faster steps of exploiting the current process and subordinating other work to it. Another mistake is "local optimization"—suggesting improvements to a part of the system that isn't the constraint, which provides zero overall throughput improvement because the real bottleneck remains untouched.

What usually comes next

"How would you differentiate between an availability constraint, like a single test environment, and a capacity constraint, like one overloaded designer?" "What if the development team resists subordinating their work, feeling like they're being asked to slow down?" "What specific metric, like cycle time or queue length, would you use to prove something is the constraint?"

A concrete example

Imagine a team's Kanban board shows tickets piling up in the "Code Review" column. The average cycle time for that column is 3 days, while development is 1 day. This is the constraint. First, we Exploit it: we agree that no review should take more than 4 hours and prioritize smaller PRs. Second, we Subordinate: developers are limited to 1 "In Review" ticket at a time and are expected to review others' code before starting new work. This prevents the review queue from growing. Only after these steps fail to solve the problem do we Elevate, perhaps by training more senior reviewers or exploring mob programming to eliminate the review step entirely.