AI Changes The Real Bottleneck with Bernie Maloney

Welcome And Meet Bernie

Peter [0:04]

Welcome to Definitely Maybe Agile, the podcast where Peter Maddison and David Sharrock discuss the complexities of adopting new ways of working at scale. Well, hello everybody. Today Dave and I are joined by Bernie. Bernie, why don't you introduce yourself?

Bernie [0:21]

Hi everybody. My name is Bernie Maloney. I position myself as an organizational consultant. Some people see me as a coach, some as a trainer. But back in the 2008 recession, I had a lot of time to think because I was out of work for 15 months. Something I recognized is that I truly believe there's untapped potential in every person and every organization. So my mission became accelerating that genius. What I really do is help my clients make breakthroughs in performance with their teams, their organizations, sometimes even with themselves. You can think of me as breakthrough Bernie.

Dave [0:52]

I like that. You should get t-shirts made or packets or something like that.

Bernie [0:57]

I picture a wall with someone diving through it with a cape. I could actually go over to a shelf here and show you a board break I did about 10 years ago.

Peter [1:10]

So Dave, I believe this conversation was instigated by a comment Bernie made on one of your posts. Why don't you tell us where this came from?

AI Speeds Up Product Delivery

Dave [1:23]

Yeah, we've had many conversations on this podcast about the impact of AI on organizations, particularly around product delivery. Bernie, what you were commenting on was something we'd discussed. Yes, we can build things really quickly now. Implementation has accelerated pretty strongly. But there's all this non-technical stuff—decisions, processes, steps in the delivery pipeline—that isn't keeping pace with the acceleration we're seeing in execution and implementation. And you mentioned something I want to dig into with you: the role of player coaches.

Bernie [2:18]

Okay, fair warning: I can riff on this for ages. So you're going to have to interrupt me and step me back from some of this.

Everyone recognizes AI is speeding up the ability to build things. One of the interesting things I'm seeing from direct reports from clients and from industry luminaries is that you end up with more than one product manager per developer.

If you're familiar with Evan Layborne's business agility theory and the theory of agile constraints, 25 years ago when the Agile Manifesto came around, the constraint was in the ability to produce things. We started fixing that. About 15 years ago, the constraint moved to the ability to deploy things. That's where DevOps came up. Evan recognized about 10 years ago that the bottleneck was moving upstream, and it's been moving upstream ever since. It's about deciding what are the right things to build. AI is accelerating that. We're building things so fast now that the real challenge is figuring out what's worth pursuing in the first place.

And I think most people don't recognize that management is already becoming the constraint. AI is going to hit management harder than it's hit other areas because of the speed involved.

Output, Outcome, Impact, and Discovery

Bernie [3:48]

If you're familiar with Marty Kagan's product operating model, I like to articulate it as agile in three dimensions. Most organizations only use one dimension. They focus on how to build things. That's all about speeding up delivery.

Peter [4:06]

And developers often end up being the problem child, right?

Bernie [4:12]

Right. Because most organizations have treated people as a pair of hands. That goes back 200 years to industrial history and the Prussian method of management. It was developed for training soldiers, worked great for the industrial era. The whole thing separated doing from thinking. We've seen thinking come back in, but management still often treats developers as a pair of hands, tossing things over the wall.

So the first dimension is how to build. That's all about output. A lot of agilists talk about outcomes, which is a second dimension. That's about how to solve problems. But very few people talk about a third dimension. That's about what problems are worth solving. I call this the impact dimension.

Peter [5:06]

As you're holding up your fingers there for the video viewers, we've got output, outcome, and impact.

Bernie [5:12]

Exactly. This is about business-level agility. Strategic-level agility. This is how startups work. I've been in the Bay Area for over 30 years, so I've been exposed to it. They start by asking: is this a problem worth solving? That's your first funding round. Then: is this a good way to solve it before we scale?

Now, there's also a discovery plane here. I like to bring in Gabby Bernfield's Mobius loop. Most people focus on the delivery side. That's where organizations have been focusing with Agile. But discovery is a big part of figuring out what problem to solve in the first place. That's where product ownership comes in. Sometimes product ownership isn't seen as technical, so we're in the same space.

What Product Ownership Should Be

Peter [6:14]

There's a real problem with how product owners are positioned. Someone labeled as a product owner isn't always what we'd want them to be. They often don't have the scope to act that way within the organization. So describe what the product owner should actually be doing.

Bernie [6:36]

A lot of organizations use product owners just as backlog jockeys for delivery. But when the original Scrum paper came out in 1995, they recognized there was a handoff between discovery and delivery. And handoffs slow things down. That's where they defined the product owner role to span both. Some organizations call it product management. The ones labeled as product managers definitely get this idea of discovery and delivery both.

Dave [7:22]

But I'm not sure it's as easy as saying product managers understand this. A lot of organizations really don't see it at all. I love Marty Kagan's work, and this idea of a product operating model where the product itself drives business decisions—it just doesn't happen in many places. There's still this gulf. This handoff happens. The alignment between business and technology is still a long way from being real.

Bernie [8:11]

Absolutely. That's what Scrum was trying to design with the Agile Manifesto. Business people work daily with the team. You want to reduce handoffs because handoffs delay value production.

Think of that Mobius loop. There's a plane of discovery. That's the whole idea: discovery before you get to delivery. But most organizations hold that discovery at a management layer. Then things get tossed over the wall to teams to deliver. Teams are given solutions to build, not problems to solve.

The pace of change is picking up. Competition is picking up because they're solving things faster. And that handoff delays value production. So what I'm seeing is that product owners and product managers need to get better at discovery. Because delivery is speeding up. The pressure is moving to management. And that's where the player coach idea comes in.

Alignment Starts With Clear Intent

Bernie [9:37]

I go to a lot of Miro conferences. They had one a couple months ago in May 2026. They talked about two forces: alignment and decision latency.

I describe alignment as intent. The problem I see across my clients is unclear intent. There's no clear vision, no clear strategy, no clear opportunities being pursued. No clear product or sprint goals. People get a task list. They're given a solution to build instead of a problem to solve.

Alignment is necessary. As we speed up, without it, people are scattered.

Dave [10:30]

But there's more to it than alignment. Alignment sounds like we need to get everyone in a room and all agree we're building X and it looks like this.

Bernie [10:43]

We need to know the problems we're trying to solve.

Dave [10:47]

So here's the metaphor spinning through my head. What's happened on platforms like LinkedIn is that AI accelerated the volume of content. You can draw conclusions about the quality. There's all this talk about AI swap and garbage output. But there's a consequence: the cost of production dropped to near zero. So that decision layer—what do we actually build in the world of product, or what do we write and publish on social media—suddenly becomes where the attention is. We're looking for authenticity, integrity, things that are well thought-out. The goal is finding something genuine, experienced, not garbage.

But it doesn't stop the amount of stuff being produced.

Bernie [12:04]

Right.

Dave [12:05]

It means there's a ton of organizations that don't see this as important. But the real value gets created by a small number of companies that understand the discovery plane is where your best people need to be. Where the best structures are being put in place to make good decisions. Where data and all the things we talk about sit, more than implementation and execution.

Bernie [12:34]

Agreed. Yeah, agreed.

Decision Latency and Player Coaches

Bernie [12:36]

This discovery plane has largely been at a management layer. Alignment is one thing Miro highlighted. The other was decision latency. In the past, when it took a while to build things, management had a buffer of time to decide what direction to head. That buffer is going away. Decision latency has to be addressed.

That's where the player coach term comes in. Managers are no longer just administrators figuring out what direction to head. They actually need hands-on work to know what's possible. When Agile came in, consultancies came in because they had experience. AI is so new everybody's on the same footing. An organization has to ask: do you want to outsource this to a consultancy, or do you want to bring in people who understand it and can help you grow it internally?

With AI, managers need to understand the work. That's the player part. And they also need to coach people to take a broader view. It's compressing the organization instead of having layers of hierarchy for decision-making. The player coach brings decisions closer to the team.

Andrew McAfee's book The Geek Way is another good reference. He talks about four cultural norms that lead to outside success. If you can find his video from December 2023 at the Computer History Museum, the first 20 minutes are worth it. He shows market capitalization plots from 2002 to 2023, and you see phenomenal growth from West Coast companies. He's a business school professor, and he got curious about why. It's not that they're high tech. That's everyone's assumption. He points out four cultural norms.

First: science. The willingness to run experiments. Most organizations are plan and predict. They don't have science built in. West Coast companies, startups, younger companies do.

Second: openness. This is the big challenge. It's the ability to challenge authority. Authority no longer has the clear view of what we should be doing.

Third: speed. A lot of organizations trip up here because they hear speed and think it's about delivery speed. But it's actually about speed of learning. You want to optimize for finding small, cheap, fast experiments in a fast-moving environment. You want to skate to where the puck is going.

Fourth: ownership. We see that in Agile with product ownership. What problem are you solving? What's a good way to solve it? Not just being a backlog jockey or building a solution.

He shows non-technical companies that have phenomenal success with these cultural attributes.

Dave [22:50]

Go on. Peter, you're going to say something?

Peter [22:52]

It was making me think of Peter Senge and The Fifth Discipline, the learning organizations piece. If we take those cultural elements, how do you actually get them? If the player coach role involves evolving management to help create those behaviors and cultures, how do we start that transition? What skills, knowledge, and capabilities do those people need?

Bernie [23:30]

I don't have a ready answer.

Dave [23:31]

I wanted to push back a little on what I'm hearing in your question, Peter. We're looking for experts who become broad generalists. I was a technology expert or product manager. Now my responsibility extends across that. Bernie's saying we need to build AI agents and learn how to work with them. All driven by growing skills and expertise.

What's driving my thinking is the Premier League kicks off this weekend. The really successful managers have often been journeymen players. Good players, but not the best in the world. They have an eye for the game. I wonder if that's the player bit. It's not being an expert at product management or development, but being really good at seeing the bigger picture and strategy. That drives leadership. They understand how to coach experts to be strong experts, but they see the game. They see the business. They see what's happening with AI and agility. I think there's something about sense and respond, about speed of learning. We've talked about this to clients for a decade. And people walk out saying "yeah, they didn't hear a single word" because they're not seeing that side of the playing field.

Bernie [25:31]

Organizations, by and large, because of that mechanical model, treat people as cogs in a machine. Strategy is very distant. I agree with you, Dave. For baseball fans, catchers often make really good managers. There are loads of successful managers in baseball who were catchers. And catcher is a strategic position because they're the only player who can see the entire field. That analogy works.

Dave [26:02]

Now I've got to challenge Peter to bring in a different sport.

Peter [26:06]

Oh jeez. No, they—I'm the wrong person to ask for that.

Dave [26:12]

So we talked about player coaches. Let's land this quickly. The player coaches—we've talked about the player side, learning to build AI agents, having strategic insight. But on the coaching side, that's different from traditional leadership. That's different from "I know where we're going, follow me." Can you speak to what you're seeing on the coaching side of player coaching?

Coaching Skills Leaders Forgot

Bernie [26:49]

I don't have a ready roadmap for this. But one thing they need to do is get comfortable building AI agents themselves. They need to understand not just AI, but agentic AI. They need to understand how to build AI agents. Maybe even do a value stream map and create agents to help with that. That's the player part. Getting closer to the actual delivery of value.

Then there's coaching people to take a broader view like management would. You're compressing the organization instead of having layers of hierarchy. The whole idea of player coach is bringing decisions closer to the team.

Another reference I like is Andrew McAfee's work on The Geek Way. He talks about four cultural norms. If you can find his video from December 2023 at the Computer History Museum, watch the first 20 minutes. He shows West Coast companies have phenomenal success.

I worked at HP for about 16 years, and they did a really good job developing people as general managers. They invested heavily in coaching and mentoring skills. What I've seen over the past 30 years is that investment has gone away.

Organizations hire people for specific skill sets. Cogs in a machine. That propagates today. People aren't taught how to coach and mentor anymore.

There's situational leadership, which talks about different styles. Directive: I decide. Coaching: We talk, I decide. Mentoring: We talk, you decide. Delegation: You decide, I trust you. Pretty much every manager says they want delegation. But they don't have the skills to bring people there. They only have directive skills because nobody coached them.

Rajiv Peshawar has a book called Too Many Bosses, Too Few Leaders. The key skill is at the transition from first level to second level. At first level, you can still do the work. At second level, you have to let go. That's the coaching part. He also points out there's no model in industry for doing this. You're on your own to find a mentor. There's a huge lack in developing people with the skills to let go.

So part of the industry needs to figure out how to let go. And the part that's figured it out needs to figure out how to get hands-on again. That's the classical challenge right now.

Dave [29:07]

You can't afford not to be close to where the sausage is made, right?

Bernie [29:14]

That's decision latency right there. That's it.

Dave [29:16]

You need to be close because you can't just assume that over the next five years that space is stable. It isn't.

Bernie [29:26]

It's going to continue to learn. But at the same time, you need to not be involved in every single decision. You need to develop people who can make decisions consistent with what's desirable. That alignment, that long-term strategic direction. Maybe not yours personally, but where the organization wants to head.

Dave [29:45]

And I'd push back to say it's not just alignment to those decisions. It's the learning. They're not going to be aligned.

Bernie [29:53]

Yeah.

Dave [29:54]

They're going to interpret things in slightly different ways. That's the beauty of those coaching relationships. I wouldn't do it that way, but you seem certain. Great. How do we make sure you either prove me wrong—fantastic, we learn fast—or you bump into something that hints you need a different direction early enough it's not costly? There's real learning there. And that's tough. When you're under pressure and accountability is real and everything around you is changing, maintaining a learning mindset as something safe is difficult.

Enabling Experimentation and Psychological Safety

Peter [30:41]

It's about limiting the blast radius. That's often a key function of leadership. Yes, you can experiment with this. Here's the scope. Here are the boundaries where we step back and consider if this is still the right direction. Some of that comes from being good at designing experiments.

People say they're running experiments, but they've already decided the outcome. They've already picked the solution before they started. It's not really an experiment. No hypothesis. No measure of success or failure. No learning.

Bernie [31:34]

Another thing that has to come into organizations is tolerance for intelligent failure.

Amy Edmondson wrote about this in Right Kind of Wrong. She categorizes three types of failure. Basic failures from oversight or neglect. Complicated failures from chain-reaction events. And intelligent failures. Intelligent failures happen all the time in pharma because you're running experiments, discovering things. But a lot of organizations put process in place to try to eliminate failure entirely. So when something does happen, people get blamed because it shouldn't have. That's where psychological safety comes in. You need tolerance for intelligent failure without getting into the dangerous complicated stuff.

Peter [32:28]

There's no such thing as human error.

Bernie [32:30]

Cogs in a machine.

Peter [32:33]

Sydney Decker and systems thinking. Failure in a system is the system's failure, not individual failure. Understanding that tells you whether there's psychological safety. Can people put their hands up and say something went wrong?

Dave [32:59]

And there's timing too. You want intelligent failure to happen early enough that you manage the cost.

Peter [33:09]

Yeah, for sure.

Dave [33:11]

I think we could keep going, but we've covered a lot of ground. Maybe we need a follow-up conversation. Let's bring together a few things. We always try to land on three takeaways. Bernie, as our guest, I'll start with you.

Key Takeaways

Bernie [33:41]

If I have to pick one thing: think about that three-dimensionality. Most folks just operate faster, faster, faster. It's all about output. Lots of agilists talk about outcomes. But think about that third dimension: impact. Start asking what problem you're actually trying to solve. Even ask your leadership. What's the real problem? That's your five whys. That's how you figure out customer need so you're building a better solution. That leads to ways to solve the problem before you even think about building something. That's my takeaway: the three-dimensional view of Agile.

Peter [34:29]

I'll go next so I can try to steal Dave's. I'm going to take the systems piece. We touched on this. When we talk about psychological safety, organizations have hired for skill sets, cogs in a machine. But now you need those people to think more broadly and strategically about the system they're in. That's what player coaches do—bring people up to think more broadly.

I'm coaching people right now through exactly that. How do you start thinking more broadly about the system? What does your organization actually do? How does it make money? What systems are in place? What's your role in those systems? How do you influence them to improve? How do you learn? How do you accelerate? Those are key pieces. Understanding the system you operate in and taking a broader picture of the organization. That matters.

Dave [35:55]

And that wasn't the one I was going to say. We have these conversations all the time from a technology view. Product and technology, with technology leading. And what I really liked about this conversation is we touched on sport—baseball, football. We touched on non-technical companies that are as successful as Western US companies. We talked about impact on that discovery plane. It takes us outside just thinking everything's about tech and DevOps. What I'm walking away with is: we really need to broaden our appreciation and understanding of company development. AI's going to do a lot. But it's not going to do it just in tech.

Bernie [36:52]

I've long said Agile is a social technology. That's why the Manifesto says individuals and interactions over processes and tools. We haven't even gotten into what happens when your products are non-deterministic, probabilistic instead, because of AI. That's a whole other thing. I'm helping write a book on the economics of AI products.

Peter [37:18]

There's definitely some interesting stuff there. That's a conversation for next time. I can think of a myriad of other directions we could go from here.

Bernie, thank you very much. This was a great conversation. And thank you, Dave.

Dave [37:36]

It's always a blast exploring where our minds go and what we come up with.

Bernie [37:43]

Thanks for having me.

Peter [37:45]

For our listeners, don't forget to subscribe. You can send us emails at feedback@definitelymaybeagile.com. We look forward to next time. You've been listening to Definitely Maybe Agile, the podcast where your hosts Peter Maddison and David Sharrock focus on the art and science of digital, agile, and DevOps at scale.