Agile Roles Are Maturing Not Dying

In this episode of The Deep Dive, we explore one of the biggest tensions in modern agile and product organisations: are agile roles disappearing, or are they simply evolving?

Across many organisations, there is a growing narrative that roles such as Scrum Master, Product Owner, Engineering Leader, and specialist roles are no longer needed in the same way. Under pressure to simplify structures, cut cost, and move faster, some businesses are questioning whether these roles have become overhead.

This conversation takes a different view.

Rather than seeing these roles as outdated, this episode explores how they are maturing in response to a more complex organisational reality. As digital product work has grown beyond small co-located teams into distributed, cross-functional, AI-influenced environments, the demands on these roles have shifted. The challenge is no longer just about following frameworks or managing delivery activity. It is about enabling better decisions, supporting flow, aligning around value, and helping organisations work more coherently across product, engineering, business, and specialist disciplines.

In the episode, we discuss:

•  why so many organisations are rethinking agile roles right now 
•  the old, narrow view of roles such as Scrum Master, Product Owner, Engineering Leader, and specialists 
•  the real shift in what modern organisations need 
•  how Scrum Masters are evolving beyond facilitation into system enablement and organisational influence 
•  how product roles are moving beyond backlog management into strategy, discovery, and value shaping 
•  how engineering leaders are shifting from delivery oversight to enabling technical excellence and long-term value 
•  why specialist roles still matter, and how they are evolving from gatekeepers into embedded enablers 
•  what all of these roles now have in common 
•  where organisations still get it wrong, especially when structural and cultural problems are mistaken for role problems 
•  what the future of agile roles may look like as AI, hybrid work, and organisational complexity continue to grow 

This is not a framework debate or a defence of old job titles. It is a broader reflection on what healthy product and agile organisations actually need from the people working within them.

If you work in product, agile, engineering, delivery, transformation, or leadership, this episode offers a calm, practical, system-focused perspective on why agile roles are not dying, they are maturing.

Based on insights drawn from books by Matthew Coxall.

Transcript

Speaker 0:00

Welcome to the Deep Dive, a series on digital product and agile.

Speaker 1 0:04

Glad to be here for this one.

Speaker 0:05

Yeah. So whether you are, you know, a daily practitioner right in the trenches, or maybe a leader trying to steer a massive organization, or just wildly curious about how work actually gets done today, we have curated this deep dive specifically for you.

Speaker 1 0:20

Absolutely. It's a topic that affects basically everyone in the knowledge economy right now.

Speaker 0:25

Right. Because right now, in corporate hallways all around the world, there is this pervasive rumor.

Speaker 1 0:30

Oh, yeah, the whispers.

Speaker 0:32

Exactly. You've probably heard it in Slack channels or uh debated in executive boardrooms. The rumor is that Agile is dying.

Speaker 1 0:39

which is quite the dramatic statement.

Speaker 0:41

It is. And specifically that roles like the scrum master, the dedicated product owner, and embedded specialists are, well, they're being put on the chopping block in the name of corporate efficiency.

Speaker 1 0:53

Yeah. It is a very loud and frankly very anxious narrative out there right now.

Speaker 0:57

Oh, absolutely.

Speaker 1 0:57

You constantly hear executives saying things like uh we don't need that role anymore, or we're going lean, we're flattening the structure. Yeah. Right. But that narrative, I mean, it completely misreads the reality of what is actually happening within high-performing organizations.

Speaker 1:11

Yeah. And to really ground our conversation today, we are going to be leaning heavily on some fantastic material based on insights drawn from books by the author Matthew Coxel.

Speaker 1 1:23

Some really foundational work there.

Speaker 1:24

Yeah, completely. And just for the sake of our conversation today, we're going to simply refer to the author as Matt.

Speaker 1 1:31

Sounds good.

Speaker 1:31

So Matt has written extensively across the entire spectrum of product ownership, uh, engineering leadership, specialist collaboration, and delivery teams.

Speaker 1 1:41

Right, the whole organizational product system.

Speaker 1:43

Exactly. And our mission today is to essentially dismantle this myth. What if these roles aren't dying at all?

Speaker 1 1:51

Right. What if they're doing something else entirely? Yeah.

Speaker 1:53

What if instead they are mutating into the most powerful connective roles in the company?

Speaker 1 1:58

I love that framing.

Speaker 1:59

Okay, let's unpack this. We aren't looking at the death of roles, right? We are looking at the vital, necessary evolution of roles. Treating them as isolated job titles is just missing the entire point.

Speaker 1 2:11

I completely validate that mission. Yeah. And I think maths work provides the perfect lens for this. Yeah. Because what many organizations and leaders are uh misdiagnosing as role redundancy is actually a symptom of growing systemic complexity.

Speaker 2:27

Oh, that's a great way to put it.

Speaker 1 2:28

Yeah. We are moving through this massive painful shift from focusing on sheer output to focusing on actual value creation. Right. So treating these roles as isolated job titles on a spreadsheet.

Speaker 2:41

Like just moving boxes around.

Speaker 1 2:43

Exactly. It completely misses the point. You really have to look at the organizational ecosystem as a whole.

Speaker 2:48

Well, let's start with the big picture context then, the why now. Because you know, Agile has been around for over two decades.

Speaker 1 2:55

Right. We all know the manifesto by heart at this point.

Speaker 2:57

Yeah, exactly. So why is there suddenly this massive friction and redefinition happening right now? Why is the pressure cooker whistling today and not say five years ago?

Speaker 1 3:07

Well, this raises an important question. And honestly, it comes down to scale, environment, and cognitive load.

Speaker 3:14

Okay, break that down for me.

Speaker 1 3:16

So the original Agile frameworks, right? They were mostly designed for a single co-located IT team building software in a single room.

Speaker 3:25

Yeah, pizza-sized teams.

Speaker 1 3:26

Exactly.

Speaker 3:27

Yeah.

Speaker 1 3:27

But those boundaries have completely dissolved. I mean, Agile has scaled into massive distributed hybrid environments now.

Speaker 3:35

Right. It's everywhere.

Speaker 1 3:36

It's spread far beyond software engineering into HR, marketing, operations, finance.

Speaker 3:43

Yeah, that's a huge shift.

Speaker 1 3:44

You now have organizations trying to synchronize these really complex value streams across teams in Bangalore, London, and New York.

Speaker 3:52

All at the same time.

Speaker 1 3:52

Right. And then you add to that the rapid integration of artificial intelligence into our daily workflows.

Speaker 3:57

Oh, yeah. The AI factor.

Speaker 1 3:59

Exactly. The complexity factor has just skyrocketed. Modern organizations are wrestling with this need for cross-functional maturity at a scale that the original manifesto simply didn't map out.

Speaker 4:10

That makes total sense. I mean, the environment is infinitely more complex. But uh I have to play devil's advocate here for a second on behalf of the skeptical executive who might be listening.

Speaker 1 4:20

Fair enough, bring it on.

Speaker 4:21

If Agile is scaling so rapidly and we have all these amazing cloud-based collaboration tools now, why are so many people so incredibly frustrated with it?

Speaker 1 4:31

It's a very common feeling.

Speaker 4:32

Right. Like, are the frameworks themselves failing us? Or is it our understanding of the people running them that's broken?

Speaker 1 4:39

That is the perfect question to frame the problem.

Speaker 4:42

Because a lot of companies feel like they bought the really expensive Agile treadmill, but they aren't losing any weight.

Speaker 1 4:47

That's a great analogy. But the frameworks aren't inherently failing. The frustration you are feeling is tied to a severe lag in role maturity.

Speaker 4:56

Role maturity.

Speaker 1 4:57

Okay. The tools have changed, the scale of the organizations has changed, the hybrid nature of the work is different. But our mental models of the roles operating those frameworks haven't caught up at all.

Speaker 5:08

So we're stuck in the past.

Speaker 1 5:09

Exactly. We are using a 2024 tech stack with a 2010 mindset of what a scrum master or a product owner is supposed to be doing. Wow. It is essentially an industrial age mindset being applied to the knowledge economy.

Speaker 5:22

Because our mental models are lagging so far behind, we really need to drag those outdated stereotypes out into the light and examine them.

Speaker 1 5:30

We have to.

Speaker 5:31

Let's deconstruct this old view of agile roles and let's start with the scrum master. We all know the stereotype. Oh yeah. They're often viewed as the glorified calendar manager.

Speaker 1 5:42

Precisely. In the immature model, the scrum master is essentially an administrative assistant for the team.

Speaker 5:48

Just booking rooms and sending invites.

Speaker 1 5:50

Exactly. They are viewed as the ceremony facilitator, the person who enforces the daily stand-up and makes sure everyone updates their JIRA tickets.

Speaker 5:59

Right, like a compliance officer for the framework.

Speaker 1 6:01

That's exactly what it is. A compliance officer.

Speaker 6:03

Okay. And what about the product roles? You know, the product owner or product manager?

Speaker 1 6:07

In the old model, they are basically backlog administrators.

Speaker 6:11

Backlog administrators.

Speaker 1 6:12

Yeah. They sit between the business and the developers taking orders from the loudest stakeholders.

Speaker 6:16

So whoever shouts the loudest gets their feature built.

Speaker 1 6:19

Aaron Ross Powell Exactly. They just write user stories and feed the development team. They are order takers, translating business demands into technical tasks.

Speaker 6:27

without ever questioning it.

Speaker 1 6:29

Rarely. They almost never question the strategic value of the demand itself.

Speaker 6:33

Aaron Ross Powell Okay. Then you have the engineering leaders, the engineering managers or the tech leads.

Speaker 1 6:37

Right.

Speaker 6:38

In this outdated mental model, they are treated as delivery controllers. Trevor Burrus, Jr.: Trevor Burrus They oversee the deadlines, they crack the whip on velocity metrics, and they just make sure the code gets shipped on time.

Speaker 1 6:49

Yes. And their entire performance is judged by predictability and output.

Speaker 6:55

Like, did you deliver the features you promised by Q3?

Speaker 1 6:59

Exactly that. Not did those features actually solve a user problem.

Speaker 7:02

Which brings us to the specialists, you know, the architects, the UX designers, the business and data analysts.

Speaker 1 7:10

Uh yes. The classic Ivory Tower experts.

Speaker 7:13

Aaron Ross Powell Right. The Ivory Tower.

Speaker 1 7:14

Trevor Burrus In the old view, they sit completely outside the Agile team acting as gatekeepers.

Speaker 7:20

Just handing things down from on high.

Speaker 1 7:22

Yeah. They hand down massive architectural blueprints or exhaustive, pixel-perfect design files, toss them over the wall, and expect the development team to just execute them perfectly.

Speaker 7:32

No questions asked.

Speaker 1 7:33

Right. Or worse, they act as an approval choke point at the end of the process.

Speaker 7:37

Oh, that's the worst.

Speaker 1 7:38

They just reject work that doesn't meet their pristine standards.

Speaker 7:42

You know, when you lay it all out like that, it feels incredibly industrial.

Speaker 1 7:46

It really does.

Speaker 7:47

It reminds me of a 1920s factory assembly line. We've just swapped out the title Foreman for Strum Master. Yeah. And we've swapped out Requirements Document for JiraTicket.

Speaker 1 7:57

Exactly.

Speaker 7:58

But we have kept the exact same command and control, output-obsessed mindset.

Speaker 1 8:03

The conveyor belt just keeps moving.

Speaker 8:04

Right. And everyone's job is just to pull their lever faster.

Speaker 1 8:07

The assembly line is a really apt metaphor. But operating this way inherently violates the core principles of agile and knowledge work. How so? Well, what happens is that organizations turn their iterative sprints into mini waterfall cycles.

Speaker 8:23

Ah, mini waterfalls.

Speaker 1 8:24

Sure, they break the work down into two-week chunks, but the mindset is still focused entirely on volume.

Speaker 8:29

How many features did we ship? What was our velocity?

Speaker 1 8:32

Exactly. It values sheer output over actual user impact and business value. You are optimizing for busyness, not effectiveness.

Speaker 8:42

Right. And the friction caused by creating an agile team like an assembly line is exactly what is forcing organizations to wake up now. It has to. They are realizing that faster output isn't actually solving their business problems. And this is the catalyst for the real shift in what organizations actually need today.

Speaker 1 9:00

Matt's core argument across all his work is that organizations do not need isolated siloed roles executing tasks.

Speaker 9:07

They need something more cohesive.

Speaker 1 9:09

They need systemic alignment. They need a deep level of role maturity where there's a clearer purpose and much stronger collaboration.

Speaker 9:15

So getting away from the silos.

Speaker 1 9:16

Exactly. We have to shift from role silos to true systems thinking.

Speaker 9:21

Let's make that tangible for a second because I think the text perfectly illustrates this shift from volume to value.

Speaker 1 9:26

Go for it.

Speaker 9:27

Imagine you have two teams. Team A operates like a well-oiled feature factory.

Speaker 1 9:32

Okay, Team A.

Speaker 9:33

They deliver 10 brand new features in a single quarter. High velocity, everyone is typing furiously. The burn down chart looks perfect.

Speaker 1 9:42

They look great on paper.

Speaker 9:43

Right. But post-launch, the data shows that half of those features go completely unused by the customer. Ouch. The fundamental pain points of the product remain completely untouched. And now you just have a bloated code base.

Speaker 1 9:57

High output, negative value. Because those ten features now have to be maintained, updated, and navigated by the poor user.

Speaker 10:04

Exactly. Then you have team B. Team B takes a very different approach. Okay. They spend significant time in discovery, they push back on stakeholder requests, and they only deliver three features in that same quarter.

Speaker 1 10:16

Their velocity looks terrible on a traditional spreadsheet.

Speaker 10:18

Terrible. But those three specific, targeted improvements reduce customer turn by 40%.

Speaker 1 10:24

That's massive.

Speaker 10:25

It is. Organizations are finally realizing they don't need team A. They desperately need Team B.

Speaker 1 10:30

They do.

Speaker 10:30

But here's the problem. Executives are historically seduced by Team A.

Speaker 1 10:36

They're totally seduced by Team A because 10 features feel like a tangible return on investment.

Speaker 10:41

It feels like you're getting your money's worth.

Speaker 1 10:43

It feels like certainty. The executive signed a check and they got 10 shiny new buttons on the app.

Speaker 10:49

Right.

Speaker 1 10:50

Team B requires a leap of faith. It requires leaders to trust that slower output will actually lead to higher impact.

Speaker 10:58

So what does this all mean for the roles we are discussing? Well. If I am a listener and my company complains that our scrum masters are useless overhead or our architects are bottlenecks, how should I interpret that?

Speaker 1 11:10

You should interpret it as an organizational design problem, not a personnel problem.

Speaker 11:14

Oh, that's a huge distinction.

Speaker 1 11:16

It is. When a company complains about these roles, it is rarely the fault of the individual sitting in that seat.

Speaker 11:21

It's the system around them.

Speaker 1 11:23

Exactly. These dysfunctions are almost always caused by shallow, agile adoption.

Speaker 11:28

Where a company adopts the ceremonies but not the mindset.

Speaker 1 11:32

Right. They are caused by weak product thinking and a culture that is still obsessed with measuring success by output rather than outcomes.

Speaker 11:41

Yeah.

Speaker 1 11:42

If your company rewards people for shipping 10 features, you will get 10 mediocre features, regardless of how good your scrum master is.

Speaker 11:51

So true. So if the organization's needs have fundamentally shifted from basic assembly line execution to complex systems thinking, the roles at the center of the team have to evolve first.

Speaker 1 12:03

Yeah, have to. They cannot survive as mere cogs.

Speaker 12:06

We have to start with the scrum master then. Let's look at how this role is shedding that administrative skin.

Speaker 1 12:11

It's a big change.

Speaker 12:12

How do you go from being the meeting booker to a system optimizer?

Speaker 1 12:16

The evolution of the Scrum Master is profound. It starts with moving far beyond the mechanical mechanics of the framework.

Speaker 12:22

Give me an example.

Speaker 1 12:23

Take the Daily Scrum, for instance. In the old model, the Scrum Master asks the three classic questions What did you do yesterday?

Speaker 12:29

What are you doing today? And are there blockers?

Speaker 1 12:32

Exactly. And it is treated as a status report to management.

Speaker 12:35

Right, which everyone hates because it just feels like a micromanagement roll call.

Speaker 1 12:39

Nobody likes it. But the text points out that in an evolved model, the Daily Scrum is a collaborative daily planning session owned by the developers.

Speaker 12:48

Owned by the developers.

Speaker 1 12:50

Yes. The Scrum Master's role isn't to take role, it's to observe the system.

Speaker 12:55

What are they observing exactly?

Speaker 1 12:56

They are listening for unspoken dependencies. They are watching the flow of work and asking why things are getting stuck, not just what is stuck.

Speaker 13:05

Ah, getting to the root cause.

Speaker 1 13:07

Exactly. They are evolving into true organizational change agents.

Speaker 13:12

Let's dig into that because organizational change agent can sound like a bit of a buzzword.

Speaker 1 13:16

It can, yeah.

Speaker 13:17

What does that actually look like in practice?

Speaker 1 13:19

It looks like managing team contracts and fostering psychological safety.

Speaker 13:23

Psychological safety is huge right now.

Speaker 1 13:26

It is. It means stepping in when a developer is afraid to admit they don't understand the legacy code.

Speaker 13:32

Which is secretly causing a massive delay.

Speaker 1 13:34

Right. The evolved scrum master creates an environment where that vulnerability is acceptable, allowing the team to swarm the problem instead of hiding it.

Speaker 13:44

They make it safe to say, I don't know.

Speaker 1 13:46

Exactly. They are the critical bridge between the product vision and the technical execution.

Speaker 13:51

And this requires incredible adaptability, especially with hybrid work.

Speaker 1 13:55

Well, hybrid work changes everything.

Speaker 13:57

The text gives a great tangible example of a scrum master navigating a distributed team across three different time zones.

Speaker 1 14:04

I love that example.

Speaker 14:05

In the old model, you just hop on a conference call, people multitask, and nothing really gets resolved.

Speaker 1 14:10

Someone's dog is barking in the background.

Speaker 14:12

Exactly. But this Evolved Scrum Master introduced a virtual Miro whiteboard pre-populated with systemic data to run asynchronous and synchronous retrospectives.

Speaker 1 14:23

Yes. And the impact of that goes far beyond just using a new tool.

Speaker 14:26

How so?

Speaker 1 14:27

By enabling real-time visual collaboration, the Scrum Master dramatically increased participation from introverted team members.

Speaker 14:34

That's a great point. Not everyone wants to speak up on a massive Zoom call.

Speaker 1 14:39

Right. And it generated actionable insights that actually improved their workflow across geographic barriers.

Speaker 14:45

So it wasn't just talk.

Speaker 1 14:46

No, it was advanced facilitation. Right. That is adding systemic value, not just checking a box on a calendar.

Speaker 14:53

Okay, here's where it gets really interesting and where a lot of the current anxiety comes from. We have to talk about AI.

Speaker 1 14:59

Oh boy. Artificial intelligence. Trevor Burrus, Jr.

Speaker 15:01

Yeah, AI is entering the chat. And it is now capable of automating backlog refinement, tracking velocity metrics, analyzing sprint trends.

Speaker 1 15:09

Even generating meeting notes and action items.

Speaker 15:12

Aaron Ross Powell Exactly. So I can hear the skeptical executive again.

Speaker 1 15:15

What are you saying now?

Speaker 15:16

They're saying if AI can track the brindown chart and summarize the retrospective, what do we need a scrum master for? Why am I paying a human salary for this?

Speaker 1 15:26

It's a completely valid fear if you still view the role as purely administrative.

Speaker 15:31

Right.

Speaker 1 15:32

If your only job is updating JIRA, yes, AI will absolutely replace. But the reality is that AI frees up the scrum master to do their actual job. It elevates the role.

Speaker 15:42

Okay, tell me more about that.

Speaker 1 15:43

Matt gives a brilliant example of a scrum master who used an AI-powered tool to analyze strint velocity trends.

Speaker 15:50

l What did the AI find?

Speaker 1 15:52

The AI dug through months of data and identified a hidden pattern. User stories involving a specific legacy database always took three times longer than estimated.

Speaker 16:03

Wow, causing cascading delays everywhere.

Speaker 1 16:06

Exactly. So the AI found the anomaly in the data.

Speaker 16:08

But the AI can't fix the legacy database.

Speaker 1 16:12

No, and it definitely can't fix the team's avoidance of it.

Speaker 16:15

Right.

Speaker 1 16:15

Precisely. The AI did the math, but the Scrum Master facilitated the human change.

Speaker 16:20

How to do that?

Speaker 1 16:21

The Scrum Master took that data, brought it to the team, and uncovered that the developers were avoiding the database because the original architect had left and they were terrified of breaking it.

Speaker 16:31

Oh wow. So it was a fear issue, not just a tech issue.

Speaker 1 16:33

Exactly. The Scrum Master then worked with engineering leadership to create a dedicated innovation spike to map and refactor that database. That's amazing. By letting the AI handle the data crunching, the team was able to address a deeply rooted psychological and technical issue, ultimately reducing their cycle time by 15%.

Speaker 16:53

That is a perfect example. When AI absorbs the mechanical tracking, the scrum master can focus entirely on advanced human facilitation.

Speaker 1 17:01

Resolving complex team conflicts, coaching the organization.

Speaker 17:05

Dealing with the psychological aspects of team dynamics that an algorithm simply cannot navigate. Oh, I love that. AI gives the x-ray, the human does the surgery.

Speaker 1 17:17

Exactly.

Speaker 17:18

And with the scrum master handling the system flow and the health of the team, the direction of that flow where the team is actually going must be guided by someone who truly understands value.

Speaker 1 17:28

Which leads us perfectly into the evolution of product roles.

Speaker 17:32

The shift here is just as dramatic and perhaps even more difficult because of corporate politics.

Speaker 1 17:37

Oh, the policies are intense in this space.

Speaker 17:39

We are moving from the product owner as a backlog administrator to a true visionary. They are shifting from taking orders from the loudest stakeholder in the room and simply writing tickets to actively shaping the business strategy and defining the why behind the product.

Speaker 1 17:55

It's a huge mindset shift.

Speaker 17:57

It's the difference between being a waiter taking orders at a restaurant versus being the head chef designing the menu.

Speaker 1 18:04

That is a great analogy. The waiter doesn't ask the customer if a steak pairs well with a motion.

Speaker 18:09

They just write it down.

Speaker 1 18:10

They just write it down. A backlog administrator just writes down whatever the VP of sales demands.

Speaker 18:15

Right.

Speaker 1 18:16

But an evolved product owner uses data to push back.

Speaker 18:21

They actually push back.

Speaker 1 18:22

They use opportunity solution trees and cost of delay metrics to prove that building feature X right now will actually hurt the company's long-term strategy.

Speaker 18:31

But let's be real for a second. Pushing back on a VP of sales sounds like a great way to get fired.

Speaker 1 18:36

It really does.

Speaker 18:36

How does a product owner actually survive this transition? How do they say no without causing an organizational meltdown?

Speaker 1 18:43

This is where the critical partnership between the product owner and the scrum master comes in. They cannot operate in silos. Think of a scenario where a product owner is under immense pressure from a major client to deliver a custom feature faster.

Speaker 18:57

And the client is threatening to churn if they don't get it.

Speaker 1 18:59

Exactly. The traditional reaction is for the product owner to panic, bypass the backlog, and start assigning work directly to developers.

Speaker 19:07

Completely destroying the Sprit focus.

Speaker 1 19:09

And tanking team morale in the process.

Speaker 19:12

Which turns them right back into Team A, the feature factory.

Speaker 1 19:15

Exactly. But in an evolved system, the Scrum Master steps in.

Speaker 19:19

To do what? Scold the product owner?

Speaker 1 19:21

No, not to scold them, but to partner with them. The Scrum Master protects the boundary of the team, making the cost of context switching visible to the organization.

Speaker 19:30

Ah, showing them the real cost.

Speaker 1 19:33

Meanwhile, the product owner uses data-driven insights, often aided by AI, to analyze the client's actual usage data.

Speaker 19:40

But what if the client is wrong about what they need?

Speaker 1 19:43

That's usually what happens. They might discover the client isn't actually using the existing features properly. And what they need is better onboarding, not a new custom button.

Speaker 19:52

So they solve the actual problem.

Speaker 1 19:54

The product owner manages the stakeholder relationship with facts, while the scrum master ensures the system can sustainably deliver on the real need.

Speaker 20:03

It's a dynamic duo. The product owner brings the market and business context, and the scrum master ensures the system can sustainably deliver on it.

Speaker 1 20:11

It's a beautiful partnership when it works.

Speaker 20:13

The product owner has to navigate that stakeholder alignment, proving with facts and user feedback why Team B's three features are more valuable than Team A's ten features.

Speaker 1 20:23

But a great vision and a healthy, psychologically safe team mean absolutely nothing if the technical execution is unsustainable.

Speaker 20:32

That's a subering thought.

Speaker 1 20:33

You can have the best product strategy in the world and the best scrum master protecting the team. But if the code is built on a house of cards, it will inevitably collapse under its own weight.

Speaker 20:42

Which brings us to the evolution of engineering leaders.

Speaker 1 20:45

Yes.

Speaker 20:46

I find this transition to be the most fascinating and frankly the most personally difficult for the individuals involved.

Speaker 1 20:53

It is incredibly tough on a personal level.

Speaker 20:55

You are talking about tech leads and engineering managers who usually got to their position because they were the best, fastest, smartest coders in the room.

Speaker 1 21:04

They were the hero developers.

Speaker 21:06

Right, the ones who solve the hardest problems at 2 a.m.

Speaker 1 21:09

It is a profound identity crisis for them. Moving from traditional management to agile leadership means moving from the person who solves the problems and tracks the code commits to the enabler who creates autonomous teams.

Speaker 21:22

They have to step back.

Speaker 1 21:23

You have to let go of control. You are no longer responsible for doing the work.

Speaker 21:27

Right.

Speaker 1 21:28

You are responsible for creating the conditions where others can do their best work.

Speaker 21:32

But if I'm an engineering manager whose end-of-year bonus is tied to shipping X amount of code this quarter, letting go of control sounds like career suicide.

Speaker 1 21:41

It feels incredibly risky.

Speaker 21:43

If I step back and let the team figure it out and they fail, I'm the one who gets in trouble. How does Matt suggest that they actually survive that transition?

Speaker 1 21:50

It requires them to stop speaking purely in technical jargon and start thinking like a product leader.

Speaker 21:56

Speak the language of the business.

Speaker 1 21:58

Exactly. They have to change. How they communicate risk and investment to the wider business. I love the example from the text about translating technical debt into business value.

Speaker 22:08

How does that work?

Speaker 1 22:09

In the old view, an engineering leader might go to the executive team and say, we have to pause feature development for three weeks because we need to refactor the database and update our API endpoints.

Speaker 22:21

And the business executives roll their eyes, deny the request, and say, That sounds like an IT problem. We have a marketing launch next month. Just make it work.

Speaker 1 22:30

Because the engineering leader spoke to them in a language they don't value.

Speaker 22:33

Right. They don't care about APIs.

Speaker 1 22:35

But an evol an evolving engineering leader frames it completely differently.

Speaker 22:38

What do they say?

Speaker 1 22:39

They say, our current architecture is causing a four-second delay on the checkout page. If we invest three weeks in modernizing this system, we will reduce page load time by 30%, which data shows will increase our e-commerce conversion rates by 5% and significantly reduce customer churn.

Speaker 22:57

Wow. Suddenly the business is listening.

Speaker 1 23:00

Absolutely.

Speaker 23:01

They aren't hearing refactoring, they are hearing increased revenue.

Speaker 1 23:04

They are speaking the language of value, not just technical velocity.

Speaker 23:08

And that translation is essential for balancing innovation and delivery. This is where the concept of dual track agile comes in.

Speaker 1 23:15

Yes, dual track agile is key here.

Speaker 23:17

An evolved engineering leader advocates for innovation spikes and dedicated time for foundational work.

Speaker 1 23:23

They have to carve out that space.

Speaker 23:40

That's perfect. But to achieve that long-term architectural health, the engineering leader and the team need incredibly deep specialized expertise.

Speaker 1 23:49

They really do.

Speaker 23:49

Which is the perfect segue to what is arguably the most misunderstood group in the entire agile ecosystem the specialists.

Speaker 1 23:57

The architects, the UX designers, the business analysts, the data scientists.

Speaker 24:02

Yeah, these roles often feel the most alienated by basic agile frameworks.

Speaker 1 24:07

They really do. It's a common struggle.

Speaker 24:08

And we have to tackle this generalist myth head on.

Speaker 1 24:12

Oh, let's talk about the myth.

Speaker 24:14

There is a pervasive, almost dogmatic idea in early agile transformations that a truly cross-functional team must be made entirely of full stack generalists.

Speaker 1 24:25

It's everywhere.

Speaker 24:26

The myth is that everyone on the team should be able to code, test, design the interface, and analyze the data.

Speaker 1 24:33

Which is absurd.

Speaker 24:34

And therefore, specialists are no longer needed, or they are viewed purely as bottlenecks who slow the generalists down.

Speaker 1 24:40

It is a dangerous myth, and it leads to incredibly mediocre products.

Speaker 24:45

How so?

Speaker 1 24:46

The text is very clear that while cross-functional teams are the goal, treating everyone as a generalist is not scalable and it is not sustainable in a complex environment.

Speaker 24:56

Because nobody can be an expert at everything.

Speaker 1 24:58

Exactly. You do not want a back-end developer guessing at human-computer interaction principles.

Speaker 25:02

Definitely not.

Speaker 1 25:03

What organizations actually need is a shift in how specialists operate. They need to move from being gatekeepers to embedded enablers.

Speaker 25:11

Instead of sitting in an ivory tower, they become embedded allies.

Speaker 1 25:14

Yes.

Speaker 25:14

I want to use an analogy here. It's the difference between a general sitting in a tent miles from the front line, reading reports and sending down orders. Right. Versus an embedded journalist or medic who is right there in the trenches with the squad, experiencing the friction firsthand.

Speaker 1 25:30

That's a really vivid way to look at it.

Speaker 25:32

What does that actually look like on the ground for these different roles? Let's take architects.

Speaker 1 25:37

Well, in the old model, an architect spends months designing a rigid monolithic blueprint.

Speaker 25:44

And then what?

Speaker 1 25:45

They hand it to the developers and say, build exactly this.

Speaker 25:48

Which never works out.

Speaker 1 25:50

Never. When the developers inevitably find out the blueprint doesn't work with the real-world technology constraints, they have to submit a change request.

Speaker 25:58

And everything grinds to a halt.

Speaker 1 26:00

Exactly. But in the evolved model, architects co-create guardrails.

Speaker 26:04

Co-create. I like that.

Speaker 1 26:06

They work alongside developers in the trenches, building a walking skeleton of the architecture.

Speaker 26:11

So they build a prototype together.

Speaker 1 26:12

They design modular systems that can adapt as the product evolves, making decisions at the last responsible moment rather than entirely upfront.

Speaker 26:20

Okay, what about UX designers? Because fitting deep user research into a strict two-week sprint is notoriously difficult.

Speaker 1 26:29

It's one of the biggest fiction points in Agile.

Speaker 26:32

A lot of developers complain that UX is always either too slow or they're just drawing pretty pictures without understanding the code.

Speaker 1 26:39

The evolved UX designer moves from delivering pixel perfect upfront wireframes months before coding begins to engaging in continuous discovery.

Speaker 26:49

Continuous discovery.

Speaker 1 26:50

This is a crucial mechanism. They operate on a dual-track system. They're often working one sprint ahead on discovery.

Speaker 26:56

We're running usability tests and gorilla research.

Speaker 1 26:58

Exactly, but they're doing it with the developer.

Speaker 27:00

Oh, so the developers are involved in the research.

Speaker 1 27:02

Yes. They bring an engineer into the user interview so the engineer sees the customer struggle with the interface firsthand.

Speaker 27:09

That builds so much empathy.

Speaker 1 27:11

It does. They feed those insights directly back into the current sprint in real time, sketching solutions together rather than throwing Photoshop files over a wall.

Speaker 27:21

And the business or data analysts, I imagine they aren't just writing 50-page requirements documents anymore.

Speaker 1 27:27

Not at all. They move from writing exhaustive specs to collaboratively discovering needs.

Speaker 27:33

Framing the problems.

Speaker 1 27:34

Exactly. They have the team frame the right problems to solve based on metrics.

Speaker 27:39

So instead of dictating a solution.

Speaker 1 27:41

Right. Instead of saying dual the dashboard with these five charts, they say the data shows users are abandoning the process at step three. Let's figure out why.

Speaker 27:50

That's much more powerful.

Speaker 1 27:51

They apply lean principles optimizing flow, reducing waste, to prevent the team from accumulating technical or usability debt.

Speaker 27:59

Looking at all these roles together, the scrum masters facilitating flow, the product owners driving strategic vision, the engineering leader is enabling technical excellence, and the specialists embedding deep expertise.

Speaker 1 28:10

You see a pattern emerge.

Speaker 28:12

We really can start to see a unified pattern.

Speaker 1 28:14

Yes, there is a shared DNA across all these modern Evolve roles. Mass core themes synthesize beautifully here.

Speaker 28:22

How would you summarize that shared DNA?

Speaker 1 28:25

If you strip away the titles, every single Evolve role is focused on enabling others.

Speaker 28:30

Enabling others.

Speaker 1 28:31

Supporting better decisions, improving the flow of work, focusing relentlessly on outcomes over outputs. Fostering trust.

Speaker 28:42

It's a complete posture shift.

Speaker 1 28:44

A massive one.

Speaker 28:45

Every single role has moved from a vertical command and control posture where your job is to dictate, approve, and track from above.

Speaker 1 28:54

To a horizontal collaborative posture.

Speaker 28:56

Exactly. A horizontal posture where your job is to coach, discover, and facilitate alongside the team. You're no longer managing the people, you are managing the environment they operate in.

Speaker 1 29:06

What's fascinating here is that this shared evolution is the very definition of true organizational agility.

Speaker 29:12

It really is.

Speaker 1 29:12

It's not about having the perfect JIRA workflow or doing stand-up, standing up. It is about creating a resilient nervous system for the organization, an environment where value flows continuously because the people are aligned.

Speaker 29:25

Because they understand their shared purpose.

Speaker 1 29:27

And because they possess the psychological safety to act on it, not just because a framework dictates a rigid set of ceremonies.

Speaker 29:34

But if the blueprint for evolving these roles is so clear and the shared DNA of horizontal collaboration makes so much sense, we have to address the elephant in the room.

Speaker 1 29:45

Let's do it.

Speaker 29:46

Why are so many organizations still getting it so spectacularly wrong?

Speaker 1 29:50

It's painful to watch sometimes.

Speaker 29:52

Why is it still so painful out there for the practitioners listening to this right now?

Speaker 1 29:56

Because of systemic misalignment and organizational gravity.

Speaker 29:59

Organizational gravity? What does that mean?

Speaker 1 30:02

You cannot drop an evolved, horizontal, outcome-focused, agile team into a rigid, vertical, output-focused corporate structure and expect magic.

Speaker 30:12

It just doesn't fit.

Speaker 1 30:13

The immune system of the old corporation will attack the agile team.

Speaker 30:17

Oh, that's a great way to describe it.

Speaker 1 30:19

The text unpacks how companies actively, albeit unintentionally, sabotage these evolving roles.

Speaker 30:26

Give me some specific examples of that sabotage. What does it look like when the corporate immune system attacks?

Speaker 1 30:32

The most classic example is the budgeting process.

Speaker 30:35

Oh, the dreaded annual budget.

Speaker 1 30:37

Right. You have an organization trying to run agile development teams, asking them to pivot based on continuous customer feedback and market discovery.

Speaker 30:45

Being agile.

Speaker 1 30:47

But the finance department still maintains a rigid annual waterfall budgeting process.

Speaker 30:52

The two just clash.

Speaker 1 30:54

In November, they demand a GATT chart promising exactly what features will be delivered in August of the next year in order to release funds.

Speaker 31:01

So you have a product owner who is supposed to be running experiments and adapting, but they are legally bound to a contract they signed nine months ago before they had any data.

Speaker 1 31:10

Exactly. It completely neuters the product owner's ability to be visionary.

Speaker 31:14

What's another example?

Speaker 1 31:15

Another one is maintaining strictly siloed departments where IT and business don't speak, making the scrum master's job of organizational change almost impossible.

Speaker 31:23

They're just blocked at every turn.

Speaker 1 31:25

Or most destructively, the executive board rewarding leaders based on the sheer volume of features delivered rather than the business impact of those features.

Speaker 31:34

Ah, the feature factory trap again.

Speaker 1 31:37

That's so common.

Speaker 31:38

I want to dive into the psychology of this because it is so easy for an organization to panic when quarterly numbers are down.

Speaker 1 31:45

Panic is the enemy of agility.

Speaker 31:47

Let's say revenue misses projections by 5%, the executives freak out, the pressure rolls downhill rapidly.

Speaker 1 31:54

And suddenly that beautiful evolved system we just talked about collapses.

Speaker 31:59

The product owner is forced to bypass the backlog.

Speaker 1 32:02

The Scrum Masters facilitation is ignored as fluff.

Speaker 32:05

And the developers are whipped back into being an assembly line just to show progress to the board.

Speaker 1 32:09

And when that panic sets in, the system breaks down entirely. Technical debt skyrockets, quality drops, and burnout goes through the roof.

Speaker 32:17

It's a vicious cycle.

Speaker 1 32:18

But what happens next is the real tragedy, the blame game.

Speaker 32:21

Who gets blamed?

Speaker 1 32:22

Executives look at the chaos, the poor quality, and the exhausted teams, and they blame the agile framework itself.

Speaker 32:29

They say agile doesn't work here.

Speaker 1 32:31

Or they point at the specific roles, saying, our scrum master isn't effective at delivering.

Speaker 32:37

Wow.

Speaker 1 32:38

They almost never look in the mirror and address their own outdated operational models, financial models, and output-obsessed culture that forced the panic in the first place.

Speaker 32:48

They blame the symptom, not the disease.

Speaker 1 32:51

Exactly.

Speaker 32:51

They fire the scrum master for not making the assembly line run faster without realizing the assembly line is building the wrong product.

Speaker 1 32:59

It's incredibly frustrating for practitioners.

Speaker 33:01

So overcoming these massive organizational hurdles requires looking forward.

Speaker 1 33:06

We have to look ahead.

Speaker 33:07

Where is this entire ecosystem of roles heading next? If I am a listener navigating this messy reality, what does the future look like?

Speaker 1 33:15

Well, artificial intelligence is going to be the ultimate force multiplier.

Speaker 33:18

AI again.

Speaker 1 33:19

And it is going to force this evolution faster than anything else.

Speaker 33:22

Because it automates the busy work.

Speaker 1 33:24

The text makes it very clear that AI is not going to replace these roles. It is going to shift them to higher order thinking because AI is going to commoditize the execution.

Speaker 33:34

Writing boilerplate code, running automated tests, generating reports.

Speaker 1 33:38

AI will do that instantly.

Speaker 33:39

So what do the humans do?

Speaker 1 33:41

The humans focus on strategy, ethics, and systems design.

Speaker 33:45

Systems design.

Speaker 1 33:46

Specialists, for example, will spend less time doing manual data analysis and more time guiding AI-driven automation.

Speaker 33:52

Like predictive workforce planning or automated security testing?

Speaker 1 33:57

Exactly. AI will generate thousands of insights and recommendations. But the agile leaders, the evolved specialists, scrum masters, and engineering leaders, will provide the ethical, data-backed governance.

Speaker 34:10

They have to make sure the AI isn't hallucinating.

Speaker 1 34:13

They will have to ensure the AI's recommendations actually align with the nuanced business strategy and complex human needs.

Speaker 34:19

And what about the organizational structure itself? We talked about scale earlier.

Speaker 1 34:22

As we navigate the realities of massive hybrid and remote work environments, scaling frameworks like Safe, LESS, or Nexus are becoming ubiquitous.

Speaker 34:31

They are everywhere in the enterprise space.

Speaker 1 34:33

Aaron Ross Powell And these frameworks are incredibly dangerous if run by immature roles, because they can easily become just another layer of heavy bureaucracy.

Speaker 34:42

Scaling agile often just means scaling meetings.

Speaker 1 34:45

Exactly. But these evolved roles are the antidote to that. They act as network nodes rather than gatekeepers.

Speaker 34:52

Network nodes.

Speaker 1 34:53

They're the ones who will have to coordinate seamlessly across massive matrixed organizations using their horizontal posture to cut through the red tape.

Speaker 35:01

That is the tight rope walk of the future. Scaling the benefits of agile without scaling the bureaucracy.

Speaker 1 35:07

It's a delicate balance.

Speaker 35:08

It seems to me that the future belongs entirely to those who can interpret AI insights and facilitate complex human collaboration around them. Absolutely. If you are a scrum master who only knows how to book meetings, yes, your role is dying.

Speaker 1 35:21

Unquestionably.

Speaker 35:22

But if you are a system optimizer who can use AI data to heal a fractured team culture, your role isn't dying. It's becoming the most important job in the company.

Speaker 1 35:31

I agree completely. The future of work is undeniably human, supported by incredibly powerful machines.

Speaker 35:38

Supported by machines, driven by humans.

Speaker 1 35:40

But the machines cannot build trust, they cannot resolve a stakeholder conflict, and they cannot define a compelling product vision.

Speaker 35:49

As we bring this deep dive full circle, I want to bring it right back to you listening right now.

Speaker 1 35:53

Yeah, back to the listener.

Speaker 35:54

We started by dismantling a myth, and hopefully we've shown you that agile roles are not disappearing. They are maturing.

Speaker 1 36:01

Evolving, maturing, adapting.

Speaker 36:03

The scrum masters, product owners, engineering leaders, and specialists are shedding their administrative gatekeeping skins to become the vital connective tissue of value creation in modern organizations.

Speaker 1 36:16

Connective tissue, exactly.

Speaker 36:18

The focus is shifting from removing roles for efficiency to aligning roles for value.

Speaker 1 36:22

And I won't leave you with a final provocative thought.

Speaker 36:25

Please do.

Speaker 1 36:26

As AI and automation continue to advance at breakneck speed, they will eventually absorb almost all the mechanical processes of agile.

Speaker 36:34

The tracking of velocity, the generation of code, the automated testing, the drafting of user stories.

Speaker 1 36:39

Right. When the machines are handling all the mechanics of the framework, does agile leadership ultimately become a pure exercise in human psychology, empathy, and organizational systems design? Wow. That is the frontier we are heading toward. It is no longer about managing the work, it is about managing the environment.

Speaker 36:58

Managing the environment.

Speaker 1 37:00

That is something for you to mull over as you step back into your own teams tomorrow.

Speaker 37:04

Thanks for joining us for this deep dive on digital product and agile. If you found the conversation useful, follow the series so you don't miss future episodes exploring how product leadership and organizational systems evolve.