Flow Over Efficiency with Steve Pereira

Peter Maddison and Dave Sharrock sit down with Steve Pereira, founder of Visible Flow Consulting, to talk about something most organizations get backwards: the obsession with efficiency at the expense of actual flow.

Steve works with large companies to improve operational performance through value stream mapping and continuous delivery. But the conversations he keeps having aren't about cutting costs. They're about untethering capable people from the systems that are quietly holding them back.

In this episode, the three dig into why high utilization is often the enemy of good work, how lean thinking applies to knowledge work without losing what makes knowledge work different, and why adding AI on top of a broken system just makes things break faster.

If your organization feels like it should be doing more than it is, this one's worth your time. And if you want all 4 takeaways, don't miss the last few minutes of the episode.

This week´s takeaways: 

1. Step back from the work to look at how the work works. Whether it's a value stream mapping session or a quiet moment of reflection, intentional distance helps you see not just whether the saw is dull, but whether you're sawing the right tree.
2. High utilization is not efficiency. Running people and teams at full capacity removes the slack needed to respond, adapt, and make good decisions. Optimal is closer to 80 percent. The rest needs to be budgeted, not eliminated.
3. Understand your system before adding new tools. Whether it's AI, automation, or the latest framework, bolting new capabilities onto a system you don't fully understand tends to make existing problems worse, not better. Map first. Then act.

Extra Resources:

📖 Tools of Flow by Tody Goldratt: https://www.goodreads.com/es/book/show/75304520-goldratt-s-rules-of-flow

Chapters

• 0:00 Setting The Stage: Visible Flow
• 1:31 The Real Pain: Potential vs Outcomes
• 3:45 Beyond Efficiency: Untethering Talent
• 6:15 Flow Over Fragile “Efficiency”
• 9:20 Value Stream Mapping For Knowledge Work
• 12:05 Dependencies: Contracts vs Collaboration
• 15:10 Friction, WIP, And Utilization Traps
• 18:25 Budgeting Slack And Real Prioritization
• 21:05 Decision Systems: Triage, Andon, A3
• 24:10 AI Meets Flow: Manage The System First
• 27:05 Standardized Work Without Stifling Craft
• 30:15 Three Takeaways And Closing

Transcript

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. Hello everybody, wonderful to be here again. Today I'm with my good friend Dave and my good friend Steve. Steve, would you like to introduce yourself?

Steve [0:22]: Sure, yeah. Very pleased to be here. My name's Steve Pereira, also from Toronto, along with Peter. I run a small consulting company called Visible Flow Consulting. We focus on improving operational performance in large companies, specifically around continuous delivery and large-scale collaboration. Release processes, continuous integration and delivery, platform implementation, reorganization. I love talking about it, I love doing it. That's where most of my time goes. But where do we even begin? There's a lot we could cover. A lot of overlap with what you guys do, I think.

Dave [1:11]: Steve, maybe just to kick things off, what's the most common pain point your clients are coming to you with? Because we all work in overlapping spaces, and I think we each see different kinds of headaches.

Steve [1:30]: That's a good place to start. The most common thread, if I had to summarize it, is organizations that feel like they're capable of much more. There's this sense that they have strong capabilities, smart people, more than enough of them, and yet the outcomes don't match expectations. It could be something they hear about from a competitor, or from a totally different industry that gets them thinking about what's possible if they could change their environment somehow.

In my case, you'd think people come to me because I do a lot of value stream mapping, to eliminate waste and cut costs. But that's almost never what drives the conversation. They come with a desire to untether their staff, to let people perform at the level they know they can, but that bureaucracy, process, and legacy technology are holding back. That surprised me honestly. I thought when I started this work it would be all about cost cutting. More often than not, it's about the upside.

Dave [3:12]: I'm really struck, Steve, by how you described everything your clients are looking for without using the word "efficiency" once. Because so many organizations say, "We have all these people, why can't we get things out the door? We need to be more efficient." That's not the mindset you described. You described it as: how do we unlock the latent potential in the organization? We have the right people, the right things in place, but we're holding them back. That shifts the whole conversation once you start doing value stream mapping and looking for where the bottlenecks actually are.

Peter [4:06]: Yeah, the balance is: am I going to use this capacity to grow, or am I going to use it to shrink? More with less, or less with more.

Steve [4:18]: Right. And I would expect efficiency conversations to be more seasonal, more tied to tighter capital cycles or market volatility. But I'm honestly not sure the conversation has evolved that much. Personally, I don't talk about cutting headcount. If people look me up, they know that. I spend a lot of time talking about the system, and how that system enables individuals to perform, rather than focusing on the individuals themselves. So I try to stay in that space. I would hope the conversation is evolving.

Dave [5:49]: I love the idea that it is evolving, that the buy side is getting past the focus on cost cutting and headcount reduction. Because the latent potential in an organization offers so much more upside than grinding away at efficiency. And of course, what you end up doing when you do that is losing the heart of what's really happening. You lose resilience. You become more brittle.

Peter [6:20]: Yeah. You remove all the slack, which means you have no ability to flex when something unexpected turns up.

Steve [6:30]: And those people who were there to respond, well, they can't anymore. I think this is actually a common criticism of lean tools like value stream mapping, that they encourage wringing all the slack out of the system or trimming everything that would allow for serendipity and innovation. I've always believed the exact opposite. I get into some heated discussions with people who come from that angle. There's so much upside in taking the friction, the waste, and transforming it into space and freedom. Into conditions that let human creativity and ingenuity actually run. And there's an interesting angle on AI there too.

Dave [7:35]: It pulls almost in the opposite direction from what you're describing. Because when you give people clarity about where they're going, and remove the bureaucratic friction that stops them from seizing an idea and running with it, the energy goes up. Ideas start to flow. And it's interesting, nobody ever says "flow" and "efficiency" in the same sentence. Flow is about the intangible aspects of how work gets done. Efficiency feels more like someone somewhere has a stopwatch ticking.

Steve [8:42]: Yeah. And flow has retained this positive association in people's minds, both at the personal and collective level. I hope that doesn't go away, because it gives us a frame of reference that isn't associated with cost cutting or ruthless operational excellence. There's so much more to gain from an abundance framing than a scarcity one.

Peter [9:30]: The origins of value stream mapping come from the lean space, largely from optimizing how physical parts move through a factory. That's very different from knowledge work, where things are often unknown, and we need space to explore and think. We need that space to create flow in the system. Without it, things hit roadblocks constantly because there's no capacity to flex as direction changes.

Steve and I have both worked with manufacturing companies, and their view of value stream mapping is quite different. It comes from a diagnostic view of the system: how do I make every part operate as efficiently as possible?

Steve [10:30]: Yeah, and there's still real challenge there. I've spent a lot of time recently in the lean space with manufacturing companies and physical logistics companies. They genuinely struggle to take their lean knowledge and apply it to knowledge work, to invisible work. I don't think it's fundamentally different in every way, but it's a challenge. I spend a lot of time saying, don't throw the baby out with the bathwater. There's a baby in there. There's real value in value stream mapping applied to knowledge work, even if it's not a perfect fit. I haven't found anything that fits better. You do have to do some unlearning and relearning to apply it. You have to help people understand we're not trying to print the exact same outcome every time. And yet we do follow a process, we do put one foot in front of the other, we do aim not to run in circles. There is a flow we can visualize, measure, and optimize. And we can use it to enable more creativity, more innovation, more slack where we actually want it.

Dave [12:11]: When you describe that, Steve, what strikes me is that optimization in a creative space is driven by conversation and collaboration, not rules. In a manufacturing context, managing dependencies is contractual. It's physical space on a factory floor. In a creative space, you don't know when a dependency will show up. It might emerge in the middle of a project. So the dependencies are much more emergent. Which means rules-based dependency management doesn't really serve you. And in fact, anytime you try to constrain things too rigidly in that creative space, you tend to generate odd behaviors somewhere else that you didn't see coming.

Steve [13:33]: Right. It's interesting how constraint manifests differently depending on the context. In a factory, you want strict controls. Materials in exactly the right place, supply chains that make sure everything is there when needed. On the other end of the spectrum, a craftsperson like a woodworker or a painter, they still work within constraints around their medium, their domain, what their customers need. They make sure their materials are stocked and available.

In high-performing software organizations, you see the same patterns. There are contracts for mission-critical dependencies, because if anything in that chain fails, everything slows down or quality suffers. But there's slack in other places. And the real goal in both contexts is: if I need something to produce a valuable outcome, I can get it without hunting for it, asking for it, or waiting for it. Value stream mapping makes that visible very quickly. When someone should be able to just reach for what they need and can't, that becomes obvious. And then you have this environment where it's just part of daily life that the thing isn't available, so people just start something else. All those negative conditions we keep seeing.

Peter [16:59]: For sure. You end up running lots of things in parallel, and we all know what that does. All those unfinished pieces clog up the works.

Steve [17:08]: I actually just drew a simple illustration of what happens when a contributor hits friction in the flow of work. They just pick up another work item. Put the first one on hold, mark it blocked, start the next thing. And you get this accumulation of work in progress, driven by people who genuinely want to be productive and see progress.

Peter [17:44]: It's the utilization problem. You very quickly find yourself working on far too many things, and nothing is getting done because your attention is fractured across too many areas. Then when something truly critical comes in, you're already buried and can't take it on properly.

Steve [18:08]: And it's funny, in organizations that talk about efficiency, utilization is usually part of that conversation. But high utilization is often the opposite of efficiency.

Peter [18:21]: Yeah, I was using a graph last week in a presentation about this. There's an assumption that zero percent utilization means maximum cost, and 100 percent utilization means maximum value. But that doesn't account for all the friction that builds as you approach 100 percent. The handoffs, the waiting, the context switching. When you plot those two curves against each other, you can see that the actual optimal is somewhere around 80 percent. You don't want to fully occupy all the capacity in the system.

Steve [19:18]: Right. And I'd go further and say it's even better to be intentional about that spare capacity. To budget it, so that when you need it, you spend it in the right places. Not in lower-value areas, not on something that won't lead to better outcomes. It's like budgeting finances. The capacity is there, but you have to design how it gets used.

Peter [20:05]: Yeah, that touches on prioritization. What is the next most valuable thing we could work on?

Dave [20:11]: And with that comes the question of visibility. How do you make it obvious what to pick up next? In manufacturing, there's another product coming down the line. You don't have to overthink it. In knowledge work, especially something like woodworking or painting as a craft, you can start lots of different things. Knowing what comes next becomes part of the problem itself.

Steve [21:02]: We're definitely closer to that craft end in software. Every work item should be unique, an improvement on the last. That has a lot of implications. And just like you don't want 100 percent utilization, you also can't have 100 percent certainty on priority. And it can't be one person's job, or even one team. You need slack there too. People need room to use their own judgment. To say, yeah, I know this is top of the backlog, but based on a conversation I had 20 minutes ago, I think we need to rethink this. Strong visibility, a clear sense of value, and real knowledge of your customers are all critical to that. So you're not just blindly following the plan as it was shepherded through the system. That's very difficult to get right. Speaking of which, AI.

Dave [22:16]: Before we get into that, what you were describing made me think of the Hippocratic Oath. Medical practitioners have to make rapid decisions about priorities in very challenging environments. And rather than a rulebook, they have a foundational principle, do no harm or something close to it, coupled with a whole set of decision-making criteria. They can make rapid trade-offs under pressure. What I find in software delivery is we don't spend enough time understanding our own equivalent of that. The principles behind what we're delivering. You mentioned wanting to always leave the product stronger. But that's not universal. And we also don't build the practices that make rapid decision-making easier. There's so much ambiguity in how a prioritization decision actually gets made, which you just don't see in some of those other domains where more effort has gone into making decision-making clearer and less blame-laden.

Steve [24:06]: That's where it gets really interesting and challenging. The typical response is heavy upfront planning to avoid making the wrong prioritization decision. Very intensive analysis of obligations, criteria, timelines. Tight at the beginning, very loose in the middle, tighten up again at the end with multiple review cycles. And I can see why that happens when you're under pressure and have no time. But I don't think it's a viable system of work long term.

A more viable system looks more like what you see in manufacturing, where the assumption is we'll be doing this for a long time. So we invest in baseline capabilities. Things like triage, an andon cord so that when someone hits trouble they can signal immediately and there's a procedure behind that. A3 problem solving to iron out wrinkles in the system. There's more continuous decision-making, and more decisions built into the system of work rather than placed on each individual work item. The highest-performing organizations do this well.

Peter [26:38]: They have well-defined systems for making decisions. Things like andon cords, triage, A3s. These are mechanisms that help people make decisions in the moment. Teams have those tools at their disposal. But as you said, Dave, it's not uncommon for organizations to not spend enough time thinking about how decisions will actually get made here. What do we do when we disagree? How do we move forward?

Steve [27:18]: Yeah. And figuring out the right amount of structure there is genuinely hard. It took the lean world a long time to settle on standard tools. But we do have quite a bit at our disposal. One interesting connection, bringing us back to AI and value stream mapping, is the latest DORA report on AI-driven software development. They spent a considerable portion of the report talking about value stream management. Basically value stream mapping as a continuous practice of managing flow. I was pleased to see it get more attention. But the angle they were presenting was: in order to leverage AI, you need to understand your system of work first. Because it's very easy to waste a lot more money with AI. Very easy to implement it where it will actually make things worse. The narrative was, spend time on your system of work. Understand how it performs, what it looks like, how to measure it. So you can focus on what's actually holding you back, rather than just bolting AI on top of a system that's already struggling.

Peter [29:47]: Otherwise things can go wrong pretty quickly when you start injecting non-deterministic systems into what should be deterministic processes. There's certainly enough noise out there now around whether that's contributing to more production failures.

Steve [30:16]: And it cuts both ways. AI can be an incredible tool for diagnosing failures. But it can also do something that looks like a fix without anyone really understanding what it changed, and whether that's causing a different problem somewhere else. Double-edged sword.

Dave [30:45]: I have a few stories around that. Maybe just as we head toward a close, one quick question. You talked about standardizing work, and how long it took in the lean manufacturing world to get there. One thing I keep seeing in software and digital delivery is this resistance to standardization. The creative identity of the people doing the work gets bound up in it. Standardized work feels like a threat, even in areas that are genuinely repetitive and well-suited to automation. The DevOps movement pushed back on that a bit, but I still see programmers struggling with it in many areas.

Steve [32:11]: Yeah. Finding the middle way there is genuinely hard, because the practices are evolving and inherently flexible. It's very natural to say, why constrain this when it doesn't have to be? The spiral of infinite recursion, try a little thing, put it out, see what happens, go with whatever feels good.

Where it really becomes friction is when process is a manual, onerous obligation that doesn't get instrumented into code and automation as quickly as possible. Individual contributors worry that once something gets standardized and mandated, nobody's going to revisit it for nine months. And honestly, processes do calcify quickly. We think of software as dynamic, but processes really don't change until something forces them to. That's part of why I like value stream mapping as a tool. It forces the question: does it have to be this way? Do we want it to be this way? And how would we redesign it given that our goals have probably changed since the last time we looked at this?

The standardization people actually resist isn't the "commit your code and have everything just fall into place" kind. They want that. What they resist is jumping through hoops, filling out forms, waiting for someone else to approve something. Make the path clean and automatic, and people will use it.

Peter [34:39]: And when it works every time, even better.

Steve [34:40]: Exactly. And that is truly difficult to do. Which is why we'll all be in business for the foreseeable future. This work is hard.

Peter [34:56]: Very true. On that note, it's probably time to wrap up. We like to close with three takeaways, one each. Steve, as our guest, you go first. What would you like people to take away?

Steve [35:18]: Glad I'm only on the hook for one! I'm a huge fan of stepping away from the work to look at how the work works. How is the system performing today? I've never found that not to pay off. So whatever form it takes, even if it's just a conversation or a quiet moment of reflection, step back from the day-to-day. Not just to ask whether the saw is dull, but whether you're sawing the right tree. It's so easy to get caught up or distracted by everything that's constantly emerging, and neither of those conditions is great for designing a better system of work. Intentional distance to observe, reflect, and act is really powerful.

Dave [36:18]: For me, the phrase I'm walking away with is "tight, loose, tight." As you were saying it, I was immediately thinking of several organizations where that's almost exactly what's happening. And often in different departments, which adds another layer of complexity. That tight, loose, tight pattern gives a feeling of control without actually generating predictable delivery. So for me the takeaway is: how do you get to less loose, but also less tight, by actually stepping back and looking at the system of work.

Peter [37:12]: I'm going to leave the audience with something to read. We touched on triage and some related concepts. There's a book, I believe it's by Eliyahu Goldratt's daughter, called something like Concepts of Flow or possibly Tools of Flow. Steve, you might remember the exact title better than I do. One of the concepts she gets into is triage and other mechanisms for thinking about how work gets prioritized as it enters the system. Worth reading. Some real gems in there.

Steve [37:49]: I love that book. I think it's called Tools of Flow, but I might be wrong. And the one thing I'd add, totally stealing from that book, is full kit. The concept of giving someone everything they need to complete a task from beginning to end, uninterrupted. That was the first time I truly understood it, and it's stayed with me ever since.

Peter [38:42]: Same. I've used that idea many times. Awesome. Well, thank you very much Steve. Fun conversation as always. And thank you Dave, as always. Until next time.

Steve [38:58]: Thanks for having me.

Dave [38:59]: Thanks a lot, Steve. Thanks Peter.

Peter [39:02]: 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.