Theory of Constraints, applied to engineering management

I’ve been reading about Theory of Constraints, and thought I’d interpret in context of engineering management, so here goes. Would love to hear about experiences from folks who have tried some variation or version of this! :

Optimizing each individual department makes things worse. :

Optimize for flow of a change through the entire chain of departments, not focusing on any individual department.

Enter “Drum, Buffer and Rope” strategy, to maximize the processing rate of the bottleneck and hence the entire chain.

“The principles of flow imply a management philosophy: no company should take on more work than their bottleneck can process. The job of management is to determine the capacity of their bottleneck, fill it, and then allow no more projects to begin until one is completed.” :

“The story of a young program manager at Microsoft, Dragos Dumitriu, deciding to take on a challenge: turning around the worst performing software development team in one of the company’s eight IT groups. By the time he was finished nine months later, the team was the best performing in its business unit, with an improvement in productivity of 155%, lead time reduced from five months to two weeks, and due date performance improving from near zero to over 90%.”

“Using a simple approach like Drum-Buffer-Rope in this case showed that much of what constrains the productivity of software engineers (and by extension, other knowledge workers) is not related to the details of how they perform their work, but to the management, planning, scheduling, and queueing of work.”


What to do: Limit the work-in-progress. Adopt “Drum, Buffer and Rope” strategy for each pod/squad/team. A product manager (PM) should be responsible for the buffer (e.g. small-scope user stories). An engineering manager (EM) should be responsible for the rope (e.g. team capacity, supporting infrastructure). The engineers should be in-charge of the drum (e.g. light estimation, coordination, execution).

What not to do: Optimize for predictability. Instead, optimize for velocity and responsiveness and trust, above all else. For example, not spending time on forecasting when a future project will be taken up, another example from :

We optimize for shipping a high volume of user/customer value with each release. We do want to ship multiple major features in every monthly release of GitLab. However, we do not strive for predictability over velocity. As such, we eschew heavyweight processes like detailed story point estimation by the whole team in favor of lightweight measurements of throughput like the number of merge requests that were included or rough estimates by single team members.

See and for more depth on this topic.

Your thoughts?

Published by swaroop