Delivering software is hard. I often see companies undertake large, complex projects that span multiple years and involve hundreds of people. Then, when things deviate from the original plan, managers start finger-pointing at their teams and say the reason for the problems is how teams are “not collaborating,” or they “lack ownership,” or “aren’t aligned.”

Blaming teams is the easy answer. It’s also almost always the wrong one.

The Lure of the ‘Easy Fix’

When projects start showing signs of trouble, when friction appears, or dependencies slow things down, a manager might conclude that a team is underperforming or creating issues for others.

Pointing the finger at a team offers a clear, simple path forward. If teams lack ownership or aren’t aligned, we can create new processes to get them back on track. Whenever problems appear, people can be coached, trained, or educated back to a desired level of performance.

This approach seems decisive, but it’s a trap that proposes a solution without even trying to uncover the actual problem. It ignores the environment—the system—in which teams operate.

Blaming teams is “one-why” thinking.

Blaming teams is possible only if you ignore how everything is connected. Better understanding and better solutions require staying with problems a bit longer, exploring them and considering multiple perspectives.

The need to get back on track leads to rushing to a solution.

Setting Teams up for Failure

Teams operate within a socio-technical system—a complex web of interconnected people, tools, processes, and code. Blaming the teams ignores how everything else is connected.

Teams are not always the cause of problems. Often, they’re the symptom.

The outcomes you see are the result of dozens of organizational and project choices:

• If you design massive, multi-year projects that span dozens of teams, of course alignment and dependencies will be a constant reality.
• If you structure teams around technical components instead of customer value, of course you will hear teams say, “We got our part done.” Their part is all they can see and own.
• If you create unclear boundaries of ownership between teams, of course problems will appear in the spaces between them.
• If you focus only on team-level agile practices, of course the interactions between those teams will become opportunities for problems.

These are not team failures; they are the likely, probable outcomes of the system’s design. Big project plans appear clear on paper, but the real world is more complex, interconnected, and unpredictable.

Trying to fix these problems by giving people better information and instructions does nothing to address the environment the teams are in. Creating more meetings, more reports, and more tracking only adds to the waste.

See the System

Instead of trying to change people’s behaviours, change the conditions in which they work. Shift your focus from blaming teams to probing the system.

Seeing the system starts by asking better questions:

• What’s really going on?
• How are these things connected?
• What pressures are the teams under?
• What does the structure encourage them to do?
• How do people’s behaviours make sense from different perspectives?

When you start to see the organization as a system, you uncover the real sources of friction affecting teams. You find the root causes of burnout, bottlenecks, and poor quality.

A systems thinking perspective allows you to stop playing whack-a-mole with symptoms and start looking for leverage points—places in the system where a small change could lead to a large shift in behaviour.

Tackling a difficult problem is often a matter of seeing where the high leverage lies, a change which—with a minimum of effort—would lead to lasting, significant improvement.

Peter Senge, The Fifth Discipline