How would you identify and elevate your team's primary constraint?
This tests systems thinking over local optimization. A great answer outlines the 5 steps: identify the constraint (e.g., long queues), exploit it, subordinate other processes, elevate it, and repeat. A red flag is jumping straight to hiring or buying tools.
What's really being asked
This question assesses your understanding of systems thinking and the Theory of Constraints (TOC). The interviewer wants to see if you can move beyond local optimizations (e.g., "my developers are busy") and identify the single factor limiting the entire system's throughput. It tests your ability to use data to find a bottleneck and apply a systematic, multi-step process to address it, rather than just throwing resources at a perceived problem.
The full answer
A strong answer walks through Goldratt's Five Focusing Steps. First, IDENTIFY the constraint by looking for where work piles up; use metrics like cycle time per stage or queue size. Common constraints are code review, a shared test environment, or a single UX designer. Second, EXPLOIT the constraint by making the most of what you have, like improving coding standards to reduce review rework. Third, SUBORDINATE everything else to the constraint's pace; for example, limit upstream WIP to match the bottleneck's capacity. Fourth, ELEVATE the constraint by adding capacity, such as automating tests or hiring another specialist, but only after the first three steps are done. Fifth, REPEAT the process, acknowledging that once one bottleneck is fixed, a new one will emerge elsewhere.
The mistakes people make
The most common mistake is jumping directly to Step 4: Elevate. For example, saying "If QA is the bottleneck, I'd hire more QA engineers." This ignores cheaper, faster improvements from exploiting and subordinating. Another red flag is focusing on utilization metrics ("everyone should be 100% busy") instead of flow metrics. High utilization often creates bottlenecks and hides the true constraint. Finally, candidates may suggest fixing multiple "bottlenecks" at once, which violates the core principle of focusing on the single primary constraint that dictates system throughput.
What usually comes next
"How would you convince a developer who is being asked to slow down (subordinate) that it's the right thing to do?" or "What if the constraint is outside your team's direct control, like a legal sign-off process?" or "Walk me through the specific metrics you'd put on a dashboard to monitor for constraints."
A concrete example
Imagine our Cumulative Flow Diagram shows the "In Review" column growing much faster than the "In QA" column. Code review is the constraint. First, we EXPLOIT it by establishing clear coding standards and encouraging smaller PRs to speed up reviews. Second, we SUBORDINATE by setting a WIP limit of 5 on the "In Review" column; developers can't push new code for review if the column is full. Third, after weeks of this, if it's still the bottleneck, we ELEVATE by training more engineers to be effective reviewers or dedicating specific "office hours" for reviews. Once reviews flow smoothly, we'd see the bottleneck shift, perhaps to QA capacity.
Interview question
A software team identifies its code review process as the primary constraint. According to the Theory of Constraints, which action should they prioritize before considering hiring more reviewers?
- a.Implement stricter coding standards and encourage smaller pull requests to improve review efficiency.Correct
- b.Immediately hire additional senior developers to assist with code reviews.
- c.Assign more development tasks to ensure all engineers are fully utilized while waiting for reviews.
- d.Begin simultaneously optimizing the QA and deployment processes to address all potential bottlenecks.
Why? this is the answer
The Theory of Constraints (TOC) dictates that after identifying a constraint, the next step is to 'exploit' it by making the most of existing resources, such as improving review efficiency through better standards and smaller PRs (Option A). 'Elevating' the constraint, like hiring more reviewers (Option B), is a later step, only considered after exploiting and subordinating. Options C and D represent common misconceptions: focusing on local utilization or attempting to fix multiple bottlenecks at once, rather than the single primary constraint.
Just read this? Test yourself on what you have been reading.
Read the original → theagilemindset.co.uk
- #agile
- #systems thinking
- #theory of constraints
- #devops
- #kanban
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on agile — each one lists the topics its interview covers.
See open roles