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. Clarity, meaning a sense of orientation, awareness of how you fit into the bigger picture 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 smoothness of action.
Hey everyone. My name is Henry Surya Virawan and you're listening to the Technically Journal Podcast, the show where I'll be bringing you the greatest technical leaders, practitioners and thought leaders in the industry to discuss about their journey, ideas and practices that we all can learn and apply to build a highly performing technical team and to make an impact in your personal work. So let's dive into our journal. Hello, Steve.
Hello, Andrew. Welcome to the Technical 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 to improve your value stream and things like that. So really excited. Welcome to the show. Thank you so much, Henry. Yeah. Thanks for having me here.
All right. So Andrew and Steve, so I always love to ask my guest 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 be great. I've been in tech for a couple of decades now. I started in kind of IT and tech support and work 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 that's what I'd refer to IT as nowadays. But another big inflection point was taking on a role as CTO and 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 and brought a lot of that into consulting.
So that's kind of my path. 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 for any book recommendations on value stream mapping for tech organizations in particular. And he 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 it 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 licensees here, free license 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 there were a lot of struggles for 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, you know, make an edit, and I'm like, what is this? Did I write this? Did somebody else write this? Has this changed that I just forget? There's 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 transition from the tactical bits, 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 doctor Christina Mazlak, 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. And I just realized this world was much bigger than I had appreciated.
And so it really, 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 and highly regulated industries, Auto Rabbit. 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 the 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 balustre mapping is probably a bit rare. Hey, thank you for being part of
the technogenal community. This show wouldn't be the same without your ears, and you are the reason this show exists. If you're loving TLJ and want to see it keep on growing. Consider becoming a patron at techlegional dot Dev Patron or buying me a coffee at Techlegional dot Dev Coffee. Every little bit helps field the research, editing, and sleepless nights that go into making this show the best it can be. Thanks for being the best listeners any podcast could ask
for. And now let's get back to our episode. 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 the book, you actually basically first came up with the background that a lot of problems in the organization
comes from scale. 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? Well, one thing that I want to mention, I'll throw to Andrew for some of this.
But one of the things I 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 Seminole book on Valley 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 here doesn't have time for Valley Stream mapping, can't get the buy in for it, can't make the space in there doing to step away from the work and do the mapping and 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 of 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, you are kind of long term forecast. You know you have 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. And so this distance creates these conditions. But I'll throw to Andrew to run over the specific costs that we highlighted because I don't want to run the mic the entire time. 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 smoothness, of action. And when we're 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 Mihai Chick sent Mihai'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, 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, it resonates deeply with us.
We feel like we're doing something useful. So that's individual flow, the 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 background 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 enable 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, most likely I'm 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 in 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 got the Gallup organization saying, you know, 75% of people in organizations are disengaged or actively disengaged.
And then also if there's just a 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 I think even for me, you know in the IT world the pace of notifications and documents, sprawl and so forth in 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 Co workers, 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. 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 cause or problems that you just mentioned, right this orientation, this engagement and also distractions. I think in tech world these days, destruction 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.
And I think in many organizations the first approach when they want to increase their business value or 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? Yeah, I think coordination is really a fascinating thing. And and I think actually building on top of coordination, collaboration is something that's very interesting as well. The coordination, the 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 and 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 to bring everybody together.
We got to bring in marketing and 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 by a kind of radiating information that people can just 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 talked 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, rebuild, rapport and familiarity, it all is much more difficult. So you kind of turn the dial of more people and you're incurring more cost, but there's more risk of miscommunication and all of
these negative consequences. There was a research report that we highlighted in one of the early chapter on the cost of scale from 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, 30-2 people do the work of like nine people or 12 people, something like that. And there was a phrase we we settled on the book. But then nevertheless there are net benefits to working together as a group. But there's this huge hidden costs. And so the reason like I love to Steve's comment, you know that you solve these problems by
hiring new people. I'm 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% 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 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. 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 big organization rather than a small
organization. Or maybe people don't put up more in terms of effort. So maybe tell us a little bit more about this paradox. I'll briefly hit that. It's the same research report, and it does highlight what's known as the Ringleman 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 have 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 then you can literally measure the force that they're exerting on the rope. Yeah. So I mean that's great. I love that analogy of the of the tug of war and I think we can see this manifested and and it might be a little bit counterintuitive, right? Because it's not as if people just inherently take advantage of the 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. 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.
Right. So the three elements of this collective action in your book, which also brought up by Andrew in the beginning of value, clarity and flow, right. So you hypothesize like with this tree in place, right. So as the organization's skills, probably we will see much benefit rather than having more cost or the tax of having so many people, which probably brings us into this flow engineering. What is actually flow engineering right in the 1st 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. 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 upfront 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 learn by mapping the value streams and looking at value streams and looking at constraints in 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, OK, 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 the road map 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. 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. So I think this can work at the 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 1 by 1, right. What are those tools that we can use in flow engineering? The book introduces 5 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'd 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.
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 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 getting that clarity on the outcome is the first step. And that often is missed if people just dive right into
value stream mapping. Value stream mapping we introduce is 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 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, 2 to 3 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 OK With the understanding we've gained. How can we improve that? And then you identify a sequence of improvement activities in the final map. Is flow. Rd. mapping is 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 the scattershot approach to,
yeah, making it better? 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's 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 road map also tells them that OK, 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 a such a flow kind of a state,
right. So I think really important thing 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 do you think gives the biggest impact if organization wants to do it in the first place? Well, this is a 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 talk to and every map that I've ever built with a group you find the 20% 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. Like 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 olives, it's fantastic. We hear great things about it and then they struggle because they haven't done the 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 by 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 retro, right? Try something different for your retro, try something different
for your lunch and learn. Try something different for your off site, just to make it very easy to say yes and try it out. 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 like, we 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 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, Oh yes.
And then you share your understanding and see how that map and 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 a lining of these mental models, and the raw benefit that you get from this implies that 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. 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 organizations, 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 models so to speak, right. So people are more aware of what is going on in the company and what kind of target they want to
achieve. So not only the maps, you know, the tools that you give people to try out an experiment, but you also kind of like give 5 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 problem. So tell us a little bit more about these principles. 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, OK, 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 extract away what we really care about, right, because we might just want to
get to a restaurant. But there's diminishing returns in in perfect detail. And this is one of the things that I think people really struggle with, with Valley Stream mapping is they're really unclear about what the right level of detail and accuracy is. And they kind of trip 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, OK, 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 5 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 I just wanted to mention that and I'll, I'll toss back to you, Andrew, 'cause I thought that was interesting and I don't disagree. I think that all maps are wrong. Yeah, yeah, agree. And I mean a map is just a model, for example. So it's totally apropos. 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 the idea that everything is 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 the 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 Spear 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 the 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 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 I spent some time organizing, and eventually I couldn't come up with a better system than these.
What do we call the five principles of Lean? And these are borrowed from Jim Womack and Dan Jones. Lean Thinking these books 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 and that's all never possible perfectly but it's basically it's 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 GuideStar 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, 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.
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 customers 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 driving. 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. OK, 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. 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 it crucial so that they can actually utilize this flow
engineering for their benefits? 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 travelled 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 a 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 I want to hand off to to Andrew for some other idioms here. But one thing that I think doesn't get emphasized enough is that a lot of people, 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 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. 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 we're 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, 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 10:00 AM in the morning when I'm fully caffeinated and wide awake. And yeah, my clarity dims significantly at 3:00 PM in the
afternoon. Right. So there's an understanding that you're dealing with these invisible forces, right? This, 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. 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 is a good guidelines for us. And in the books, 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. 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 guest. I call this 3 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 3 technical leadership wisdom? So if you can share them, what would that be? 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 leader in some position 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 conversation
to clarify that. So that would be 1 nugget of wisdom. You don't have to have all the answers. The 2nd 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 2:00 to give a chance for Steve to. That's great. I I will do the 1 1/2. I will, yes.
And everything that Andrew said. I wrote these down because I was thinking about this prior to the meeting. I wrote down assume you don't know which is kind of the corollary of but 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 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, 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.
You know, we look at OK, 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 and in the practice of flow engineering.
So hopefully that's valuable. 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 or ask questions, is there a place where they can reach both of you online? Yeah, we 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. Flowengineering.org is now live, so go check out Flow engineering.org For more information and sign up for the e-mail list. 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's sake and also collective flow. So thanks again for coming to the show. Thanks so much Henry. It's been super fun. Delighted to have the conversation. The.