As an individual contributor, I focused on my code. I knew the word “constraint”, but only as a concept. I never thought about where constraints actually lived in a system or how to identify them.
In 2020, I read The Phoenix Project. It made sense, but didn’t stick. Two years later, in 2022, I read it again, this time through I was a manager responsible for team delivery. The book clicked. That summer, I picked up The Goal and The Unicorn Project. I wasn’t just curious about constraints anymore. I wanted to see how they worked in the real world. I was struggling to manage my team’s projects and needed tools to see what was really happening.
That reading introduced me to systems thinking and theory of constraints. I began to realize most problems aren’t local to the team, they’re systemic. If you only look at the team you’re on, you miss where the work comes from and where it goes. To find the real constraint, you have to zoom out.
Someone recently asked how to speed up a team. Should we add headcount? Was the manager blocking progress? Are the dev’s slow?
I spent time with the team and followed the flow of work. It turned out they weren’t slow. They were overloaded. Besides building software, they were managing tickets, clarifying requirements, and coordinating priorities. The engineers were doing work that should’ve been handled upstream.
The team wasn’t the primary problem. The system was.
When you can see the system, you stop guessing. You start solving the right problems.
Finding Your System’s Constraints
When teams seem slow, don’t add people right away.
Follow the work, not the workers. Pick a few tickets and trace their path from idea to deployment. Look for every handoff, approval, and queue. How long is work idle versus active?
Count the hidden roles. Watch what your team actually does during a sprint. Are developers also acting as business analysts? Are they managing stakeholder expectations? Are they debugging integration issues that stem from unclear requirements?
Identify the work that flows downhill. Look for tasks that repeatedly land on your team’s plate. Are you surprised by what they are working on?
The constraint usually isn’t where you think it is. It’s in the handoffs, the unclear responsibilities, and the work that nobody officially owns but somehow becomes the development team’s problem.