Agile Leadership vs Traditional Leadership: Leading with Harmony, Not Control

Agile leadership is not traditional management with Agile language added.

In this episode, we explore the difference between Agile leadership and traditional leadership, and why leading with harmony, not control, is critical in modern digital product organisations.

We discuss how traditional leadership often seeks confidence through control, reporting, escalation, approvals, and output tracking, while Agile leadership creates confidence through clarity, trust, learning, decision boundaries, autonomy with accountability, and better operating conditions.

The episode also introduces some of the thinking behind Matthew Coxall’s upcoming work on Product Agile Harmony and THOM, The Harmony Operating Model, as a practical way to understand how leadership, product flow, technology, funding, measurement, and everyday decisions interact.

Listen to more Agile Product Hub podcasts:
 https://agileproducthub.com/podcasts

Available on your favourite podcast platform.

Transcript

Speaker 1 0:00

Welcome back to the deep dive in the agile product hub. Many organizations ask teams to be agile, empowered, and outcome focused while the leadership system still behaves through control, reporting, escalation, approvals, and certainty.

Speaker 0:15

Yeah, it's um it's a massive collision. We're looking at a really fundamental tension in the modern corporate world today.

Speaker 1 0:21

Right, because you have these, you know, highly capable teams, they're trying to navigate this complex, totally unpredictable digital reality, and they're essentially being suffocated.

Speaker 0:32

Suffocated is the exact right word. I mean, they're trapped in an operating system that just demands this absolute illusion of perfect predictability.

Speaker 1 0:39

And that collision, that's what we're going to examine today. We're pulling from three really foundational books by author Matthew Coxell.

Speaker 0:46

Right. So we have engineering leadership, product agile harmony, and the harmony operating model guide.

Speaker 1 0:52

And across these texts, Matt really deconstructs why these traditional leadership habits just completely break agile initiatives.

Speaker 1:00

He does. But you know, more importantly, he provides this mechanical blueprint for what we can actually do about it.

Speaker 1 1:05

Yeah, the intellectual thesis we're digging into today is um you know it's profound, but it's really practical.

Speaker 1:11

Exactly. The core message is that traditional leadership seeks confidence through control, right? But agile leadership, it creates confidence through conditions.

Speaker 1 1:21

Right, conditions. Like engineering clarity, trust, learning, decision boundaries.

Speaker 1:26

Yeah, and autonomy with accountability, which is huge, plus technical sustainability and just generally vastly better operating conditions.

Speaker 1 1:34

So that the right decisions can actually happen closer to the real work.

Speaker 1:38

Exactly. But before we get deep into the mechanics of those conditions, we should probably introduce the uh the connective tissue of Matt's upcoming work.

Speaker 1 1:45

Oh, yeah, definitely.

Speaker 1:47

So THOM, the Harmony operating model, pronounced Tom, is a new and exciting way to bring operating models together. It is not another framework to roll out, but an operating lens for seeing how strategy, leadership, product flow, technology, data, funding, structure, measurement, and everyday decisions interact. Right.

Speaker 1 2:04

And I want to start by, you know, kind of painting a vivid picture for you listening of what it really looks like when a team is trapped inside that traditional system.

Speaker 2:13

Because the facade is just incredibly convincing, isn't it?

Speaker 1 2:16

Oh, it's so convincing. Like there's this story right in the preface of Product Agile Harmony. It's about a delivery team that looked on paper like an absolute dream.

Speaker 2:26

Uh, right. The amber green dashboard illusion.

Speaker 1 2:30

Yes, the classic dashboard.

Speaker 2:32

I mean, Matt describes leading this delivery team that just had all the artifacts of success, right? They had these meticulously crafted project plans.

Speaker 1 2:41

Hitting all their milestones.

Speaker 2:43

Every single one. The steering committees were completely calm. Every dashboard they put in front of leadership was just glowing and, you know, reassuring, perfectly balanced amber and green.

Speaker 1 2:53

Which is what every executive wants to see Of course.

Speaker 2:55

And everyone involved was just working at maximum capacity, you know, burning the midnight oil just to make sure those status indicators never slipped into the red.

Speaker 1 3:02

So if you're listening to this, the natural question you're probably asking is, well, what's the actual problem? I mean, it sounds like a well-oiled machine.

Speaker 3:09

Right. But the problem was this complete decoupling of their metrics from actual reality.

Speaker 1 3:14

Right. Because beneath the surface of that green status reassurance, the whole system was fundamentally broken.

Speaker 3:21

Completely broken. I mean, they were flawlessly delivering outputs, but they were not achieving outcomes.

Speaker 1 3:28

Just constant movement.

Speaker 3:29

Exactly. Shipping code, closing tickets, moving JiraCards from in progress to done. But they weren't actually advancing the business.

Speaker 1 3:37

And crucially, they weren't learning anything.

Speaker 3:39

No, not at all. The entire apparatus of the team had just accidentally become dedicated to feeding the dashboard.

Speaker 1 3:45

Feeding the beast, yeah.

Speaker 3:46

Instead of discovering what the customer actually needed.

Speaker 1 3:49

And we see this facade of agile literally everywhere. An organization realizes uh our market is moving too fast, so we need an agile transformation.

Speaker 3:58

Oh, here we go. The consultants arrive.

Speaker 1 4:01

Exactly. They hire the consultants, they launch these massive training programs, they update all the corporate terminology, right?

Speaker 4:06

Suddenly everyone's in a squad or a tribe.

Speaker 1 4:09

Yes. They rebrand the traditional project teams into squads. They start doing two-week sprints, daily stand-ups. But if you look at the underlying plumbing of the company.

Speaker 4:21

The legacy system is completely rigid.

Speaker 1 4:23

Totally. The teams are told, hey, you're agile now, but they are completely trapped inside waterfall governance.

Speaker 4:30

Let's actually look at the mechanics of that trap because it's fascinating. Like a team might work in a two-week iteration, right?

Speaker 1 4:37

Sure, two week sprints.

Speaker 4:38

But their funding is still tied to this rigid 12-month business case that promised, you know, a very specific set of features by a specific date.

Speaker 1 4:46

Right, which completely defeats the purpose of the sprint.

Speaker 4:49

Exactly. And they're stuck in these matrix reporting lines where their engineering manager, their product manager, and their design lead all report up to completely different executive silos.

Speaker 1 4:59

But with totally conflicting incentive structures.

Speaker 5:02

Yes. Aaron Ross Powell And they're measured by output-based KPIs, like uh how many story points did you deliver this week?

Speaker 1 5:08

Well the technical debt just quietly rises beneath the surface.

Speaker 5:12

Because the system literally does not allocate any capacity for architectural maintenance.

Speaker 1 5:18

You know, it's kind of like imagine buying a state-of-the-art, beautifully engineered, highly responsive sports car, right?

Speaker 5:25

Okay, I'm with you.

Speaker 1 5:26

And then forcing it to drive on a completely congested, pothole-filled dirt road, and then installing a dial-up modem directly into its navigation system.

Speaker 5:38

That is a painful mental image.

Speaker 1 5:40

Right. You have this incredible machine that can adapt rapidly, but the environment throttles its potential at every point of connection.

Speaker 5:46

And then when the car fails to hit 100 miles an hour, what does management do?

Speaker 1 5:50

They blame the engine or they blame the driver.

Speaker 5:53

Exactly. They never look at the road.

Speaker 1 5:54

Never.

Speaker 5:55

And you know, the environment is the real constraint here. To fix that environment, we have to first understand the specific ways that this traditional system

Speaker 1 6:03

And why it was built that way in the first place.

Speaker 6:05

Right. Because if we just treat traditional leaders as like malicious villains who love micromanaging people, we completely miss the structural root of the problem.

Speaker 1 6:16

Yeah. I mean, nobody wakes up in the morning and says, um, I think I'm going to deliberately sabotage my software engineering team today.

Speaker 6:24

Far from it. Traditional leadership models, and many of these trace all the way back to Taylorism and the industrial age, they were brilliantly designed for a very specific context.

Speaker 1 6:34

Like a predictable, physical, project-centric world.

Speaker 6:38

Exactly. If you're building a suspension bridge or manufacturing 10,000 identical widgets on an assembly line, the variables are mostly known.

Speaker 1 6:45

Right. Physics doesn't change halfway through the project.

Speaker 6:48

No, it doesn't. And in that environment, fixed timelines, fixed scope, upfront certainty, they aren't just possible. They are essential for safety and profitability.

Speaker 1 6:57

So the illusion of certainty is actually an achievable target there.

Speaker 7:00

Yes, but digital product development is not a suspension bridge.

Speaker 1 7:03

No, the materials we're building with uh code, user behavior, market dynamics, competitor innovations, they are entirely invisible and constantly shifting.

Speaker 7:15

Digital work is inherently complex. It's exploratory, it's highly interdependent. You're basically building the factory at the exact same time you're trying to manufacture the product.

Speaker 1 7:25

While the customer keeps changing their mind about what they even want to buy.

Speaker 7:29

Right. Customer needs evolve mid-flight. The technology stack shifts underneath you. Traditional control mechanisms just cannot handle that level of volatility.

Speaker 1 7:39

Because they're designed to suppress variants.

Speaker 7:42

Exactly. Whereas agile requires you to exploit variants to discover value.

Speaker 1 7:47

There's this great anecdote Matt shares in engineering leadership that just perfectly illustrates how these traditional instincts backfire.

Speaker 7:54

Trevor Burrus Oh, the engineering manager story.

Speaker 1 7:55

Yes. He talks about this highly capable, really well-intentioned engineering manager whose team started missing their delivery deadlines.

Speaker 8:04

And let's really analyze the manager's reaction here because it is so common.

Speaker 1 8:07

Right. His immediate instinct was just to step in and tighten the grip.

Speaker 8:11

He started checking in with the team every single day. He demanded far more granular status reports. He increased his own personal oversight of all the architectural decisions.

Speaker 1 8:22

Because from his perspective, the system was failing. So he needed to inject more control to stabilize it.

Speaker 8:28

He's treating knowledge work like an assembly line bottleneck.

Speaker 1 8:32

Right. Like if a machine on a factory floor slows down, a supervisor stepping in to monitor it closely might actually find the mechanical flaw.

Speaker 8:40

But in software, that intervention just creates a death spiral.

Speaker 1 8:45

How so? Like break down the mechanics of that.

Speaker 8:47

Well, it creates a feedback loop of reduced capacity. When the manager increases those daily check-ins, he forces the engineers to constantly context switch.

Speaker 1 8:56

Oh, right, pulling them out of deep work.

Speaker 8:58

Exactly. They have to stop deep focused problem solving just to justify their time to him. And that cognitive load actually reduces their coding capacity.

Speaker 1 9:07

Which leads to more bugs, which leads to more missed deadlines.

Speaker 9:10

Exactly. And furthermore, by taking over the architectural decisions, he completely erodes the team's autonomy. The engineers stop thinking systemically.

Speaker 1 9:19

They just wait to be told what to do.

Speaker 9:21

They stop anticipating problems. They just wait for the manager to give the next order. And the sheer irony of this paradox of oversight is that the harder the manager tries to enforce control, the slower the decision making becomes.

Speaker 1 9:34

It brings the whole team to an absolute crawl.

Speaker 9:37

Yep.

Speaker 1 9:37

And, you know, that desire for control, it culminates in what might be the most staggering example from the source material.

Speaker 9:45

The 3,000 page specification document.

Speaker 1 9:49

I mean just let that sink in. 3,000 pages.

Speaker 9:52

It stands as the ultimate monument to the illusion of certainty. Matt details this massive multi-year initiative where a traditional organization tried to define every single element of a complex digital system up front.

Speaker 1 10:05

Before a single line of code was written.

Speaker 10:07

Before a single real user interacted with a prototype. Before any genuine learning could happen, they pumped out 3,000 pages of requirements.

Speaker 1 10:15

Let's really think about the mechanics of producing a document like that.

Speaker 10:18

It's terrifying.

Speaker 1 10:19

It is. It requires hundreds of people sitting in windowless conference rooms for months debating the hypothetical placement of a button or the hypothetical structure of a database.

Speaker 10:30

For a product that won't even launch for another three years.

Speaker 1 10:32

Right. And by the time the ink is dry, the market has moved on. The technology is obsolete.

Speaker 10:38

It's just a desperate organizational demand for upfront alignment, and it shatters the second it makes contact with reality.

Speaker 1 10:45

And we really have to look at the systemic signals that drive a company to produce a document like that. Because this isn't just, you know, a rogue project manager gone mad.

Speaker 10:55

No, not at all. As Matt's work on TUM points out, behavior in an organization is almost entirely shaped by systemic signals.

Speaker 1 11:02

Right. People don't behave based on what's written in a strategy memo.

Speaker 11:06

Or what the CEO says in a town hall meeting. Behavior is shaped by what gets funded, what gets escalated, what gets celebrated, and crucially, what gets tolerated.

Speaker 1 11:14

So if an organization requires this mathematically perfect ROI projection before they release a single dollar of funding, they are structurally demanding that teams lie to them.

Speaker 11:25

They're demanding that 3,000-page spec.

Speaker 1 11:28

Exactly the mechanism. If the executive layer publicly claims to value, you know, learning and experimentation.

Speaker 11:34

But then privately punishes a team when a validated experiment proves a multimillion dollar feature shouldn't be built.

Speaker 1 11:40

Right, because it won't yield returns. And instead, they just yell at the team for delaying the original timeline.

Speaker 11:47

The system learns an indelible lesson right there. The system learns that the speed of delivery is way more important than the value of the delivery.

Speaker 1 11:54

It learns to ship the wrong thing on time rather than the right thing late.

Speaker 11:58

Exactly. So if traditional leadership relies on this brittle illusion of certainty and these really rigid signals of control, we need to redefine what agile leadership actually entails.

Speaker 1 12:10

Because a huge misconception out there is that agile leadership is just passive facilitation.

Speaker 12:14

Right. The idea that you just put a group of smart people in a room, say, uh, you're self-organizing now, and then walk away hoping for the best.

Speaker 1 12:22

Aaron Powell, which is arguably just as destructive as micromanagement.

Speaker 12:25

It absolutely is. Redefining leadership as a value-driven function means moving from commanding the work to designing the environment.

Speaker 1 12:34

Right. It means ruthlessly prioritizing outcomes over outputs.

Speaker 12:39

And it requires a leader to create extreme clarity by connecting the daily, granular engineering tasks directly to overarching business impacts. It's deeply intentional system shaping.

Speaker 1 12:50

To see that stark contrast in action, we have to talk about the Monday morning scenario from Product Agile Harmony.

Speaker 12:56

Oh, this is a phenomenal mechanical breakdown of leadership responses.

Speaker 1 13:00

It really is. So let's set the stage for you listening. It's a high pressure Monday. You've got three distinct product teams barreling toward a major publicly promised milestone.

Speaker 13:09

And they all depend on a shared platform capability.

Speaker 1 13:12

Right. Deadlines are incredibly tight, dependencies are super fragile. And over the weekend, a delay in one team's database migration creates this massive ripple effect.

Speaker 13:21

It completely blocks the other two teams.

Speaker 1 13:23

Exactly. The mood in the office is incredibly strained.

Speaker 13:26

The stakes are high, the system is under severe stress. So let's look at leader A, who represents the traditional control mindset.

Speaker 1 13:35

Right. The person who wants to re-establish certainty.

Speaker 13:38

Confronted with this crisis, Leader A reacts forcefully. They immediately call an urgent, mandatory cross-team meeting.

Speaker 1 13:45

Everyone in the conference room right now.

Speaker 13:47

Exactly. They demand a root cause analysis on the spot, they dictate immediate fixes, and they significantly tighten the atmosphere.

Speaker 1 13:55

Making it very clear that failure to hit the milestone is completely unacceptable.

Speaker 13:59

They want answers and they want them immediately.

Speaker 1 14:02

Now think about the psychological response from the engineering teams in that room. It's just immediate contraction. Total shutdown. When a leader tightens the atmosphere like that, the actual risks immediately go underground.

Speaker 14:14

The conversation instantly shifts. It moves away from uh how do we collaboratively solve this complex architectural dependency to how do we manage the perception of this problem so our specific team doesn't take the blame.

Speaker 1 14:28

Right. The engineers stop looking at the system as a whole. They just retreat into their silos.

Speaker 14:33

And they'll just offer quick, super fragile patches just to satisfy the leader's demand for an immediate fix.

Speaker 1 14:38

Which just builds in massive technical debt that will inevitably explode next quarter.

Speaker 14:43

Exactly. So now let's rewind the tape. Let's bring in leader B, the agile or harmonic leader, facing the exact same Monday morning crisis.

Speaker 1 14:53

How do they handle it?

Speaker 14:54

Leader B understands that their primary job is to regulate the temperature of the room and clarify the decision boundaries.

Speaker 1 15:01

So they don't step in and ask, you know, who broke this or when will it be fixed?

Speaker 15:06

No, they ask a completely different set of questions. They ask what do we definitively know right now? What do we not yet know?

Speaker 1 15:13

Aaron Ross Powell Looking at the dependencies, which ones are absolutely critical to the core user journey, and which ones can flex.

Speaker 15:19

Yes. And what assumptions did we make last week that need to be entirely revisited today?

Speaker 1 15:24

That phrase, what can flex? It's such a powerful environmental lever.

Speaker 15:28

It really is. By introducing the concept of flexibility into a rigid crisis, the leader implicitly gives the teams permission to negotiate the scope.

Speaker 1 15:37

It creates cognitive space. It dissolves all that panic and blame into collective systemic problem solving.

Speaker 15:45

And that is the absolute core of leadership as environmental design. The harmonic leader isn't writing the code to fix the database themselves.

Speaker 1 15:54

But they also aren't just abandoning the teams to figure it out alone.

Speaker 15:57

Exactly. They are actively creating the specific conditions where diverse perspectives, like the product manager who gets the user pain, the engineer who knows the database constraints, the designer who understands the workflow can align naturally to negotiate a trade-off.

Speaker 1 16:13

But you know, this transition from control to conditions, it brings up a massive area of friction.

Speaker 16:18

A huge friction.

Speaker 1 16:19

Because you're asking traditional leaders to just abandon the very tools that got them promoted in the first place.

Speaker 16:24

Right. You're asking them to rely on influence rather than formal authority.

Speaker 1 16:28

And relying on positional power, saying, do this because I'm the vice president of engineering. I mean, sure, it might get immediate compliance, but it completely destroys engagement.

Speaker 16:37

Aaron Ross Powell Because when a leader relies on formal authority, they are implicitly telling the team, your judgment is secondary to my rank.

Speaker 1 16:45

Right. If an executive walks into a room and says, rewrite this legacy system using this specific new framework, they have entirely shut down the team's autonomy.

Speaker 16:55

They've turned highly paid, highly intelligent problem solvers into simple order takers.

Speaker 1 17:01

Which is such a waste of talent.

Speaker 17:03

It is. The harmonic leader, operating through influence, uses questions to reveal strategic intent and illuminate risks instead.

Speaker 1 17:11

So what does that actually sound like in practice? How do you influence a major architectural rewrite without just, you know, ordering it?

Speaker 17:18

Instead of dictating the solution, the leader interrogates the constraints. They might look at the current legacy system and ask the team if we continue to patch this platform at our current velocity, what long-term constraints are we permanently building into our product?

Speaker 1 17:33

How will this architecture affect our ability to scale into the European market next year?

Speaker 17:38

Exactly. That fundamentally reframes the problem. You aren't telling them to rewrite the code, you are presenting them with a business reality.

Speaker 1 17:46

The European expansion.

Speaker 17:47

Right. And you're asking them to evaluate their technical foundation against that reality.

Speaker 1 17:51

It invites the engineers to elevate their thinking.

Speaker 17:54

It forces them to own the trade-offs. If they conclude that the legacy system will fail under the load of a European expansion, they will be the ones to propose the rewrite.

Speaker 1 18:05

And because they proposed it based on a business constraint, they own the execution of it entirely differently than if it had been a top-down mandate.

Speaker 18:14

Night and day difference.

Speaker 1 18:15

I have to interject here, though, because there is a very pragmatic objection that comes up constantly when we talk about this.

Speaker 18:21

Let's hear it.

Speaker 1 18:22

If leaders are stepping back, asking open-ended Socratic questions and dismantling their control mechanisms, aren't we just opening the door to total chaos?

Speaker 18:32

The Wild West.

Speaker 1 18:33

Right. How do you prevent a scenario where three different agile teams choose three completely different cloud providers and build completely incompatible architectures just because they're quote unquote empowered?

Speaker 18:46

That is the single most common fear surrounding agile adoption. And honestly, it is entirely valid if Agile is implemented poorly.

Speaker 1 18:54

So what's the answer?

Speaker 18:55

The answer to that fear is not total unconstrained freedom. The answer is structured autonomy. It is autonomy with accountability.

Speaker 1 19:05

So guidelines.

Speaker 19:06

Exactly. For a system to function without devolving into chaos, true autonomy requires three highly specific structural conditions to be present and maintained.

Speaker 1 19:16

Okay, let's break down the mechanics of those three conditions for the listener. What is the first pillar?

Speaker 19:21

The first condition is absolute clarity of goals and strategic intent.

Speaker 1 19:26

Without a universally shared understanding of what success actually looks like and why has success matter to the company, autonomy is just confusion.

Speaker 19:35

Precisely. If team members do not understand the broader business strategy, they will locally optimize for their own preferences, which is exactly how you end up with incompatible architectures.

Speaker 1 19:45

The leader's job is to ruthlessly communicate the why and the what, leaving the how to the team.

Speaker 19:50

Yes. The second condition, which gets talked about a lot but is rarely implemented correctly, is psychological safety.

Speaker 1 19:57

Right, psychological safety. We'll explore the deep mechanics of safety later, but at its core, if a team fears reprisal or punishment or public humiliation for making a well-reasoned mistake.

Speaker 20:09

They will never take ownership of a decision. In the absence of safety, a team will always revert to waiting for explicit orders just to protect themselves. Okay, and the third condition: clear decision-making frameworks and boundaries.

Speaker 1 20:22

Establishing the playing field.

Speaker 20:23

Exactly. Teams need explicit clarity on the boundaries of their authority. They need to know which decisions they can make entirely locally, which decisions require consultation with other teams, and which decisions genuinely require executive alignment.

Speaker 1 20:39

And when those boundaries are well designed, the team moves incredibly fast within their domain.

Speaker 20:44

They do. And if we view this through the lens of Tom, we can diagnose the health of an organization by looking at what happens when those boundaries fail.

Speaker 1 20:53

Right. Because in a traditional corporate hierarchy, when a team hits an obstacle or faces a tough trade-off, the standard procedure is to just escalate the decision up the chain of command.

Speaker 21:03

And a lot of companies view this as a healthy sign of respect for executive authority. We better run this up the flagpole to the VP.

Speaker 1 21:10

But in the harmony operating model, chronic escalation is viewed as a systemic design smell.

Speaker 21:16

A glaring indicator that the operating environment is broken.

Speaker 1 21:20

If highly paid, capable teams are constantly escalating routine product or architectural decisions up to a steering committee, what does that actually tell us?

Speaker 21:29

It tells us one of two things. Either the decision boundaries are so ambiguous that the team doesn't actually know what they're allowed to do.

Speaker 1 21:37

Or the cultural system implicitly rewards permission seeking over active learning.

Speaker 21:43

Exactly. It means the environment is forcing the team to seek political cover rather than make a choice based on data.

Speaker 1 21:50

The steering committee just becomes a risk laundering mechanism.

Speaker 21:53

I love that phrase.

Speaker 1 21:59

Right. But if the Environmental conditions, clarity, safety, boundaries are set up correctly, a team should almost never need to escalate.

Speaker 22:06

Unless they are facing a true boundary crossing crisis, this requires a change in strategic funding or a massive shift in the overall business model.

Speaker 1 22:15

Now, if we successfully build this environment, if we give teams this structured autonomy and the conditions to make decisions close to the work, it forces a massive secondary shift.

Speaker 22:25

We have to completely change how we judge if they are actually succeeding.

Speaker 1 22:29

Because if you change the system of work to be agile, but you keep the traditional measurement systems like county lines of code or measuring story points, the system will inevitably snap back to the old behaviors.

Speaker 22:41

It's the battle of outputs versus outcomes.

Speaker 1 22:44

Matt provides a brilliant, really concrete example of the engineering leadership book to illustrate this shift.

Speaker 22:49

The tale of two teams.

Speaker 1 22:50

Right. Let's analyze two hypothetical teams operating within the same company. We have Team A. Over the course of a single quarter, Team A operates like a machine.

Speaker 22:59

They ship 10 brand new, highly complex features. They are burning through story points at a record pace.

Speaker 1 23:05

Their velocity graph is pointing straight up and to the right. To a traditional PMO, Team A is the crown jewel of the engineering department.

Speaker 23:14

They are the heroes. But let's look at the actual impact of those 10 features.

Speaker 1 23:18

Post-launch analytics reveal that half of those features go completely unused by the customer base. And the other half. They introduce massive new cognitive load for the users, and the core pain points that customers were actually complaining about remain entirely untouched.

Speaker 23:34

So team A is highly efficient, but they are highly efficient at producing the wrong things.

Speaker 1 23:39

Exactly. Now we examine Team B. Over that same three-month quarter, team B only ships three relatively small improvements.

Speaker 23:47

If you look at their output on a traditional spreadsheet, their velocity looks absolutely terrible.

Speaker 1 23:51

They spent weeks writing no new code at all. Instead, they were conducting user interviews, prototyping, and running A-B tests.

Speaker 23:58

But those three small improvements directly targeted the most severe user friction point.

Speaker 1 24:03

Then as a direct result of those three releases, customer support tickets drop by 40% and user retention spikes.

Speaker 24:09

So the question for you listening is obvious. Which team is actually successful?

Speaker 1 24:14

Because if you promote the manager of team A, you're actively destroying your product's value, even though their spreadsheets look perfect.

Speaker 24:21

This contrast highlights a profound shift in perspective. Team A represents the pipeline mindset.

Speaker 1 24:28

Right, pipelines. They optimize for predictability and volume.

Speaker 24:31

A pipeline takes a set of upfront requirements, turns them into code as fast as possible, and pushes them out the door. It measures success by volume, speed, and adherence to the initial plan.

Speaker 1 24:42

And a pipeline assumes the upfront requirements were perfectly correct, which we know from the 3,000-page spec discussion is almost never true.

Speaker 24:50

Never, exactly. The Tom concept introduces the antidote to the pipeline, the product loop.

Speaker 1 24:56

Where pipelines optimize for predictability, loops optimize for learning.

Speaker 25:00

The mechanics of the Tom products loop involve three distinct continuous phases: discovery, delivery, and validation.

Speaker 1 25:07

Let's break down the mechanics of that loop for everyone because it requires a fundamentally different cadence of work.

Speaker 25:13

Okay, so in a loop, a team identifies a problem in the discovery phase. They hypothesize a solution. Then in delivery, they build the smallest possible increment of that solution to test the hypothesis.

Speaker 1 25:26

But the critical phase, the one that traditional companies almost always skip, is validation.

Speaker 25:32

Yes. The team releases the increment, gathers empirical evidence on whether it actually changed user behavior or solved the problem, and then structurally feeds that learning back into the very next discovery cycle.

Speaker 1 25:45

And the mechanical consequence of running a product loop is that it might feel significantly slower at first.

Speaker 25:50

You have engineers sitting in on user interviews instead of typing on their keyboards. To a traditional manager, that looks like wasted capacity.

Speaker 1 25:57

Right. Why aren't they coding?

Speaker 25:59

It does slow down the initial delivery of raw code, but it dramatically increases the probability that the right thing is actually being built.

Speaker 1 26:06

But the danger occurs when an organization is placed under severe market pressure, right?

Speaker 26:10

Oh, absolutely. When revenue dips or a competitor launches a new product, what happens? The organization panics.

Speaker 1 26:17

Exploration and discovery are immediately shortened.

Speaker 26:20

The validation feedback loop is completely deferred or ignored because uh we don't have time to measure, we just need to ship.

Speaker 1 26:27

And the teams instinctively revert to pipeline behaviors, turning out output metrics, because motion feels like progress.

Speaker 26:36

And the word value gets thrown around constantly, but it devolves into a hollow corporate buzzword rather than an experienced reality for the customer.

Speaker 1 26:44

But the reality is that achieving true outcomes, like team B reducing support tickets by 40%, is not something an engineering team can accomplish in total isolation.

Speaker 26:53

No, writing elegant code doesn't matter if the design is incomprehensible or the business model is flawed.

Speaker 1 26:59

Right. We have to look at how agile leadership breaks down entrenched silos and creates harmony across the entire business ecosystem.

Speaker 27:06

Which brings us to the core of the harmony model that Matt outlines. For a product to truly succeed in a complex market, for an outcome to be genuinely achieved, four distinct high-friction conversations must happen simultaneously and continuously within the team.

Speaker 1 27:21

The four harmonic conversations. Let's lay out the mechanics of each one because this is where the theory really hits the road.

Speaker 27:27

Okay, so the first is the value conversation, traditionally championed by product management. The core questions here are: what specific problem are we trying to solve? Who are we solving it for? And is this problem actually worth solving compared to all the other problems we could tackle? Right.

Speaker 1 27:44

The second conversation is feasibility, which is championed by engineering. The questions shift to how can we build this using our current architecture? Can we build it sustainably? Will it scale under load? And what technical debt will we incur if we rush it?

Speaker 27:58

The third is usability led by design. The focus here is can the user actually navigate the solution? Does it match their mental model? Is the friction low enough that they will actually adopt it?

Speaker 1 28:09

And finally, the fourth conversation is viability, championed by business or commercial stakeholders.

Speaker 28:15

Right. The defining questions are: does this solution make strategic and commercial sense for our company? Does it align with our revenue models, our legal constraints, and our long-term brand strategy?

Speaker 1 28:25

And the danger of imbalance among these four conversations is incredibly real.

Speaker 28:30

Oh, yeah. If you look closely at any failed digital product, you can usually diagnose exactly which conversation was missing.

Speaker 1 28:38

Oh, totally. I've seen scenarios where you have a team with incredibly strong design and product voices, but they actively exclude the business and engineering viability conversations until the very end.

Speaker 28:51

They spend six months designing beautiful, avant-garde, pixel-perfect interfaces.

Speaker 1 28:56

And then when they finally hand it over, the engineers point out that it requires real-time data streaming that the legacy database just cannot support.

Speaker 29:05

And the business points out that the feature costs more in server compute than the customer pays in subscription fees.

Speaker 1 29:10

It's a disaster. Or you see the exact reverse. You have an incredibly strong product voice dominating a submissive engineering function.

Speaker 29:18

Product outlines a highly ambitious intent and demands it by Q3.

Speaker 1 29:22

And because the feasibility conversation wasn't given equal weight, the engineers just stay silent about the architectural limitations. They hack the solution together, destroying the platform's stability.

Speaker 29:32

It's a classic case of intent moving completely without capability.

Speaker 1 29:36

Matt uses an incredibly relatable analogy for this: the two case and the journey, to explain why establishing shared mental models across these four domains is so critical.

Speaker 29:46

I love this analogy.

Speaker 1 29:48

He suggests imagining a scenario where you gather a group of friends representing product, engineering, design, and business, and you announce, hey everyone, we're going on a trip next week.

Speaker 29:59

And everyone in the room smiles, nods, and voices their absolute agreement. Looking around that room, there appears to be total alignment. There is zero conflict.

Speaker 1 30:08

It is the perfect illusion of alignment. It is what happens at the end of most corporate kickoff meetings.

Speaker 30:13

Exactly. But then the meeting ends and everyone goes home to pack their suitcases.

Speaker 1 30:18

The designer, imagining a tropical vacation, packs a swimsuit and sunscreen.

Speaker 30:22

The engineer, anticipating an intense mountaineering expedition, packs a heavy parka, climbing gear, and snow boots.

Speaker 1 30:30

Right. They all heard the exact same words, we are going on a trip. But because they didn't interrogate the constraints, the climate, or the destination together, they interpreted the directive entirely differently.

Speaker 30:41

If product, engineering, design, and business aren't engaging in those four harmonic conversations early and often, the entire system fails the minute they open their suitcases at the airport.

Speaker 1 30:51

So what's the mechanical solution to this misalignment?

Speaker 30:55

Individuals must step out of their traditional functional silos. An engineer cannot simply be a passive ticket taker waiting at the end of a waterfall process for a product manager to hand them a fully formed requirement.

Speaker 1 31:07

To achieve harmony, engineers need to learn to think and speak like product leaders.

Speaker 31:12

Designers need to understand business viability. Product managers need to understand technical debt.

Speaker 1 31:18

What does that translation actually sound like in the real world? Like how does an engineer elevate a technical constraint into a harmonic business conversation?

Speaker 31:26

It requires a fundamental shift in framing. Consider a common scenario. The engineering team realizes the core database needs a massive refactoring. In a siloed environment, the lead engineer goes to a business stakeholder and says, we have to pause all new feature development for the next three sprints because the schema in the legacy database is messy, our queries are slow, and we need to migrate to a new ORM.

Speaker 1 31:52

To a business stakeholder whose bonus is tied to launching new features, that just sounds like a purely inward-facing, self-indulgent technical delay.

Speaker 32:02

They will immediately reject it and demand the team keep building features on the broken database.

Speaker 1 32:07

Right. The conversation fails because it completely lacks viability and value.

Speaker 32:12

Precisely. Now consider the harmonic approach. The engineer frames the exact same technical reality in terms of business outcomes. How do they say it? They say, we have identified that our current database architecture is causing our checkout page to load in 4.5 seconds. Our analytics show that this latency is directly causing a 15% cart abandonment rate. If we allocate the next two sprints to refactoring this database, we can reduce page load times to under one second, which projected data suggests will recover a million dollars in loss revenue this quarter.

Speaker 1 32:43

Wow. That is a masterclass in translation.

Speaker 32:45

Right. The engineer has directly connected feasibility, the database refactor to usability page load time and viability recovered revenue.

Speaker 1 32:54

No rational business stakeholder reject that proposal.

Speaker 32:56

Exactly. But you know, this level of alignment is relatively easy to achieve with a single high-performing team of eight people.

Speaker 1 33:04

Right. The profound challenge arises when we try to scale this.

Speaker 33:07

What happens when an organization has 50 of these cross-functional teams? Scaling is where the agile dream so often metastasizes into an absolute bureaucratic nightmare.

Speaker 1 33:17

And the anti-patterns of scaling agile are deeply ironic. An organization looks at their slow delivery, decides they need to be more agile at a massive scale, and their instinctive reaction is to reach for traditional heavy control mechanisms.

Speaker 33:30

To manage the 50 teams, they add massive new layers of process.

Speaker 1 33:34

They introduce portfolio management boards, overlapping backlogs, endless cross-team dependency mapping meetings, and incredibly rigid, heavy frameworks.

Speaker 33:43

It is the instinct to manage complexity by adding complication. We see this vividly in how Matt critiques heavily prescriptive frameworks like SAFE, the scaled agile framework.

Speaker 1 33:54

Now, it is important to acknowledge why these frameworks exist.

Speaker 33:57

Sure. For a chaotic, massive legacy enterprise, a framework like SAFE provides a rigid structure that can feel like a life raft. It gives them a common vocabulary.

Speaker 1 34:07

But Matt points out the severe mechanical flaws in how they are typically implemented.

Speaker 34:12

Right. Because in trying to align everyone, these frameworks often break the very autonomy they are supposed to scale.

Speaker 1 34:19

They introduce micromanagement disguised as quote-unquote alignment ceremonies.

Speaker 34:25

Crucially, they tend to take the actual empowerment and decision-making authority away from the teams doing the work and move it upward into heavy governance and portfolio steering committees.

Speaker 1 34:36

You end up with engineers spending three days a month in massive PI planning events, trying to predict their output for the next quarter.

Speaker 34:43

Which is just the illusion of certainty wrapped in agile terminology.

Speaker 1 34:46

Matt even references companies like MasterCard, who actually had to embark on a journey of actively moving away from heavy, prescriptive, safe implementations in order to strip away the bureaucracy and get back to true fluid agility.

Speaker 35:00

Using the Tom Guide, Matt explains this danger as the flaw of scaling too early.

Speaker 1 35:05

The scenario usually plays out like this: Leadership sees one pilot team doing incredibly well. They are running fast, making great decisions, operating in perfect harmony.

Speaker 35:16

And leadership thinks great, let's document their daily stand-up, their sprint length, and their Jiraboard layout, and mandate that all 50 teams copy that exact process tomorrow.

Speaker 1 35:26

That is the fallacy of copying the practice without copying the context.

Speaker 35:30

You can mandate that a team hold a 15-minute stand-up every morning, but you cannot copy and paste the deep psychological trust that the pilot team built over a year.

Speaker 1 35:40

You cannot copy the clear strategic intent they were given by a great leader. You cannot copy the explicit authority they were granted to make local decisions.

Speaker 35:48

When you force the practices without cultivating the environment, you just get cargo cult agile.

Speaker 1 35:53

True scaling should not mean scaling meetings, documents, and processes. It must mean scaling clarity, scaling learning, and scaling decision confidence across the organization.

Speaker 36:03

Exactly. I mean, scaling by adding bureaucracy is like trying to make a ship go faster by adding more captains and heavier anchors.

Speaker 1 36:11

Oh, I love that. And when scaling is done poorly, when you add layers of process and strip away local autonomy, the first casualty is almost always the underlying technology.

Speaker 36:21

Which brings us to a vital concept in Matt's work. Technical excellence is not an IT issue, it is a core leadership responsibility.

Speaker 1 36:30

This is one of the most profound paradigm shifts in the source material. We have to stop viewing technical debt as a moral failing of the engineering team.

Speaker 36:38

Messy code, fragile architectures, and slow deployment pipelines are not engineering failures. They are organizational outcomes.

Speaker 1 36:44

They are systemic signals indicating how the leadership team is designing the flow of work.

Speaker 36:48

Let's trace the mechanics of how an executive's demand for a feature directly creates a fragile database.

Speaker 1 36:54

Okay, let's break it down. It comes down to capacity and pressure, right?

Speaker 36:57

Exactly. Technical debt accumulates when leadership consistently and systemically prioritizes short-term feature delivery over a sustainable pace and long-term system health.

Speaker 1 37:07

If the business continually demands that a team ship feature after feature, and never grants the engineering function the time or capacity to maintain the foundations, upgrade the libraries, or refactor the rushed code, the system inherently becomes fragile.

Speaker 37:22

The code becomes messy because the operating environment forced it to be messy.

Speaker 1 37:26

The engineers didn't want to write bad code. They were simply responding to the incentives of a pipeline that only rewarded speed.

Speaker 37:33

It is the classic feature factory trap. Matt proposes a highly practical structural solution for avoiding this, which he calls the 3030-40 rule.

Speaker 1 37:43

This isn't just a philosophy, it's a hard capacity allocation model.

Speaker 37:46

It is a way to make the invisible work explicit. The rule suggests that a teen's capacity should be deliberately fractured.

Speaker 1 37:53

So 30% of the team's time and energy is protected for innovation, research, and exploring new capabilities.

Speaker 37:58

Right. Another 30% is rigidly dedicated to technical investments. This means refactoring, upgrading infrastructure, improving developer tooling, and paying down technical debt.

Speaker 1 38:09

And the remaining 40% is dedicated to building and delivering the customer-driven features that the business asks for.

Speaker 38:16

I can hear a traditional CFO screaming right now.

Speaker 1 38:25

Oh, the pushback on this model is intense. How does a leader defend that 30% allocation for technical debt?

Speaker 38:31

A harmonic leader defends it by explaining the compound interest of bad code and by framing technology as an enabler of flow.

Speaker 1 38:39

Right. If you push a team to spend 100% of their time on features, within a year, the code base will become so brittle that every new feature takes 10 times longer to build.

Speaker 38:49

You aren't getting 100% capacity. You are getting 10% capacity grinding through mud.

Speaker 1 38:53

By explicitly allocating that 30% for technical health, the engineering team doesn't have to secretly beg for time to fix the database. It is baked into the operating model.

Speaker 39:03

Using Tom, we see that the tools and the architecture shouldn't be obstacles to work. They should accelerate it. Flow is a primary design constraint for technology.

Speaker 1 39:11

If a team is burning out, working weekends, and constantly fighting fragile code and incredibly slow deployment pipelines, that is not a lack of personal resilience on the part of the engineers.

Speaker 39:23

That is a fundamental design failure of the leadership system. The leader has failed to provide the conditions for sustainable flow.

Speaker 1 39:30

Which brings us to the most deeply personal part of this deep dive. We have analyzed the system, the scaling anti-patterns, and the technical architecture.

Speaker 39:39

But what exact granular daily behaviors do agile leaders exhibit to actually make this work?

Speaker 1 39:46

Because it is one thing to sit in a boardroom and say, I'm going to design a better environment. And it is an entirely different thing to do it on a Tuesday afternoon when the servers are crashing, the CEO is yelling, and everything is on fire.

Speaker 39:56

Matt shares a remarkably revealing story in Tom about a leader who, despite having the best of intentions, simply could not let go when the pressure spiked.

Speaker 1 40:05

This was a leader who truly believed in the theory of autonomy.

Speaker 40:08

But during a critical project, a vital architectural decision was taking the team longer than expected. The deadline was looming. So the leader jumped into the team's working session to quote unquote help speed up the decision.

Speaker 1 40:22

They took over the whiteboard, outlined the solution, and drove the consensus.

Speaker 40:27

I think almost anyone who has ever managed a team can relate to that instinct. You see your team struggling, you know the answer, and you just want to unblock them.

Speaker 1 40:36

Right. So what is the actual harm in stepping in to help?

Speaker 40:39

The harm is entirely systemic. By stepping into that meeting and taking over the decision, the leader immediately redefined the boundary of autonomy.

Speaker 1 40:47

The leader accidentally taught the team a devastating lesson. Your autonomy is conditional.

Speaker 40:53

It only exists when the waters are calm. The minute there is real pressure, the boss will take the wheel.

Speaker 1 40:58

The psychological contract is completely broken.

Speaker 41:00

And the mechanical consequence of that broken contract is predictable. What will that team do the very next time they face a complex high-pressure decision?

Speaker 1 41:09

They will not struggle through it to find an innovative solution. They will preemptively escalate it to the boss.

Speaker 41:15

They will wait to be saved. The leader's well-intentioned help actually destroyed the team's decision-making confidence and permanently added themselves as a bottleneck in the system.

Speaker 1 41:26

This ties directly into the mechanics of psychological safety. We throw that term around a lot, usually equating it with being nice or polite.

Speaker 41:34

Matt makes a crucial penetrating distinction here. Psychological safety is structural, not cultural.

Speaker 1 41:40

It has nothing to do with having beanbag chairs in the break room or smiling warmly during Zoom meetings.

Speaker 41:46

It is entirely about system signals and tangible consequences. If a leader stands up in a town hall and verbally praises bold experimentation, but then structurally punishes, demotes, or fires an engineer who ran a well-reasoned experiment that happened to fail.

Speaker 1 42:02

The leader has structurally removed safety from the entire organization. The system listens to the firing, not the town hall speech.

Speaker 42:09

A massive part of this daily behavioral shift is how a leader handles incoming organizational pressure. A traditional leader acts as a conduit. When unrealistic demands arrive from the market or the board, the leader panics and simply dumps all those demands onto the team's backlog, telling them to work harder.

Speaker 1 42:28

But the harmonic leader acts as a shock absorber.

Speaker 42:31

They absorb the pressure, they pause, they force the business to make explicit trade-offs, and they aggressively protect the team's focus.

Speaker 1 42:39

A leader's true job is to separate urgency from importance. And that requires immense courage.

Speaker 42:45

So a big part of leadership is actually having the fortitude to look a powerful stakeholder in the eye and explicitly say, no, we are not doing that right now.

Speaker 1 42:53

Stating explicitly what will not be done is one of the most powerful and clarifying actions a leader can take.

Speaker 42:59

When a leader definitively kills a distracting initiative, it stops the team from hedging their bets. It eliminates the cognitive load of trying to keep a doomed project on life support, allowing the team to commit 100% of their energy to the real strategic priorities.

Speaker 1 43:13

Okay, if we have leaders behaving this way, if they're acting as shock absorbers, protecting focus, explicitly allocating time for technical excellence, and fostering structural psychological safety, how do we evaluate their performance?

Speaker 43:27

Because if we measure this new type of leader using old industrial age metrics, we are going to inadvertently incentivize a return to the old behaviors.

Speaker 1 43:36

We must recognize that measurement in an organization is never neutral. Metrics do not just passively observe reality, they actively shape it.

Speaker 43:45

This brings us back to Goodhart's Law. When a measure becomes a target, it ceases to be a good measure.

Speaker 1 43:51

If you measure a leader's success strictly by engineering velocity, how many story points their team burns down, or how many features they push to production, you are explicitly inside. Incentivizing that leader to pressure their team to ship bad code as fast as possible.

Speaker 44:04

You are incentivizing them to avoid complex, highly valuable architectural problems because solving those problems might slow down the velocity graph for a few weeks.

Speaker 1 44:14

So what are the new metrics? We have to move beyond tracking engineering busy work and align the metrics with actual business and systemic health.

Speaker 44:20

We transition to metrics that measure the flow of value and the stability of the system. We look at things like lead time for change. Mechanically, how quickly can the organization safely go from a validated idea to code running in production?

Speaker 1 44:34

We look at the DORA metrics: deployment frequency, mean time to recovery when things break, and change failure rate.

Speaker 44:41

Beyond engineering, we measure true business outcomes, customer retention, direct revenue impact, and operational efficiency. And critically, we measure the system's human sustainability by tracking developer experience and team health.

Speaker 1 44:55

In the Tom Principles, Matt emphasizes a critical rule about how this data is utilized. He states that data must be used as a feedback mechanism, not as a tool for surveillance.

Speaker 45:06

That distinction dictates the trust level of the entire organization. Mechanically, data should be reviewed and discussed exactly where the decisions are made with the teams themselves.

Speaker 1 45:15

If a team's lead time for change is slowing down, that data should help them diagnose a bottleneck in their deployment pipeline so they can fix it.

Speaker 45:22

But if that exact same data is pulled upward to a centralized executive dashboard, simply so senior leadership can audit, judge, and punish the team from afar, the data becomes a weapon of surveillance.

Speaker 1 45:35

When teams feel surveilled, they will manipulate the data to protect themselves. The separation of learning conversations from evaluation conversations is absolutely critical for maintaining integrity in the system.

Speaker 45:47

We have covered an immense amount of ground today, unpacking the deep mechanics of the transition from control to conditions.

Speaker 1 45:53

Let's bring all these threads together and look at the ultimate destination of this journey. We are talking about building a future state where the organization runs on continuous harmony, and the leader's ultimate legacy isn't a string of heroic late-night saves, but the creation of a self-sustaining ecosystem.

Speaker 46:09

Matt has a beautiful, highly challenging thought on this legacy. He suggests that the ultimate goal of an agile leader is to actively make themselves less necessary over time.

Speaker 1 46:19

You are shifting your identity from being the indispensable hero who constantly jumps in to solve the daily crises to becoming the quiet steward of the operating system.

Speaker 46:28

You are tending the soil of the garden, ensuring the nutrients, the funding, the data, the safety are present rather than micromanaging the growth of every single leaf.

Speaker 1 46:37

In the final chapter of Product Agile Harmony, he paints a picture of what he calls the fully harmonized organization. And what strikes me most about this description is that it isn't louder or faster or full of frantic, chaotic startup energy. It is remarkably quieter, it is calmer, it is highly intentional.

Speaker 46:57

In a harmonized organization, people communicate with clear purpose, not out of panic or pressure. It doesn't mean it's a utopia without conflict.

Speaker 1 47:06

Tensions absolutely still exist because the external market remains complex and unforgiving.

Speaker 47:11

But those internal tensions between product wanting a feature and engineering wanting stability are handled as productive, data-driven trade-offs, not toxic interpersonal battles. Harmony isn't a temporary milestone you reach and lock into place. It becomes an ingrained capability, a muscle that the organization exercises naturally every single day.

Speaker 1 47:30

To wrap this incredible deep dive up, I want to leave you, the listener, with a few provocative questions to take back to your own teams, your own leadership meetings, and your own operating models. First, look closely at your incentive structures. Where are you asking teams to be agile, iterative, and outcome focused while your HR and finance departments are still rewarding traditional control-based leadership behaviors?

Speaker 47:55

Second, when market pressure rises in your company, and it always will, do decisions mechanically move closer to the teams doing the work, or do they immediately escalate upward, further away from the context?

Speaker 1 48:06

And finally, look at your dashboards. Are your metrics genuinely helping your teams learn how to build better products, or are they just teaching them how to manipulate data to protect themselves from executives?

Speaker 48:16

Those are the exact diagnostic questions that strip away the facade and reveal the true operating model of a company. And if I can add one final thought for everyone to mull over regarding their own leadership legacy, what if the true ultimate measure of your leadership isn't what your team manages to accomplish while you are in the room directing traffic, but the decisions they have, the courage, the context, and the safety to make when you are on vacation?

Speaker 1 48:41

That is a perfect note to end on. Thanks for listening to the Deep Dive on the Agile Product Hub. You can find more articles, books, and podcasts at agileproducthub.com. Until next time, keep making work clearer, calmer, and more connected.