Definitely, Maybe Agile
Definitely, Maybe Agile
Two Speeds, One Organization
Use Left/Right to seek, Home/End to jump to start or end. Hold shift to jump forward or backward.
Something is shifting inside organizations right now, and it's creating a split that's hard to ignore. AI is compressing the time it takes to generate, validate, and prototype ideas. Some people inside your org are moving at a completely different speed than the systems built to support them. Peter and Dave are calling it the great decoupling, and it's already happening whether you've noticed it or not.
In this episode, they dig into why acceleration in one part of a system creates pressure everywhere else. When you map the end-to-end journey from idea to live product, you often find 30 to 40 distinct steps. AI is handling a handful of them. The rest? Still waiting on decisions, reviews, and handoffs that haven't changed in years. Development isn't the main blocker anymore. Decision latency is.
They talk through what it looks like when product managers are running parallel experiments and validating ideas in hours, then slamming into unchanged processes for security sign-off, change control, and release management. And why the smartest people on your team are quietly finding workarounds rather than waiting in line, which creates more risk, not less.
This isn't a conversation about AI hype. It's about the real organizational friction that shows up when the pace of work outgrows the systems designed to manage it. And what you can actually do about it.
If your team is moving faster but waiting longer, this one's worth your time.
This Week's Takeaways:
- Acceleration in one part of the system creates stress everywhere else
- Map the end-to-end flow before you optimize any single part
- If it's happening inside your organization, you need to deal with it internally
If this episode resonated, follow Definitely Maybe Agile wherever you listen to podcasts so you never miss a conversation. And if you know someone sitting at one of those 40 steps wondering why everything feels stuck, send this one their way. There are plenty more episodes worth your time at definitelymaybeagile.com.
Peter: 0:04 Welcome to Definitely Maybe Agile, the podcast where Peter Maddison and DaveSharrock discuss the complexities of adopting new ways of working at scale.
Dave: 0:12 Peter, great to connect again. What do we have planned for today?
Peter: 0:19 I'm actually quite interested in this one. I saw a recent webinar you did, and the topic felt very relevant to what we normally talk about. So I thought we'd dig into it today.
Dave: 0:31 Yeah, and there were a lot of comments coming in from people far and wide, just keeping the conversation going. It was around something you and I have touched on many times, but I've started calling it the great decoupling. It feels more and more like there are two speeds inside organizations now. Two speeds to how product development gets done. Obviously AI is a big part of that. But it's also this natural progression of build, measure, learn. That lean startup idea of thinking in small experiments to keep validating as you go. What got me here was talking to a lot of product managers. You see this interesting split between traditional project managers who want a whiteboard and long strategy conversations, and then these nimble, tech-friendly product managers thinking in much smaller bites and moving much, much quicker.
Peter: 1:53 A lot of what we always wanted to be true is kind of... actually true now. I really can build an experiment, try things out, see what works. And I can do it so much faster because AI makes it possible. Providing, and we talked about this a bit before we started, the organization as a whole actually lets you do that.
Dave: 2:15 Right. As a product manager, you have a lot of control over your workspace. You can run experiments in parallel, pull together proof of concepts really quickly. But the moment you step outside that workspace, the moment you try to push something live, the speed changes dramatically.
Peter: 2:53 And it always varies by organization, of course. I spend a lot of time in the SDLC space looking at how to improve these pieces. One client I work with moves very fast, as long as what you're doing is an incremental change to an existing product. Even in a heavily regulated environment, they're really good at that part. It only grinds to a crawl when you need something new. A new service onboarded, a security architecture review, some other kind of sign-off. Suddenly you're chasing people down, collecting checkboxes, and everything stops.
Dave: 3:45 And look, some of that slowing down makes sense. Something genuinely new should get a harder look, especially in a regulated industry. But even outside regulation, data governance and information security matter. What I was seeing, though, was well-established technology organizations that have spent years cleaning up that process, and there's still this lag of weeks or months. No real categorization of risk. No fast lane for minor changes. Just this slow, methodical queue. And meanwhile you've got product managers generating validated ideas faster than ever, and they're being told to fill out a form and wait. That's going to cause a rupture.
Peter: 5:18 If you put on your flow hat and think about the end-to-end system, this is actually expected. It's classic theory of constraints. We have an existing process. We've brought in AI to accelerate individual parts of that process. But where there are handoffs and gates between those parts, things pile up. The next step isn't ready. And the same thing is happening in software development. Pull requests, code review, test frameworks, security checks, they haven't kept pace with the volume coming at them. So developers are generating code much faster and waiting on everything else to catch up before anything gets to production.
Dave: 6:30 Absolutely. And it carries into operations too.
Peter: 6:31 Exactly. Same problem. You're throwing even more at them.
Dave: 6:34 And even once something goes live, you've still got customer support, marketing, training. All of that is collapsing down to hours or days on the product and dev side, and then hitting this wall of formal process that nobody's really touched when it comes to automation. What strikes me culturally is how much this widens the gap. There's always been a bit of distance between coming up with an idea and safely getting it out. But now that gap is growing exponentially in some places. Product managers are sitting on validated ideas and being effectively patronized into a slow queue.
Peter: 8:10 I've seen the same thing in recent work. When you map the end-to-end flow, from idea all the way through to something being in front of a customer and supported in production, there are still so many failure points. In one case we mapped about 40 distinct steps across that journey. Of those 40, people in the room could confidently say AI is fully handling three of them. And the development piece was actually the least complicated part. The harder bits were things like getting alignment on what the right idea even is in the first place.
Dave: 9:12 Yeah, I had that exact conversation this morning. Came out of a meeting because I had to argue that what they were doing was the wrong call. Happens all the time.
Peter: 9:26 There are a lot of those moments. Getting aligned on what the product looks like, what matters most, those conversations are still very much human work. And I think there's a real transformation coming in how we think about the end-to-end delivery flow. Where the boundaries actually are between planning, building, reviewing, releasing. Those boundaries are going to shift, and the roles involved will shift with them.
Dave: 10:10 One thing that struck me is how disconnected people are from the whole picture. Everyone's focused on their piece. Product management, some step in the middle, whatever. But there's this complete disconnect between the pace they're moving and any understanding of the full delivery lifecycle. Value stream mapping, understanding the difference between decision time and actual work time. That's always been an issue. But now, because certain parts are moving so fast, the cultural disconnect feels much more extreme. And I heard someone describing how they're escalating and escalating just to get things moving faster. All I could think was that's going to trigger the organizational immune system. The inertial white blood cells. And that's going to be uncomfortable for everyone trying to move quickly.
Peter: 11:31 That's been true throughout our careers.
Dave: 11:33 Change management 101, really.
Peter: 11:37 Essentially, yes. You need the top-down and the bottom-up aligned. If leadership isn't bought in, then someone moving fast is just going to look like noise.
Dave: 11:53 And what's interesting now is that we're in an environment where organizations know they need product innovation, they know they need to respond quickly. They've brought in people specifically to do that. And those people are now in direct conflict with the broader organization that just got comfortable moving monthly instead of quarterly. And now we're telling them that was gear one. We need gear six.
Peter: 12:46 And even something like a two-week sprint starts to feel like a relic when you can ideate, prototype, and deliver something in a day. The economic models shift too. How you fund this, how you coordinate it. When writing the code becomes closer to turning a dial, the question becomes: what do we actually need humans for in that system?
Dave: 13:34 What draws my attention to all of this is that this used to happen outside organizations. Startups would move fast, grow, get acquired, and then slow down as they hit the culture of the bigger company. We've talked about that cultural clash before. But what's changed is now all of that is happening inside the organization from day one. People are coming in with tools that let them generate and validate ideas faster than the org is set up to handle. It's a headache waiting to happen.
Peter: 14:35 It creates stress on the other parts of the organization. One part accelerates, and the rest of the system isn't ready to consume what that part is producing. And the tricky thing is this is probably happening in multiple places at the same time.
Dave: 15:01 One product manager I spoke to was already sorting their work into two piles. Things they could sneak through by piggybacking on other work, and things they'd have to fight for through the formal process. Which brings us back to what happens with things like change approval boards. What actually happens is not that every change goes through. It's that some do, and the creative, resourceful people find ways around the rest.
Peter: 15:46 Which causes its own kind of chaos when something slips through and goes wrong.
Dave: 15:50 Exactly.
Peter: 15:51 One point I made to an executive team recently was about this same dynamic on a different timescale. If you only release once, everything critical gets jammed into that one release. When you move to incremental delivery, you get more releases, more chances to validate, more confidence over time. That's what Agile was always about.
Dave: 16:26 And I think what we're describing now is that taken to the tenth degree. And there are organizations that think they're immune to it, that they don't need to worry. That's the part I keep coming back to. It's already happening. So the question is: how do you respond?
Peter: 17:03 One thing I'd want listeners to take away is this: wherever parts of your organization are accelerating, they're going to put stress on the parts that aren't. If you're hearing someone ask why isn't everyone else moving faster, that's worth paying attention to. Look at what they're doing, why they're frustrated, where the rest of the system is lagging. Mapping your end-to-end process so you can actually see those bottlenecks is the starting point. We had a great conversation with Steven a couple of episodes back that touches on exactly that, and it's worth going back to if you haven't heard it. And if anyone listening wants to talk about what the future state looks like, we'd genuinely love to hear from you. We have ideas.
Dave: 18:14 I'd add this: the acceleration we're talking about is inside the organization. It's in the people you're meeting with, the conversations you're already having. It's not something that only happens out there with startups or partners. If you're not seeing it yet, it's not because it isn't there. It's because you haven't found it yet.
Peter: 18:44 Yep. Great conversation, as always. Looking forward to exploring more of this.
Dave: 18:54 Until next time.
Peter: 18:54 You've been listening to Definitely Maybe Agile, the podcast where your hosts Peter Maddison and DaveSharrock focus on the art and science of digital, agile, and DevOps at scale.