← All articles

Tags: Leadership

Managing Is Doing. Leading Is Seeing.

You've solved this problem before. You're certain of it. Different quarter, same conversation, same tension, same outcome. Somehow it's back.

If you're a good manager, and most people reading this are, your instinct is to work the problem harder. More process, more follow-up, tighter accountability. And it helps. For a while.

Then it comes back again.

This isn't an effort problem. It's a visibility problem. And closing that gap is what separates managing from leading.


When I work with delivery managers stuck in this cycle, I start with a bicycle.

A bicycle is a system. Frame, wheels, chain, gears, brakes. Each part has a job. Each connects to others. The bicycle's performance comes from how everything works together, not from how good any single part is.

A competent mechanic knows the parts. A great mechanic knows something more important: how a healthy bicycle is supposed to behave. They carry principles in their head. Not rules. Cause and effect relationships that hold consistently. Higher gear ratio means more speed but more effort. A skipping chain under load isn't a derailleur problem, it's a worn cassette. These principles are what let them look at a symptom and know where to actually look.

Without those principles, you can inspect every component perfectly and still fix the wrong thing.

Your delivery system works exactly the same way.


Every system runs on principles whether you've named them or not. And here's what makes this uncomfortable: most delivery managers haven't named theirs.

Consider one principle your team is almost certainly living with right now: the higher the work in progress, the longer the cycle time.

You've felt this. Twelve things in progress, everyone busy, nothing finishing. The instinct is to push harder, add urgency, maybe add resource. All reasonable responses to what you can see. But the principle is telling a different story. Starting more work isn't creating more output. It's creating more waiting, more context switching, more half-finished items competing for the same attention.

When you know the principle, you ask a different question. Not "why is this taking so long?" but "what would happen if we stopped starting and started finishing?" That question is only available to you if you know the principle producing the problem.

This is what principles give a leader that a manager doesn't have: a diagnostic lens that reaches beneath the symptom. Some principles are universal across delivery systems. Some are specific to your organization, your history, your incentive structures. A leader builds that working knowledge deliberately, and checks it regularly, because systems drift. The principles being followed today aren't necessarily the ones being followed six months from now.


Now here's where it gets more honest.

Your team is a system. But it doesn't operate alone. It sits inside a department, which sits inside an organization. Each layer has its own components, its own principles, its own logic.

Some of what looks like your team's problem is actually the larger system's behavior flowing downward. A team missing commitments despite genuine effort isn't necessarily a team problem. It might be priorities shifting above them, dependencies they can't control, decisions waiting on approvals three layers up. Your team is responding rationally to the system it operates in.

A manager sees the missed commitment and applies pressure. A leader asks which system is producing it.

And then, critically, a leader names the constraints.

Every system operates under constraints. Some are real. Some are inherited assumptions nobody has questioned in years. Most teams carry these as background anxiety, feeling the walls without seeing them, adapting around invisible boundaries that cost enormous energy and create quiet, chronic confusion.

When you name the constraints your system operates under, something shifts. Not because they disappear. Because the anxiety of fighting invisible walls gives way to the clarity of a known boundary. The team stops burning energy wondering why things are the way they are. They can perform at their best within the actual system they're in, while their leader examines which constraints are genuinely fixed and which ones have simply never been challenged.

A great mechanic doesn't fight the terrain. They set the bicycle up to perform on the terrain that actually exists. And when they suspect a constraint isn't real, they test that assumption deliberately rather than working around it forever.


The shift from managing to leading isn't about working harder or getting smarter. It's about asking different questions.

What is my system actually producing, not what I intend it to produce?

Which principles should be governing this system, and is there evidence they are?

What constraints is my team operating under, and which of those have we actually examined?

Your recurring problems are already pointing at the answers. You just need a different lens to see what they're telling you.


When you know your system, its principles and its constraints, the next question is what to do when something breaks. Most teams reach for root cause analysis. It's familiar. But in complex delivery systems, finding the root cause tells you what happened without telling you why the system keeps producing it. That's a different question. It needs a different approach. That's what we'll get into next.