#173 - Flow Engineering: Collaborative Mapping for Effective Action at Scale - Steve Pereira & Andrew Davis

[00:01:07] Introduction

Henry Suryawirawan: Hello, Steve. Hello, Andrew. Welcome to the Tech Lead Journal podcast. Today, we’ll be talking about your new book, Flow Engineering from IT Revolutions. I’m really excited, actually, when I read the book as part of the preparation of this talk. So flow is something that is quite a trending topic these days. So many people are talking about it, how improve your value stream and things like that. So, really excited. Welcome to the show.

Andrew Davis: Thank you so much, Henry. Great be here.

Steve Pereira: Thanks for having us.

[00:01:33] Career Journey

Henry Suryawirawan: All right. So Andrew and Steve, so I always love to ask my guests to first share a little bit more about themselves. So if you can maybe mention about highlights or turning points that you think we all can learn from you, that will great.

Steve Pereira: I’ve been in tech for a couple of decades now. Um, I started in kind of IT and tech support and worked through a bunch of different individual contributor roles. And speaking of turning points, I would say that DevOps was definitely a turning point for me. I was always kind of one of those people who was interested in the gaps, in the handoffs and flow before I really knew that’s what I refer to it as nowadays. But another big inflection point was taking on a role as CTO and being very responsible for end-to-end delivery and scaling an organization, especially working with enterprise clients. So kind of put everything to the test and learned a lot and failed a lot and brought a lot of that into consulting. So that’s kind of my path.

Andrew Davis: And working backwards, I guess, Steve and I met each other three years ago, Steve, at DevOps Enterprise Summit Conference, where he was running a session on value stream mapping. And I asked him if he had any book recommendations on value stream mapping for tech organizations in particular. And we ended up having to write it ourselves, because many of the books on value stream mapping cover, center of gravity more focused on the traditional manufacturing space.

So my background, I had studied engineering, but pretty early on decided not very interested in a conventional career. And so I spent about 15 years as a Buddhist monk. And so I was during that time running meditation centers for about 10 years, but also with my technical background was the Head of IT for that organization, a global organization for a few years. Then over the last 10 years, while I was a monk, I discovered salesforce.com as offering free licenses for nonprofits. And we had a big federation of lots of nonprofits. To me that looked like lots of free licenses, and so I sort of had this vision of I can get free licenses here, free licenses here, free licenses here, and integrate the whole thing, syndicate some of the code, and then all of a sudden we would have some technical management infrastructure to manage all of these meditation centers, which we were sorely lacking.

I never actually ended up bringing that to fruition, but that led me to choose to focus on Salesforce when I stopped being a monk. And so pretty early on, I was a Salesforce developer. Pretty early on, I realized that there were a lot of struggles with the development process in Salesforce. They were just a few years into even being able to write code on the Salesforce platform, but nobody was using version control. So there’s no history of changes. So I would write something, come back a month later to make an edit. And I’m like what is this? Did I write this? Did somebody else write this? Has this changed? Did I just forget? There was just so much confusion.

So I started going deep, digging deep. And I had a manager at the time who encouraged me that we needed CI for the masses. We needed all of the Salesforce projects to be able to do things like this. And I took that commission very seriously and I’ve ended up being focused on DevOps for Salesforce, kind of breaking ground with that as a new area for the last 10 years. Wrote a book, Mastering Salesforce DevOps, my first book, and was the first book to really speak comprehensively to the Salesforce development life cycle. That was about five years ago.

When I transitioned from the tactical bit, you know, version control and setting up Jenkins and running static analysis and so forth to when I went to the DevOps Enterprise Summit, now the Enterprise Technology Leadership Summit run by IT Revolution. That was what really blew my mind for the first time, because all of a sudden, it was a room full of technical people, a big auditorium full of technical people. But we had Dr. Christina Maslach, the world’s leading researcher on burnout there. And the psychology of this. And then the CEOs and the guy who overhauled Walmart’s IT infrastructure to create an event-driven system.

So it’s just all of these big thinkers in technology and how teams work better together. The bridge from technology to business. I just realized this world was much bigger than I had appreciated. And so it really, um, I’ve been delighted to be part of the DevOps community and then increasingly also in the last couple of years, trying to go deep on Lean and become part of the Lean community as well.

And then six months ago I took on a role as Chief Product Officer for a company that builds tooling for Salesforce teams in highly regulated industries, Auto Rabbit.

Henry Suryawirawan: Thanks for sharing your background story. So when you mentioned about not many books covering value stream mapping for tech world, I think now that you said it, yeah, I kind of like agree with that. A lot of probably VSM comes from old TPS, right? Toyota Production System or manufacturing. A little bit of highlights maybe in some Lean books. But yeah, specifically dedicated to talk about value stream mapping is probably a bit rare.

[00:07:12] The Problem with Scale

Henry Suryawirawan: And speaking of which, both of you have come up with the book, Flow Engineering. So first of all, right, when I read the initial few chapters of book you actually basically first came up with the background that a lot of problems in the organization comes from skill. So when we talk about flow, probably the smaller you are, maybe it’s not so much of a worry. And you actually speak about problem of scale in an organization. Maybe let’s go there first about the background. So why do you think that flow engineering probably is more applicable to kind of like a big scale organization?

Steve Pereira: Well, one thing that I want to mention, I’ll throw it to Andrew for some of this. But one of the things I want to mention is, you know, we had the great privilege of, as a result of working on this book and diving really deep in this space, building a relationship with Karen Martin, who has written kind of the seminal book on value stream mapping back in 2013. And we learned a lot from that book, and what we’re really trying to do with flow engineering is kind of make that as accessible as possible to an audience that we consistently hear doesn’t have time for value stream mapping. Can’t get the buy in for it. Can’t make the space in their doing to step away from the work and do the mapping and kind of understand the workflow. And might struggle to describe it to people or get them excited about something that is largely associated with manufacturing. So our effort was really to kind of build upon that foundation and make this very, very hard to say no to. Make it very easy for people to dive in and acknowledging those aspects of scale that kind of hold people back from all the things that they want to do, whether it’s value stream mapping or otherwise.

But we do touch on three specific costs of scale. And one of the things that kind of resonated with me in looking at why we incur these costs and what sort happens in organizations is as we scale up, the distance between everything in the organization kind of increases. So the distance between what you’re doing and what happens down the road, the distance between you and the ultimate mission of the company. Your kind of long term forecast, you know, you bigger plans, bigger impact. In a lot of cases, you’re physically much further away from people that you have to work with, whether that’s your colleagues or partners or customers. So this distance creates these conditions. But I’ll throw to Andrew to run over those specific costs that we highlighted, cause I don’t want run the mic the entire time.

Andrew Davis: Ha, ha, ha, ha, ha. Yeah, well, so the three specific costs are the cost of disengagement, disorientation and distraction. And very early on in Steve and my discussions, we settled on three positive characteristics that characterize an organization that was operating maximal effectiveness, high flow. And that was value, a clear sense of the value that you’re delivering, including the value that your own efforts make towards the organization, the value of how your product is bringing benefit to end customers and so forth. Clarity, meaning a sense of orientation, awareness of how you fit into the bigger picture. What the handoffs look like, what good looks like and so forth. And flow is the result of having a clear sense of value and a lot of clarity. Then you can get flow in the sense of a smoothness of action.

And when we were coming back to the idea of scale, Steve and I also quite early on seized on flow having two meanings, like there’s this sense of individual flow, psychological flow state, like Mihaly Csikszentmihalyi’s book on flow that when the challenge is well-matched to your capability and you keep increasing your capability and the challenge keeps getting higher. And you see people investing thousands of hours of their lives playing video games, say. Why? Because they get a sense of flow. You know, the challenge keeps going up and they keep getting better. And there’s this natural, it resonates deeply with us. We feel like we’re doing something useful. So that’s individual flow, psychological flow.

Then there’s collective flow. And collective flow is the handoff from one to another to another to another. And if you look at these old school manufacturing facilities where you’ve got assembly lines, there’s just literally a flow of parts. And especially if you speed it up, you just see this liquid like river-like stream of material and people and so forth. And one of the tricky things in the tech world is that everything we do is invisible. And it was a Lean conference a couple of years ago, where once from the stage and twice in just interpersonal interactions, I heard people say, people from traditional manufacturing backgrounds say, if it’s in the computer, it’s hidden. If it’s in the computer, it’s hidden. Because they want everything on big boards and displays and signs and so forth. And I thought, oh man, we’re in trouble. Because if it’s in the computer, it’s hidden. Like, how do we keep oriented? How do we get and maintain that clarity, right?

Now, it is computers that enables us to be having this conversation across the internet. Computers enable scale at a level that was just inconceivable previously. That even though you’ve got physical distance and mental distance and so forth, the computers can help patch in and create the handoffs and so forth. But at the same time, when, you know, if you and I were sitting next to each other on laptops, I’m most likely going to be working on something totally different from what you’re working on. We’re in totally different worlds. And so the default when everybody’s on their own computer is that we’re in different worlds.

Whereas if you’re in the same physical manufacturing facility, that the physical world itself integrates your minds. And so you’re integrated around the physical reality of, oh, there’s a mess here and there’s something that needs to be done here. And here’s a guy coming with a request and an order. And because you’re integrating around the physical reality, and then in the IT world, you can’t integrate around the physical reality, so you’ve got to construct a reality that people can integrate around. And if you don’t do that, if you don’t do that well, if you don’t create an environment where people can really see what’s happening and how they fit into the bigger picture, they become gradually disengaged.

And that’s where you’ve got the Gallup organization saying, you know, 75% of people in organizations are disengaged or actively disengaged. And then also there’s just stuff, you know, emails and Teams messages and Slack messages and documents everywhere, and so you get disoriented. It’s just more than the human mind can handle. And I think even for me, you know, in the IT world, the pace of notifications and document sprawl and so forth, and my level of patience for figuring out where everything is has gone down, right? So you get this disorientation where people just don’t know what’s going on. And then distraction, bigger organization, more coworkers, more projects, more people pinging you, harder to actually be in a flow state. And so these, we describe these as the three costs of scale. And targeting flow engineering to address those.

Henry Suryawirawan: Very elaborate answer. So I would say that I have the opportunity working in a big scaling up kind of a company. I could actually see all these kind of costs or problems that you just mentioned, right? Disorientation, disengagement, and also distractions. I think in tech world these days, distraction is kind of like given. You know, having all these chats and meetings and, you know, a lot of things that we have to take care about.

[00:14:49] The Danger of Increasing Coordination

Henry Suryawirawan: And I think in many organizations, the first approach when they want to increase their business value, be it revenue or be it more profit or even building more products, is actually to add more people, right? And over the time, they figure out, oh, we have so many people, things seems to be moving slower, interestingly, right? So it’s not as fast as they thought. And because of that, what they do is actually increase coordination, the thing that you mentioned in the book, right? So tell us why is the danger of this increasing coordination when people perceive things actually don’t work as fast as they thought it would?

Steve Pereira: Yeah, I think coordination is really a fascinating thing. And, I think, actually, building on top of coordination, collaboration is something that’s very interesting as well. Like coordination, that the fact that we have all of these people and inside of each individual, they have a representation of the system, right? They have a representation of the most important thing to focus on, the essential practices, the most important people to talk to, who to go to for what, how to prioritize, what to do in certain scenarios. That is so distributed and different between all individuals. And it’s not often reconciled, right? We don’t often sort of step away from the work to say like, how are you doing? What’s your biggest challenge right now? And we do some of this in stand ups, or we’re supposed to, and we end up reporting on status and blockers rather than kind of converging and coming together. And we do a little bit of it in retros, but this is a continuous challenge. It happens all day, every day.

And so, to kind of address this, we do a lot of communicating and we do a lot of sharing of documents and status updates and pushing and pulling information. And that all has a significant cost, right? I mean, it really adds to distraction in a lot of cases. It can add to disorientation, if you were thinking in one direction and some information comes in that pulls you in another direction. And then, you know, on top of this coordination idea that we have to kind of converge and all get on the same page and maybe we do big room planning every quarter to coordinate everybody. That can happen, but we also have to kind of converge prior to doing a release, right? We have bring everybody together. We’ve got to bring in marketing to make sure that they know about the thing that’s going out.

And so all this coordination is usually very active and intensive, right? It’s like it’s hands on, it’s very manual. It doesn’t really happen via kind of radiating information thatpeople canjust pull and do their thing and then contribute back to the whole. It’s a very high cost. And collaboration is another high cost, even more intensive because we’re talking about working actively together, which means it has to be at the same time and we have to be very closely aligned and we’re kind of passing the baton hand-to-hand.

So I think these are kind of unappreciated costs as much as they are incredible benefits. You know, we talk about the benefits of collaboration, but it’s not free. And the less structure it has, the less culture it has to support it and protocols and patterns and guidelines and principles. And just experience of working together where you build rapport and familiarity, it all is much more difficult. So you kind of turn the dial of more people and you’re incurring more costs, but there’s more risk of miscommunication and all of these negative consequences.

Andrew Davis: There was a research report that we highlighted in one of the early chapter on the cost of scale for Microsoft and Facebook. Looking at groups from 1 to 32 people and how well they work together and how much effort was expended by each individual. And they came to the conclusion that there was just an enormous amount of… it certainly wasn’t additive. Like the 32 people do not do the work of 32 people. 32 people to do the work of like 9 people or 12 people, something like that. And there was a phrase we settled on in the book. But nevertheless, there are net benefits to working together as a group. But there’s this huge hidden cost.

And so the reason like I love Steve’s comment, you know, that you solve these problems by hiring new people. Oh sorry, it was Henry. Henry, you made the point that you’re solving these problems by hiring new people. So the organization is scaling because you want to do more and more and more. And you do do more. And you see the benefits of scale, but there’s this profound hidden cost and beneath the, you know, whatever 10 percent per year the company is growing, there’s just this profound inefficiency that’s cropping up. And so we settled on the phrase that working together is best, but it’s not our best work. I might be misquoting myself, but working together is best, but it’s not our best work. Like we’re not as well coordinated with everybody else. There’s a lot of waiting time, handoffs, confusion, lack of effort, thinking that somebody else is going to do it.

[00:19:58] The Paradox of Scale

Henry Suryawirawan: Yeah, so I like that quote, right? So working together is best, right? But we may not produce the best work, if your team is not kind of like highly effective and highly performing, right? So I think speaking about this study, right? I think one thing that I also find interesting in your book, you mentioned this paradox of scale, right? So coming back maybe to the topic of people getting disengaged or maybe the cost of scale. So you mentioned that individuals effort actually declines as the group size grows, right? So this is actually also a very interesting phenomena for me, right? And maybe that’s why many people are disengaged in a bigger organization rather than a smaller organization. Or maybe people don’t put up more in terms of effort. So maybe tell us a little bit more about this paradox.

Andrew Davis: I’ll briefly hit that. It’s the same research report and it does highlight what’s known as the Ringelmann effect, which is that as you get a larger number of people working on something, the effort that each person exerts becomes less. And if you think about a game of tug of war, if it’s you and another person playing tug of war, you both will apply maximum effort on the rope. As soon as you get a second person, the two people are not going to be applying quite as much effort as they would’ve. If you got 10 people there, everybody’s pulling a little bit, right? But nobody is pulling nearly as much as if they were just the only person on there. And you can literally measure the force that they’re exerting on the rope.

Steve Pereira: Yes, I mean, that’s great. I love that analogy of the tug of war. And I think we can see this manifested and it might be a little bit counterintuitive, right? Because it’s not as if people just inherently take advantage of system and take an opportunity to contribute less. I think what’s really happening is that there’s so much complexity that’s added when you add people and there’s so much communication overhead and collaboration and coordination that’s happening. It all becomes overwhelming and you don’t want to be pulling too hard in one direction when you have to be working in concert with everybody, right? I mean, ideally, everybody pulls the same and exerts the same amount of effort. But it’s very difficult to know what that is. And it’s very difficult to actually effectively do this.

And so, I think the way that we pull from that in the book is say this is an inevitable cost of scale. And there are more benefits than costs, but because of the benefit and that we want to realize the benefit and we don’t have a better alternative than working in groups, you know, our best work can be done in highly effective teams of the right size. And so we have to do this. But there’s a big difference between doing it well and doing it poorly. And it takes intentional practice and principles and guidance and the right systems to enable that effective action that we call it effective collective action, that gets everybody kind of pulling in the sweet spot in their flow state so that we have individual flow creating collective flow.

Henry Suryawirawan: Right. So the three elements of this collective action in your book, which also brought up by Andrew in the beginning, are value, clarity, and flow, right? So you hypothesize like with this three in place, right? So as the organization scales, probably we will see much benefit rather than having more costs or the tax of having so many people.

[00:23:34] Flow Engineering

Henry Suryawirawan: Which probably brings us into this flow engineering. What is actually flow engineering, right, in the first place? Many people might know about flow. Of course, many people know about engineering, but flow engineering, is kind of like new term. So tell us a little bit more about this.

Steve Pereira: Flow engineering, you know, in very simple terms, I think, is an effort to share a term that’s memorable and easily understood by folks that doesn’t have the associations with traditional manufacturing that value stream mapping does, for one. Because it’s more than value stream mapping. You know, a lot of people, they hear value stream mapping and they think, oh, great. Like that works for a factory. We don’t want to be a factory. We don’t want to work in that kind of environment. And so we really try to separate the goal, which is effectively engineering flow from any specific practice, whether that’s value stream mapping or otherwise.

And in our experience with value stream mapping, and as you practice mapping value streams, you really quickly start to understand that you can’t just dive into mapping a value stream. You know, you have to really establish a clear direction, you know, a sense of value, what are we trying to achieve? And then understand the current state landscape, which includes a value stream. But it also includes things like what other factors are affecting our performance? What are the things that we’re struggling with? What is the context of our current activity? Because that really factors into what you notice when you go to map a value stream. When you go to create this sense of clarity, understanding this information up front and all starting on the same page really makes a big difference.

So flow engineering is partially kind of adding that very explicitly into the early stages of activities. So come together and and set a clear target. But then, on the other hand, it’s taking what we learned by mapping the value streams and looking at value streams and looking at constraints and the data and measurement that we uncover through mapping, and translating it into action. And that’s kind of the second part of the equation is it’s great to find things in a value stream. It’s great to find opportunities and understand to a deeper degree what’s holding us back from flow. But it’s useless if we don’t act on it, right? I think we’ve all kind of been in a retrospective where, you know, we discover all these things and then everyone leaves saying, okay, we’ll try harder next time, right? I think you’ve always got to take what you learn and make it actionable, and make it part of improving the system going forward.

So that’s where we really kind of add these explicit practices to kind of introduce value stream mapping with very little initial context necessary to keep it very lean and very simple and very minimal. And then at the end, to really drive that value forward and ensure that it actually makes a difference, the roadmap that you build with the insights and the actions that you’re uncovering during the mapping takes you all the way through a complete program that hopefully makes a big difference in the organization.

Henry Suryawirawan: Right. So thanks for explaining about what is flow engineering. Yeah, first of all, it’s about coming up with a term, right, so that we don’t always associate this thing with value stream mapping all the time. And it’s actually a set of practice. And the way it works, just like what you elaborate just now, I think it sounds like a feedback loop, right? So where you actually first know where you want to go, do something and currently understand how you’re doing it, what kind of problems, blockers, and things like that. And then set the actions, right? Just like what you mentioned in the retro, if we do it properly, right, we will do some actions. And then over the time you kind of like repeat the cycle again, right?

[00:27:50] 5 Primary Maps

Henry Suryawirawan: So I think this can work at a smaller scale, you know, in the team level, but also at the organization level. And I think in your flow engineering, you have a few things that we can do, the activities that we can do. And actually to map this kind of feedback loop in the organization. Maybe tell us a little bit more, in probably one by one, right? What are those tools that we can use in flow engineering?

Andrew Davis: The book introduces five primary maps that are the actual execution of the flow engineering practice. And you mentioned about the idea of feedback loops. We borrowed a lot from the principles of cybernetics when we’re talking about the problems of scale. So cybernetics as a discipline in the 20th century spent a lot of time trying to understand what are general rules that would apply to either humans or groups of humans or technical systems, but is basically some scale free rules. Some rules that apply at any scale. And so the idea of setting a clear target, and you mentioned this, right? Setting a clear target, , getting clarity on what’s your current situation, what are the gaps and so forth, and then having a feedback loop about are we there yet and continually adjusting in that direction. That was the spirit of this.

So these five mapping exercises, the first one is really to get clarity on the target state and we call it outcome mapping. And that really addresses the issue of engagement or disengagement, opposing disengagement. You know, I think often initiatives or directives would be set from a higher leadership and imposed to some degree on the organization. And people are asked to participate in that but without fully understanding either what is the outcome that they’re supposed to accomplish or why that matters. And just naturally as human beings, one of the things that interferes with our level of engagement is if we don’t understand why we’re doing something.

Now the executives who set forth the vision might understand perfectly why we’re doing something. But that’s not going to help the individuals if they don’t internalize that themselves. And that’s the, really, you’ve got to span from the psychology of whoever’s setting the goals, right, to the psychology of the individuals who are executing it. And that getting that clarity on the outcome is the first step. And that often is missed if people just dive right into value stream mapping.

So value stream mapping, we introduced as the second of these mapping exercises. And that is basically to get that clear end-to-end vision of the process, the sequence of handoffs that generate that are value producing. And Steve really encouraged us to take a working backwards approach. Like from the final product, what’s the step that precedes, you know, what are all the value adding steps preceding delivery of a final product?

The third mapping is dependency mapping which after a lot of debate we settled on just it’s zooming in, it’s taking a deep dive view of part of the value stream map that is suspected to be the primary bottleneck. Followed by future state mapping, which again is a value stream mapping exercise, but this time envisioning the future state.

And current state value stream mapping, future state value stream mapping, all of this does resonate with prior work on value stream mapping. One of the things we really wanted to do is optimize for these people who are not only busy and struggling to get approval to set aside time and so forth, they’re also impatient, right? So how can we break this down in relatively short exercises, two to three hours, to do the value stream mapping? Identify that the area that you think is likely the culprit and then do dependency mapping to do a high resolution. Zoom in on that one section, understand that better.

Future state mapping then is, okay, with the understanding we’ve gained, how can we improve that? And then you identify a sequence of improvement activities. And the final map is flow roadmapping about how do we carry that out? What are we going to do to actually implement these changes so it’s not just walking away and with a scattershot approach to, yeah, making it better.

Henry Suryawirawan: And I think, what is really interesting when you mentioned about people getting disengaged and not understanding what they are trying to do or the company is trying to do in terms of outcome, the clarity, right? So I think you kind of like come up with these tools, and uniquely they are all called maps, right? So map is like something that we create so that people get a shared understanding. So I think that’s the key thing so that people get the shared understanding, know where they are going, right? And probably the roadmap also tells them that, okay, because we want to achieve this target, we have this plan. Everybody gets together so that they are aligned and maybe, yeah, no matter what scale they are, they will get clarity, they know the value that they’re bringing and they also can do it, I mean, in terms of action, right? Do it in such a flow kind of a state, right? So I think a really important thing.

[00:32:31] The Biggest Impact Maps

Henry Suryawirawan: Maybe if you can, from your experience, right, if you can share, which map actually helps people to ramp up the most? Because so many organizations might not have this mapping exercise. But in your experience, probably which maps that you think gives the biggest impact if organization wants to do it in the first place.

Steve Pereira: Oh, this is good question. I like this question. I think that, you know, in terms of bang for the buck, in my experience, and this is part of the problem, is that value stream mapping is extremely powerful. Like current state value stream mapping. Everybody I talked to in every map that I’ve ever built with a group, you find the 20 percent of what’s happening is totally unnecessary and could go away tomorrow and would have no negative impact on customers. It would just make everything faster and easier. And that’s very high return on investment. It’s remarkable and consistent. And this is part of the reason why people kind of just dive right into value stream mapping, because they hear that, oh, it’s fantastic. Hear great things about it. And then they struggle because they haven’t done the groundwork to understand where should we focus on that value stream? What level of detail would be valuable? What is the scope? What’s the stream that we should focus on?

And so, the outcome mapping, it’s absolutely necessary to have that level of clarity. And we like to say with flow engineering, like if everybody knows what is revealed by any of the maps, they could skip it, right? If everyone is on the same page and everybody has absolute clarity on the target outcome, the benefits of that, the obstacles and how to proceed, go ahead and skip it. And likewise for everything else, right? You can skip all the flow engineering if you already have all the answers. But we find that’s never the case, right? If you ask three different people what the most important focal point is or where the biggest obstacle is or where the constraint is, you will get three different answers.

So we think it’s really important to start with outcome mapping as a foundation. But that’s another reason why, you know, we keep all this very minimal, very small scale. We’re targeting 90 minutes for every map. And sometimes you can’t get everything done in 90 minutes, but you get so much value for that time that it pays for the next map and it pays for the next session. And that’s kind of rather than having people try to get buy in for something massive and then doing nothing if they fail at that, we’d rather make it something that fits into the spot that they’ve got for a retro, right? Try something different for your retro. Try something different for your lunch and learn. Try something different for your offsite. Just to make it very easy to say yes and try it out.

Andrew Davis: The five maps are interlinked with each other and they are sequential. They each build on the other. So value stream mapping is huge and outcome mapping as the prior one. Because it is critically important, as Steve was saying. We’re in the space of unknown unknowns. And we as humans assume we know, like we have evolved to assume we know the reality. We substitute our mental models of the world for actually directly perceiving reality. And so we’re continuously acting as if we know what’s going on. And generally that means we ignore all the things we’ve learned to ignore. And where Steve said, we’ve got these disparate mental models. This aligning and creating a coherent shared picture of our disparate mental models is what we’re talking about with the mapping.

And you, Henry, called out, we’re using the metaphor of mapping. And we often say the mapping is more important than the map. And so the map is like some final artifact, but it is in the process of mapping that what you’re actually doing is having a visual conversation with the team. And as I surface part of my understanding, I externalize it on the map and then you internalize that and say, ah, yes, and then you share your understanding and see how that map in that fits in. And we’re able to do it collaboratively, digital, you know, digital whiteboarding or physical whiteboarding, you’re able to do it collaboratively. Really it’s a conversation, it’s aligning of these mental models. And the raw benefit that you get from this implies there was this hidden cost, and this is the hidden cost of scale. It’s this disorientation, it’s this sort of lack of clarity on what’s actually going on, that really can only be resolved by making an intentional effort.

Henry Suryawirawan: I like that you emphasize that the mapping exercise is actually more important than the map, right? So that reminds me of this quote as well, right? So all maps are wrong, right? But some, not all maps. All models are wrong, but some are actually useful, right? So I think the key, again, to get the shared understanding between many people. If you have a larger organization, definitely, it’s really, really more difficult to actually get this shared understanding. And doing this mapping will create a mental model so that everyone has aligned mental model, so to speak, right? So people are more aware of what is going on in the company and what kind of target they want achieve.

So not only the maps, you know, the tools that you give people to try out and experiment. But you also kind of like give five principles that we need to adopt or need to be aware of when we want to practice this flow engineering much, much better. So I think the principle sometimes is also more important, because we can be given all the tools that, you know, may work, right? But actually, if we execute it wrongly in the wrong spirit, right, the tools may not be able to solve your problems. So tell us a little bit more about these principles.

[00:38:23] All Maps are Wrong

Steve Pereira: I just wanted to quickly talk about that. You initially said all maps are wrong and then corrected that all models are wrong, but I think you’re also right to say that all maps are wrong, right? All maps are just a representation. And the only reason that we kind of settle on any representation of what we think of as reality is that we all say, okay, well, that’s, good enough detail. You know, it’s useful enough that we can use it. It’s not so detailed that we get lost in perfect accuracy and we can’t actually abstract away what we really care about, right? Cause we might just want to get to a restaurant. But there’s diminishing returns in perfect detail.

And this is one of the things that I think people really struggle with with value stream mapping is they’re really unclear about what the right level of detail and accuracy is. And they’re kind of tripped over this desire for accuracy and precision when all we really have to do is find a focal point, right? We need to take everything that we could possibly do. And all come together and just decide, okay, this is the most important thing to do. And once we accomplish that, we can move on to the next thing, and we’ll be way better off than trying to divide our focus across everything that we have possibly to do. And, you know, it could be one thing, it could be five things if you’ve got capacity. But often it’s 50 things because nobody is focusing and nobody has that level of clarity and decisiveness.

So I just wanted to mention that. And I’ll toss back to you, Andrew, because I thought that was interesting. I don’t disagree. I think that all maps are wrong.

Andrew Davis: Yeah. yeah, agree. And I mean, a map is just a model, for example. So it’s totally apropos.

[00:40:11] 5 Principles of Flow Engineering

Andrew Davis: You know, Henry, you’d asked early on about what is flow engineering? And Steve and I, both coming from technical backgrounds, we’re familiar with software engineering and network engineering. And it’s the idea that everything’s a technical problem to be solved.

When it comes to flow, either individual psychological flow or team flow, handoff and so forth, you’re working in a psychological environment or sociological environment, right? These are domains that sometimes engineers are undereducated on, so I’d say our book is in the same vein as books like Wiring the Winning Organization by Gene Kim and Steve Speer that are talking about social circuitry, right? And helping to use this metaphor of engineering or social circuitry and so forth for all of these overly technical-minded people to try to make sense of the real human challenges that we’re dealing with in our organization.

So when we talk about this five principles, like the third part of the book is on scaling flow engineering. So this first part, we talk about scale and the challenges of scale. The second part, we introduce these five maps. The third part of the book is about scaling flow engineering. And when you talk about scaling flow engineering, you’re wanting to make sure that you can get an increasing number of people in the organization familiar with conducting the exercises, but also to sustain the value of an initial value stream mapping exercise and improve flow. There are new understandings that need to be internalized by the team.

And so Steve and I are big believers in the power of principles as like a real condensation like the pith essence of an insight or an understanding that people in an organization can internalize. If they internalize those principles, those principles provide wise and reliable guidance in a variety of situations. And so it’s a way of enabling decentralized action. You train people in principles and then those people go off into some, you never see them again, but they’re still operating based on those principles and the principles are still working. And that’s the magic of sociology, right?

So these five principles, we spent a lot of time sifting through what’s really required to make this work and so forth. And I spent some time organizing it, and eventually I couldn’t come up with a better system than these what I call the five principles of lean. And these are borrowed from Jim Womack and Dan Jones' Lean Thinking. This book’s about explaining lean, and so they are the principle of precisely specifying value. Precisely specifying value, very much like the outcome mapping. What is the goal you want to accomplish? Mapping the value stream. And so map precisely specifying values very closely aligned with outcome mapping, our first mapping exercise. Mapping the value stream is basically the second of the exercises.

And then the idea of creating flow and really aiming for what can you do to enable a steady, continuous flow. And that’s all never possible perfectly, but it’s based against an idealized state. What would perfect flow be like? But even the idea of taking an ideal state as your guiding light, as your North Star, is very powerful psychologically. It doesn’t get old, right? If you keep working towards enabling flow, that’s a reliable North Star. That’s a reliable guidepost guide star for ongoing improvement, because there’s always going to be something different that is inhibiting that flow. And, you know, first of all, it’s waiting periods, and then it’s lack of automation, and then it’s confusion, then it’s multiple, you know, too many handoffs, and blah, blah, blah. But as you try to create flow, you discover what are the obstacles. It basically is a continuous process of discovering obstacles.

The fourth of these Lean principles which we adopted as flow engineering principles, giving credit to the authors, is enabling pull. You know, this idea which was really quite significant from the TPS, the Toyota Production System. Which is really, Toyota has recast that as TPS is the Thinking People System. So they really want people to stop saying Toyota Production System, start saying the Thinking People System to really point to what that means. And then enabling pull, not push, right? We don’t build anything unless the customer has actually requested it. And that is, that creates this most efficient process where you’re not producing more work in progress than you can have consumed by. And so it’s consumed by the end users. And so it’s a characteristic of an optimized system.

The final principle is this relentless pursuit of perfection, to quote Lexus. It’s continual improvement, continual learning. Toyota’s motto, there is no best. There is no best, only better. There is no best. And that your goal is to do better than you were yesterday. And this continual striving.

Henry Suryawirawan: Right. I think in Toyota, they also have this thing called Kaizen, right? So continuous improvement. So I think pursuing perfection, doing the Kaizen, being better than what you did yesterday is really, really important. So I like all the principles. And I think this can be a good like guidepost or mental model that people should think about whenever they are in a current situation in the organization. First, understanding the value, right, doing the value stream mapping. Because sometimes in large organizations as people move, people come, people go, change of leadership - things change, whether you realize or don’t realize, right? Things change, maybe new directions, but not everybody in the organization actually understands what are those changes. Sometimes even you are just given a goal, okay. Maybe not a goal, you’re just given a task. Hey, please build this product or this feature. And you kind of like assume that that’s the right thing to do, but sometimes it may not be, right? And you don’t understand the total outcome.

[00:46:00] Leading Flow Engineering

Henry Suryawirawan: Speaking of which, that means the leadership role is very important here, right? Because in order to do all these principles, conduct this mapping, right? You need to get the buy in, you need the people to also understand the benefit of doing this flow engineering. So, if you can probably summarize, like what is the role of leaders in the organization? How is crucial so that they can actually utilize this flow engineering for their benefits?

Steve Pereira: I think that from the leadership side, you could get the sense with borrowing the Lean principles and borrowing a lot of mapping techniques. We really tried not to reinvent the wheel. We really tried not to create anything new for the sake of creating anything new. Because there’s so much fantastic knowledge and practice that’s come before us. And it’s all been studied and there’s so much depth that you can go dig into. And leadership is well traveled territory. But, you know, when we think about leadership in the context of flow, the Lean principles and sort of guiding and enabling folks to kind of follow those and build them into daily work is really important.

One of the things that we are really passionate about is designing feedback loops and that goes all the way back to cybernetics, right? I mean, you can’t operate an effective system without feedback. So making sure that those exist to inform individuals that they’re on the right track, that they know that they’re headed in the right direction, that they can effectively coordinate and collaborate with other people. And that everything that they’re doing is in service of the target goal is so critical.

So that’s a really big one, supporting the individual contributors and the teams that are making changes by creating enabling constraints and effective governing constraints. You know, we talk about constraints a lot in the book. And constraints are kind of a natural counterpart to flow. You know, we think about bottlenecks, but something that’s really come to light quite recently in the DevOps space is the idea of enabling constraints. Things that allow us to do the right thing and make it hard to do the wrong thing. And so that’s a major aspect of what we put into the guidance. Because building these systems and building these guardrails are really, I think, what unlock the creative capacity of people and allow them to get into a flow state and stay in flow state. When they don’t have to be managing tons of complexity and cognitive load, because the system takes care of the things that systems are really good at taking care of, right?

So there’s lots of opportunities for automation and capabilities that do things that machines should do so that humans can do what humans do best.

There’s one thing. So, I want to hand off to Andrew for some other items here. But one thing that I think doesn’t get emphasized enough is that a lot of people, if they think about flow, they think about value streams and they think about efficiency, and that this is all just a race to the bottom. And it’s a race to cutting costs. It’s a race to eliminating people and making the most robotic, automated system that we can make. And, you know, what we’re really passionate about and the real opportunity is getting rid of all the things that just have no business being part of our working lives, right, because they’re better handled by systems and automation and even documentation and tooling, right? Like, there’s lots of opportunities to get rid of the things that we really don’t add value with, so that we have more time to be creative and collaborative and human. So that’s one of the things that we’re really, really passionate about.

And, you know, we charge leaders with focusing on that rather than focusing on who’s the bottleneck. Or how do we get rid of this waste that may be tightly associated with individuals, right? We really want the focus to be on systems and enabling people to do their best and really enjoy their work, so that they can contribute at their absolute peak. But I’ll hand off to you, Andrew, because I just rambled for a long time.

Andrew Davis: We started by talking about the challenges of scale, dealing with the challenges of scale. And that is the responsibility of, I mean, a leader is someone who is exerting influence at scale. And it can be difficult even to understand what is your responsibility, what’s your primary responsibility. And so here where really the word, the term flow engineering is speaking to this balance of the fluid, the liquid, the changing, the ever changing nature of things, flow, and the engineering, the systematic analytical mindset. And so leaders very much need that analytical engineering mindset when they’re thinking about what is the goal. How do we systematically improve and so forth. But they need to understand that what they’re operating with. They’re operating in the world of people. They’re operating this world of psychology, sociology. This constant flow of change in the organization, flow of information, flow of people in and out, coming and going.

One thing we noticed that these things–value clarity and flow, they’re ephemeral. I’m super clear at 10 AM in the morning when I’m fully caffeinated and wide awake. And my clarity dims significantly at 3 PM in the afternoon, right? There’s an understanding that you’re dealing with these invisible forces, right? Because you’re operating in flow. A friend of mine likens this. She used to be a paraglider, and she’s operating in space, you know, with all these invisible forces of the winds and so forth. And saying that operating in the modern world is very much like that, where you’ve got all of these invisible forces impinging on you, and you’re trying to control the harness, the frame of the paragliding equipment and so forth. To capture that, to work together with that.

Leaders, I think, we aim to… If the leaders focus first on improving the way of working, then they’re increasing the satisfaction of the people that they’re leading. They’re increasing the creative capacity of the team. And that investing first in improving that ability for the team to operate and flow, the coordination and so forth makes it infinitely easier to accomplish whatever other goals you have as an organization.

Henry Suryawirawan: I like the paragliding analogy. So far in this conversation, we have learned about tug of war and we have also learned about paragliding. I think that’s kind of like perfect analogy to explain what you just explained, right? So I think thanks for that analogy. And speaking about leadership responsibilities, of course, it’s a tough responsibility. But what Steve and Andrew has just mentioned as tips, probably is also a good guideline for us. And in the book, there are a few more that you can also explore. And I’m really excited to see the book being published in the next few weeks.

[00:52:53] 3 Tech Lead Wisdom

Henry Suryawirawan: So we reached the end of our conversation, but before I let you go, I have this one last question that I always ask from my guests. I call this three technical leadership wisdom. You can think of it just like you want to give an advice to the listeners here from maybe your experience or maybe from your research and things like that. I leave it up to you how do you want to structure this three technical leadership wisdom. So if you can share them, what would that be?

Andrew Davis: I can lead off with a few. One is you don’t need to know all the answers. I think there’s often a feeling like if you’re a tech lead or in some position of responsibility, you’re expected to have the answers. You’re not expected to have the answers. If you try to generate the answers, you’re almost certainly going to be wrong. And just basing it on your assumptions, and we operate so heavily on assumptions. What you need to be doing is hosting the conversation, bringing together the conversation to clarify that. So that would be one nugget of wisdom. You don’t have to have all the answers.

The second is you need to take seriously and think deeply about the human aspect of your role. You might be a technician, you might be excellent at your craft. If you’re in any kind of leadership role, this is a human management activity. This is a liberal art. And your technical knowledge is important that you know the lingo and the mechanics of your field. But working with humans, your goal is to draw out of them their own potential for greatness, right? And then your own internal maturity, your own internal personal development of yourself. And then your ability to lead is paramount. It’s basically become your primary responsibility over your technical skills. So I’ll leave it at two to give a chance for Steve too.

Steve Pereira: That’s great. I will do the one and a half. I will yes and everything that Andrew said. I wrote these down, cause I was thinking about this prior to the meeting. I wrote down assume you don’t know, which is kind of the corollary of you don’t have to know everything. I think it’s very helpful for us to kind of walk into it. Especially as technical folks, we tend to dive right into solution space without spending enough time in the problem space and understanding the problem. And then the other one that came to mind that is very, you know, I know close to both of our hearts is none of us is as smart as all of us. This collective understanding is so powerful and it’s so fragmented under ordinary circumstances.

And the one that I’ll add that I’m so fond of is this idea of working backwards. Like just looking for a target outcome that we can focus on and envision and become very passionate about. And then, what’s going to make that happen. And that has implications for planning and strategy and alignment and getting people excited, but it’s also how we create a value stream map. You know, we look at, okay, how do our customers get value and what happens before that and what happens before that and all the way back. And so that’s something that’s really kind of woven through the book and that we really take to heart going through cybernetics and going through the principles of Lean. Like it’s just very entrenched in the content of the book and in the practice of flow engineering. So hopefully that’s valuable.

Henry Suryawirawan: Yeah. So working backwards, I think this is also popularized by Amazon, right? So I think the way they are thinking in the organization is always like working backwards. So thank you so much for sharing all the wisdom. So there are many, not just three, I believe. And I think we’ll summarize that in the show notes.

So for people who would love to connect with you or continue this conversation, want to ask questions, is there a place where they can reach both you online?

Steve Pereira: Yeah, we both spend a lot of time on LinkedIn. We are constantly talking about flow and flow-engineering and value streams and collaboration and DevOps. So that’d be the easiest place to find me and follow along with what I’m doing. And we’re ramping up talking about the book. Folks will be able to follow along. If they pre-order the book, they’ll get connected with everything that’s happening there.

Andrew Davis: flowengineering.org is now live, so go check out flowengineering.org for more information and sign up for the email list.

Henry Suryawirawan: Right. So I’ll put them all in the show notes. So thank you so much for your time today. I hope the listeners here can invest more time in, you know, creating flow in the organization, be it for your individual sake and also collective flow. So thanks again for coming the show.

Steve Pereira: Thanks so much.

Andrew Davis: Thanks so much, Henry. It’s been super fun. Delighted to have the conversation.

– End –