Managers in the Theory of Constraints

If you are a people leader in a software company, you probably wrestle with just how much of the day to day activity of your team you should be involved in. My view is that you should be involved just enough to be able to understand the constraints they face and spend the rest of your time working on lessening those constraints.

The Theory of Constraints (TOC) basically says that in a complex system, such as software development, there will always be limiting factors and that one of those factors will always be the biggest bottleneck at any given time.

Managers don’t attend daily stand-ups so that they can solve whatever tricky coding challenge the team is facing. They listen to make sure they are working on the right constraints. Same for planning meetings and demo’s. Managers should not attend sprint retrospectives - there’s a natural power imbalance with their direct reports and we need to create safe space for the team to talk about how they want to improve next sprint. But managers should review the actions and commitments the team makes during that retrospective so they can back test against the constraints they are focusing on and support the team.

The metrics a manager chooses to focus on at any give time will be aligned to their understanding of the constraints in the system. Cycle time, PR open time, test automation coverage percentage, defect escape rate, along with all the other DORA metrics, all connect to different points of constraint in our systems. Teams cannot improve on everything everywhere all at once, so a manager plays a key role in helping the organization focus on the primary constraints and find the right metrics for them.

I’ve coached my leaders on this by saying, “Your job is to be an arson investigator. If you are walking around with buckets of water constantly putting out fires, who is spending time catching the person starting them?”

I think often times managers allow themselves to get pulled into a pattern of firefighting because it feels familiar and it satisfies a personal need to feel needed and appreciated. Removing constraints is often a somewhat thankless job. Organizations suck at rewarding avoiding a disaster, but never fail to applaud a hero that helps us recover from one. Firefighting work is also familiar because most managers come from technical contributor roles where they developed skills related to fighting those fires. When they made the transition to being a people leader they simply never learned the skills to become a detective.

What I really like about the TOC is that it highlights that friction and toil in our process is not a zero-sum game. Managers need to avoid the fallacy that they have to shoulder the burden of annoying work for their team - playing hot potato with toil like that means nobody is addressing the constraint. You serve your team much more effectively by working to eliminate the toil than you do by taking it on for them!

So… how in the weeds are you? Are you spending most of your time solving specific problems for your teams so they can keep moving? Do you have an opportunity to coach and empower the team so that you can find ways to remove/reduce toil for them? What have you done in the last four months to make life easier for your team members?

If you’re a leader of leaders, how effectively are you coaching your managers to act this way? What is the focus of your conversations? Do you talk more about what the team is delivering than you do about how they are improving? If so, you may well be reinforcing these leadership anti-patterns.

I’d love to hear from leaders on how they think about this balancing act.