Flow Engineering

Introduction and Background

Steve Pereira: Hi, everyone. I'm Steve Pereira. I am joined by my co-author on Flow Engineering, Andrew Davis. Let me say a little bit about myself, and then I'll hand it to you, Andrew, to introduce yourself. I've been in tech for what seems like my whole life, aside from a brief stint making pizzas. And what has kind of driven my direction is this idea of end to end workflow.

I suppose if I were to draw a thread, I've always been very passionate about things like software building release, automation collaboration, and definitely a fascination with value stream mapping. And that brought me to Andrew and Andrew to me. And that's where that's where we met. And that was kind of the foundation of Flow Engineering.

Andrew, introduce yourself. Tell us a little bit about yourself and where you come from.

Andrew Davis: Sure. I'm going to quickly flash the book as a visual here. So flow. Excellent. You and I are coauthors of the book. It came out almost a year ago, May of 2024. But Steve and I have been working on it for four years or something like that. I, Andrew Davis, head of product for AutoRabit.

A software company focused on building tools for Salesforce developers. I've spent, I've been a technologist like Steve for my whole career, which is now 30-ish years, with my own interesting forays in different directions. Not pizza, but the last 12 years, I stumbled into DevOps for Salesforce, and I also wrote a book on sort of the first main book on how to apply DevOps concepts to Salesforce development, which is building custom applications and customizations on the Salesforce platform. AutoRabit builds tools to help developers on that platform.

But Flow Engineering was Steve and I, our efforts to try to make value stream mapping as a practice more accessible to technology audiences. He and I both encountered the work of Karen Martin and the lean community, who had drawn value stream mapping as a practice out of the innovations that distinguished Toyota and that created the lean movement. The practice, you know, the tooling didn't read version of value stream mapping is the practice of visualizing collaborative workflows, workflows that stretch across many individuals, often many departments from idea, or customer request through to delivering that idea to customers.

The reason that becomes so important is there's so many cracks and gaps in the process where people get disoriented, disengaged and distracted from what we're really meant to be doing as an organization, as a team, and to the detriment of customers. Value stream mapping, Flow Engineering is an effort to help make that very visible, very clear, very compelling, especially for technical audiences, which is where we came from, the software development community.

The Complexity of Modern Software Development

Andrew Davis: How would you summarize the book and the essence of it?

Steve Pereira: I think that one of the things that we've both encountered and we've had a lot of exposure to is just the complexity of modern software development. You know, these organizations are now enormous and spanning the globe, and you have suppliers and you have contractors and you have full time employees of companies trying to collaborate together.

The path from idea to the delivery of value is this incredibly complicated span of activities. And so I think that we've reached a point where it's really important to grapple with that and give people some clarity on how you make sense of it, even a little. So I think value stream mapping is very, very powerful for that purpose.

But where we started with the book was really around this idea of how do you start to wrangle with this complexity? And we kind of fixated on value, clarity and flow, and the problems with scale and how complicated this landscape and environment is, and how do you kind of filter out the signal from the noise?

I think you touched on it earlier, Andrew, with disorientation, distraction and disengagement. But what are we really advising with this book? Right. We're kind of trying to guide people through a sequence of maps, this not just value stream mapping. Right. And the idea that to value stream maps effectively, you need to address a couple of things that I think we were seeing in the landscape.

If we talk to folks who tried value stream mapping, the first thing people will say is that it's difficult to learn how to do this. It's difficult to know what to map. Where do you even start mapping, and what is the right scale and what is the right level of detail? Who should be involved?

What should that effort look like? What kind of time period are we looking at? And so I think we really started to think about how we hold someone's hand from start to finish with this, with something that is not so scary, that value stream mapping remains this very niche, esoteric, complicated practice. So I think that if I'm thinking about the purpose of the book and how the book is structured, it's kind of where we are starting from?

How do you do this type of mapping practice, and then where do you go from there? What does that allow you to do? And what would you leverage the maps into in terms of improving, ultimately improving flow across your organization and at a much broader scale?

Andrew Davis: I'm going to rattle off a few concepts of major sound, you know, trite or unnecessary background concepts, but just want to make sure that we're grounding everybody in these foundations. It's very easy to focus on software, you know, in any job, I suppose, but certainly software development is just getting a job. And how do you get a job and how do you get your work done, and how do you master the technical complexities of what you're doing? And the software development world's continuously evolving, you know, enormous complexity and you can consume 100% of your mental space just trying to figure out how to solve the problems that are immediately in front of you.

But that's at the level of an individual contributor, whether you're an architect or tester or whatever, whatever you are in the software development world. Now, higher up in the organization, say you've got a higher vantage point where you're thinking about timelines and customer deliverables and efforts and costs and so forth.

There can be a dramatic disconnect between the perspective of those two parties. And that is an example of the cracks that appear in organizations between different layers of perspective, different layers of understanding. It's critically important for the people on the ground, so to speak, who are working in the trenches of bits and bytes and so forth to get that higher level perspective of what are you doing?

Why does your company exist? Why does somebody pay you? Like, who are you serving? And also critically important for people with a higher level perspective on those topics to understand some of the details of what's happening in real life on the ground, the different stages, different people and processes and so forth. And it's shockingly hard to get that complete picture.

One of the purposes of value stream mapping is to create a unified mental model for everybody involved. Whether you're sort of a high level observer influencer, whether you're a low level direct contributor. And I apologize for using these terms like high and low. It's not meant to imply disrespect or that one job is more important than the other.

It literally is. Are you standing high and seeing a larger scope vantage point or are you sort of low on the ground dealing with the felt reality? So the idea of value stream mapping is to create a very, very, very simple visual model of what the heck are we doing? Like, what does it take? And like the classic process that Steve and I both came from is the software development process.

There's a new feature. You want to build from that idea that you think is going to deliver customer value through to actually getting it out the door, deploying it. What are the different stages that need to happen? It's shocking really, how little understanding most people in the team have of the bigger picture outside of their domain.

Like if you're a tester, you may not really understand what goes into the initial design and or the deployment. If you're on the CRO side of things, you may not really understand much about the software development process. You don't have to understand much, but everybody needs some shared mental model. And one of the big conclusions I came to from the book is that in some ways, you know, these are first world problems.

I'm not trying to whine about the lives of software development, but in some ways it's harder when you're dealing with bits and bytes and the invisible world of software development than if you were on a manufacturing floor. Now, Toyota revolutionized the world of manufacturing by applying, you know, developing these ideas of visualizing value stream maps and applying lean concepts and so forth.

But they were operating primarily in a physical domain of physical manufacturing. Now, one of the things in a physical domain, you walk into the factory floor and anyone can see if there's a spill on the floor or if there's a huge pile of inventory that's piled up, or if a certain machine has a red flag over it that it's broken.

Or if there's lots of people clustered in one area and nobody clustered in another area. All of these things are visual, and everybody who walks into that space can kind of see and agree on what's going on. Now, one of the characteristics of the software development world and other knowledge work fields is that the work is fundamentally invisible, it's invisible, and it's very fast moving.

I can generate gigabytes of stuff and send it off someplace and very quickly and easily. And so Steve and I, as an example, if even for coworkers working at adjacent desks, right next to each other on our laptops, we can be seeing a completely different set of information. The stuff that I'm looking at, that I think is important, and the stuff that Steve's looking at and he thinks are important, are completely different.

Our laptops are touching. So we're not actually living in the same world. Now if you're in a manufacturing facility, he and I are laboring next to each other. We're kind of sort of living in the same world. But in the software world knowledge work, you can be in completely different universes. And so I honestly believe that's a very big deal.

It's a very big problem that people can go off and just be completely disoriented from each other and not really have a coherent, shared view, mental model of what are we doing? Why are we doing it? Where are the problems? Why are these problems, what do we need to do about it, and so forth. And so Flow Engineering really is about creating the context to have visual, collaborative conversations about what are we doing these topics, what are we doing, why are we doing it?

Where are the problems, why are those problems arise, and what are we going to do about those problems?

Recommended talk: Insights on How Team Topologies Drive Organizational Success • Manuel Pais • GOTO 2024

Visualizing Invisible Work

Steve Pereira: I think that's that's so well said Andrew. I think that it's really fast in the physical world where you can actually just follow the raw materials all the way from coming out of a truck to becoming another truck and be there for every single stage. In that process, you can have a stopwatch running, and yet we still do value stream mapping in that environment, even though we can be there for the entire workflow and see it in person, and we can get anyone we want to see it with us from our perspective.

And yet value stream mapping in technology and knowledge work in this invisible field is something that most folks don't even attempt. And I think it's partially because that idea is overwhelming. How do I trace something that's invisible? How do I even begin to do this? But also because we don't know what we're missing? Like we have requirements, we have tasks, we have an upstream and a downstream.

We have someone who gives us stuff. We have someone to give it to when we're done with it. And that seems good enough, right? Until we run into these scenarios where what we're doing isn't good enough, what we're doing individually isn't good enough. If that's the case, which is a terrible situation to be in, especially when you're part of a system of work, you know, feeling like you're individually responsible for something that has many stakeholders and many contributors and a big scope.

And that's kind of a prevalent issue. You know, we're always talking about developer productivity and trying to find metrics.

Andrew Davis: Steve, if I can interrupt you and dive in, just to give you a little bit more context, Steve and I are also sort of following very different career forks, like Steve's focused on consulting around helping companies to improve their processes and so forth, whereas I'm actually working as a head of product for a company. And there was one phrase you mentioned that that kind of triggered me a little bit.

You said if problems arise or when problems arise, I'm like, no, no, no, you don't understand, Steve. Right? It's nothing but problems.

Steve Pereira: It's the fires.

Andrew Davis: Burning all around us. Right? And that's one of the issues. It's not like you've got the smooth running system and then, you know, oh, occasionally there's a problem that arises, oh, this value stream mapping. No, no, no, you don't understand at all. It's just like it's a massive stack of dumpster fires. This thing is just on fire all the time.

That's what's consuming our time and energy. Like, we're spending all of our time putting out fires to a great degree. And not stepping back and looking at, you know, where are these fires starting from? Like, how did the fire spread? Sorry to interrupt.

Steve Pereira: No, that's I think that's great. That's great context. I think that another major motivation behind this book was this idea that nobody has any time to do this. I mean, we're not doing it partially because there's, you know, maybe not a playbook that's designed for this group of individuals who are struggling with this reality, but also who have time.

Everyone is telling us, fight fires, but also get the work done and do dozens of other things. So I think we were very, very sensitive to this idea that this has to be minimal. It has to be approachable, it has to be simple. We have to assume that nobody wants to do it. You know, even if it sounds like a good idea.

One of the things I always remember is we were having these conversations with folks while we're writing the book about how do you do value stream mapping? Has it been valuable? What's been challenging? What have you learned? What kind of results have you found? And without fail, everyone said, oh, we did it.

It was valuable. It was time consuming. It was kind of exhausting to do, but there was a clear benefit to it. And yet we don't do it. And it was difficult once we had the map to actually act on it. Right. So I think that's all. So pieces that we tried to weave into this program, you know, kind of an end to end package of activities that we call Flow Engineering.

But we really are in this landscape where nobody can afford to step away from the firefighting and the feature building and the meetings and the emails and the Slack notifications and the chaos. So that's something that we were really designing for, right? How do you create leverage in a system where the trains have to run on time and everyone is late and all the trains are late, and nothing seems to be working.

How do you fit a practice into that? 

Recommended talk: Better Value Sooner Safer Happier • Simon Rohrer & Eduardo da Silva • GOTO 2025

The Five Maps Framework

Steve Pereira: Maybe we talk about why we're not just doing value stream mapping like Andrew. Like from your perspective, why can't we just dive into value stream mapping and take even less time than Flow Engineering? Why can't we just do only mapping the value stream and get excellent results?

Andrew Davis: To get a little context for the answer. Back to my original point about the difference between knowledge work versus working in the real world, right, where you've got these fires and I'm sure every manufacturing facility, they also feel the same way. Right. Like there's all these problems. We don't have time for this and so forth.

But you think about what the last 30 years has done to the world's attention span, right? The advent of the internet and social media and so forth, like the fast moving digital information, has increased so this is not to get too metaphysical. It's increased the frequency, the vibrations going on in our brain. Like we're optimized for very fast paced stuff right now.

There's not a whole lot of that slow thinking and observing stuff. And so what we're doing is whenever you step back and look at the big picture, you need to see the pattern, things that are unfolding over time. The very nature of digital information, it's very fast moving in the lean community, I love it. They talked about the difference between when you're working with atoms versus when you're working with just electrons.

We work with just electronics manufacturing, where they work with atoms. Atoms are very competitive electrons. Especially when you get infinite amounts of them, you know, tons of them. So the potential for distraction is so much higher and the ability for people's minds to fragment and fracture and not take the time to step back.

So we knew we needed to make this very concise. The book, one of the things we did is we made the book astonishingly pretty and visual, like it's all basically it's like the missing user manual for post-it notes. It's not assuming that you've got any special tools or techniques other than, hey, grab a bunch of post-it notes like, let's just put this up here, but there's a bit of a, as we describe it, a life support system for value stream mapping.

At the very core is let's just step back and look at the sequence from idea to delivering the idea. And what are the steps and departments and individuals involved and what are the timings that are required and so forth, and how much waiting is there and how much backlog is there. And just getting a quick picture and our target is you should be able to have that core conversation in less than maybe two hours, you know, and two hours is my calendar's full 30 minute meeting.

The two hours is actually a little expensive for now, folks, but two hours get everybody together in one place to have this meeting where you look at the whole picture, that's the value stream mapping part. But it needs a life support system around because as Steve said, people again and again, they would do the value stream map but not take the follow up steps.

Or sometimes they do the value stream map. But the people who were there were not quite sure why they were doing it right. So we created this, part one of the book talks about a lot of the stuff that Steve and I just talked about, the broader context, the challenge of knowledge work, the challenge of, you know, when you're at scale, when you have, you know, everybody has little different bits of the context.

Part two of the book looks at, what we call the core of Flow Engineering, which is creating these five fairly simple mapping exercises. And there's five mapping exercises. The second map and arguably, you know, the third map also, they're the value stream mapping part. But the first map is called outcome mapping. It's a preliminary that's designed to help give everybody a shared context on what do we actually want to do, what's the outcome like why are we doing this.

The outcome, you know, because we're talking about okay, we've got software delivery and it's problematic and so forth. What is the outcome we're seeking? Well, the outcome we're seeking is can we, for example, increase the throughput of the engineering teams or can we reduce the cost of our infrastructure, or can we, you know, whatever, whatever's the whatever's your company's strategic goal or your team's strategic goal.

Let's talk about that. Let's look at that and let's see why. To achieve that goal, we need to look at our whole workflow, our whole work process and the value stream mapping. And always in the context of some why and the purpose of outcome mapping. This first mapping process to discern the why that's behind like why would why what are we trying to accomplish?

What's the benefit that we want to achieve? Second and third maps are about the value stream mapping. Fourth and fifth maps are about okay, now you've done the value stream mapping. Where do you want to go with this? Like what could it look like? What are our next steps?

Steve Pereira: I think that's one of the things to bring up here is that the idea of working backwards, which I think we both find extremely powerful, like the idea that for you to make really good decisions about how and where to take your next step, you should have a very clear understanding of where you're going.

Oftentimes, there doesn't seem to be a lot of value in taking that step away from today unless you have this broader view into to into the future or, you know, a sense of where you want to go, because then it becomes very clear that which you're doing today is going to get you where you want to go tomorrow.

I think that that's something that we've tried to do well, we didn't even have to try to weave it into the book. It just becomes part of the practice. If you set a target, if you set a vision, if you have some clarity on where you want to go, then all of a sudden the question becomes, okay, what happens before that?

What happens before that? And what happens before that? And that brings you from the flow roadmap as to where we are going? In detail. And how or how do we plan to get there all the way back to that setting of the vision? And so stepping backward through that process gets us the five maps and the program of Flow Engineering.

Starting with that, let's pick a direction. Let's pick a very clear point on the horizon that we can all agree on is is valuable and and how valuable it is from our perspectives, from the perspectives of the business and customers and everybody who has to understand or has to benefit from it, let's say, and let's understand our obstacles, that are preventing us from doing that today and how we might go about, pursuing that vision or that direction.

This doesn't have to just involve the maps of Flow Engineering. One of the things that's part of the outcome map is next steps, which can be all kinds of different things. If you have common practices around customer journey mapping or you do Wardley mapping or you do user needs mapping, all of those can be parallel efforts that are complementary in kind of support Flow Engineering.

Even the practices of Flow Engineering are kind of a suggestion that works very well. But you could take it in different directions. You can customize it as much as you see fit. We've seen a lot of that actually, like one of the most recent relationships I've been building is with Toyota. And they've kind of taken Flow Engineering and, and tailored it quite a bit to fit the way that they do many of these practices today and kind of woven in, you know, bits and pieces of their current practice, which means that it's easier to adapt.

You're not saying you must do it this way. It has to look this way. You have to do it, descriptively. And I think that's another way that we're trying to kind of meet people where they are and make just, I guess, burn down those objections. Right? All those things that stop us from pursuing something or investing in something or or actually doing things and getting things done is, you know, we want to get rid of all those hurdles, all those obstacles, wherever possible.

So, it's one of the things that I think I'm, I'm very pleased with is the how, how open this is. I hope folks perceive it that way. But, I've heard a lot from folks who've read the book and then incorporated this practice as complementary to what they've already been doing. Or, you know, they've pivoted from something that they were doing to a method inside of Flow Engineering because it was a leaner or more flexible or easier, simpler approach.

I hope that, that's one of those other ways that's making this more approachable and removing those barriers to entry for folks that we often find, you know, when we're reading a book or we're looking to adopt a new practice, you know, the immediate challenge is, how do I fit this into my life today?

How do I not go out of my way to try to build a habit or a practice that is a dramatic departure from where I am at this moment?

Andrew Davis: I'm still a little bit stuck. I hadn't. I don't think I had heard from you that you were working with Toyota and the poetic symmetry of that. It's just it's just gorgeous, which is just, I mean, it's just there is this recirculation of ideas through the ecosystem. And I know Toyota's massive organization. Right. And everybody thinks of car producing, but there's tons of software development teams.

And I remember seeing a presentation at IT Revolution, at the DevOps Enterprise Summit, a number of years ago from a software leader at Toyota. He was like, you know, I know you all think at Toyota, we've got, you know, all of our stuff together. And we think in terms of, you know, being and value stream mapping for everything.

Let me tell you, the reality in my team was data science or whatever it was. There's a gap, and the gap is not because anybody involved is incompetent or this or that, but like, literally, if you think about protons, atoms versus electrons, the dynamics are very different, right? The dynamics on the manufacturing floor of what it takes to get raw materials out through, you know, and I love what you said off the truck and into creating another truck.

Are dramatically different from the dynamics of a data science team. And so there's a bit of a limit to where the knowledge transfer is not automatic. Right. And so what we have is the recirculation of valuable ideas across different communities. We're living in very different domains. And Steve and I are you could call DevOps natives, right?

We both spent a fair amount of time like living in this space of, you know, easing and automating the software development lifecycle. We speak DevOps, so to speak. Right. We're taking these concepts of value stream mapping, weaving it into Flow Engineering. We also speak to impatient busy technical people. Right. And so the book hopefully reflects some of that.

This book is applicable to anybody, but our core folks are those working in the software development trenches who end every day like we're covered in bits and bytes right there. All right. Take a shower to get all the bits off.

Steve Pereira: Exactly. Coming home from the digital factories. Right.

Andrew Davis: Yes.

Recommended talk: Tap into Fast Flow w/ Team Topologies & Platform Engineering • Manuel Pais & Julian Wood • GOTO 2025

The Future with AI and Flow Engineering

Steve Pereira: I do think that that has a lot to do with, How we've written the book and the practices, it kind of reflects. I think we're digital DevOps natives in the sense that we were there from the very early stages of we and we've seen it, but I think we've, we've kind of moved into and adopted DevOps and embraced DevOps.

We're kind of developing in it, in different respects by nature of the fact that it really got to pain points that we were very viscerally aware of. I mean, we've both lived through the pain of having the disconnect between these different roles and perspectives and incentives. All of the things that get wrapped up in that separation between dev and ops.

I think one of the things that's been very rewarding is realizing that that separation isn't just a software challenge. It's not just building and delivering software. You know, we see that challenge anywhere you have, a transfer of work from one role to another role because you just naturally have, by virtue of specialization, these separate perspectives.

You have separate incentives here. Your definition of good is different. Your definition of done is different. Your definition of what you need to do your best work is different. We all have an upstream and downstream. And I think that that's one of those areas that gets more and more attention. I think all of these things that we're talking about maybe in ten years, like we're starting to to feel about DevOps, is just taking it for granted.

That's just how the world works now. We now have unified flow across, development and operations. But I think that's all built on this foundation. First we have to close those gaps. First, we have to have a shared language, proximity. We have to know, one of the earliest DevOps things was to eat lunch together, right? I mean, this was like a revolutionary concept.

About ten years ago, actually, it's 15 years ago now. But like one of the earliest DevOps talks that I ever saw, the whole point of the talk was just go have lunch with that other person. If you're dev, have lunch with an ops person, vice versa. I think that these practices, like collaborative mapping, are now taking that to a broader scope, a much deeper level.

We're not just having a conversation. We're having these visual conversations. One of my favorite illustrations in the book, still, that I will share with people all the time, is this illustration of a flow of activity with a highlight. And on one side is a business person, on the other side is a technology person. And they're both saying, I see what you you are communicating with me about and I can understand what you're illustrating to me, because we can both point to this part on the map and say, this is the area that we're both concerned with, or this is the area that we both need to address at this moment.

I think that having a shared artifact is something that's extremely powerful. And in my experience, it really changes conversation for.

Andrew Davis: A shared artifact, visual. I mean, one of the things we make a point about is that a third of the brain is exclusively dedicated to visual processing and more than 50% is heavily influenced or related to visual processing. And that and that especially this, the knowledge, the world of knowledge work. As Steve says, this is generalizable to knowledge work.

The world of knowledge work is fundamentally invisible. And so when you visualize it, you're stepping it down to a layer that that everybody can see, and then everybody can and deal with, with very robust parts of our brain that are designed to say, oh, you know, when you see a pattern that's problematic, everybody can see, like if you visualize the situation in a certain way, everybody can see and agree on, okay, if this does seem like a problem and you create a common language, the, the, you know, Steve and I also came at this from very, very different intellectual backgrounds and areas of interest.

I think it was very super fun. Intellectual collaboration with Steve continues to be, one of the things that I read one time is that when you eat together with a with another person, both parties secrete oxytocin, which is this bonding hormone that, that mothers will secrete and babies will secrete, you know, when they're when they're initially bonding.

But that literally we secrete bonding hormones so that at a hormonal level, deeply biologically you're when you eat lunch with somebody else, you know, you're creating a trust layer and the trust layer at that very visceral layer, opens the flow of communication, opens a flow of trust. And we talk about generative cultures and DevOps. And generative cultures are characterized by high information flow, high information flows characterized by low boundaries, right.

Not so much defensiveness and separation between the different groups. And so what we're trying to do is by having these collaborative conversations or having lunch with somebody, whatever, you're basically reducing the boundaries between people, between their minds. And so another aspect of the book is we and Steve said, you know, we center around this idea of value, clarity and flow, all three of which are effectively psychological experiences.

What do the individuals value? You can't separate that. It's not that it doesn't exist in an objective way. Clarity is very clear, you know, what is what everybody understands. The psychological experience and the flow. You know, you could describe it as an external thing. But flow is also felt, the experience, sense of progress does.

The company does the team, does the individual have a felt experiential sense of steady, smooth progress? And I know we need to wrap up the conversation. I want to throw you a real quick curveball, unscripted. Steve. The world of software developments is rapidly changing with AI powered coding tools and so forth. Do you have any predictions or observations about how that changes the dynamics?

This stuff still stays relevant.

Steve Pereira: Yeah. Well, that's a great curveball, I love that. I don't think that I've, you know, formed a complete opinion on it. But there's a couple things that are really interesting, you know, a couple of things on the horizon. There's opportunities to have things like virtual facilitators. You can have an expert Flow Engineering copilot that is part of your collaborative mapping exercises and kind of guiding you through the mapping practices, asking kind of probing questions as you go along, making sure that every participant is heard and kind of part of the process.

So that's very interesting. The other idea is that, you could see Flow Engineering kind of built into tooling in the future where, you know, rather than creating all the maps yourself. One of the starting points for Flow Engineering is just collecting a bunch of information about what's happening right now. And where do we want to go with our performance improvement and all that exists, you know, not only in people's heads, which is the critical, I think, resource that we're tapping with, with Flow Engineering, but it also exists in tools, right?

I mean, we have OKRs, we have strategies, we have roadmaps. We have all of these assets that we pull in through outcome mapping. And we referenced throughout the practices. But they could all be actually feeding a continuous aspect of Flow Engineering. Right. So tooling that supports these types of activities I think I would love to see these things emerge.

I'd love to see some of these aspects of working backwards more directly tied into how we work, because I think it's an extremely powerful way to work, but it's not necessarily instrumented in a lot of tooling that we see today. So there's opportunities for facilitation. There's opportunities to kind of make Flow Engineering more of an operational, continuous aspect of work rather than just mapping sessions.

I don't think we're ever going to get away from the value. You know, you can't outsource the oxytocin, from having a meal with someone else. You can't outsource the outcome of that activity or the benefits of that activity. So I don't think we'll ever really outsource or, completely replace the, the benefits of that collaborative mapping.

But I do think that we can go sort of above and beyond that and then also deeper, as a result of having improvements to software, integration of AI and, and supports that are possible now, that weren't possible when we started writing the book. And I'm actually really proud that we, you know, it feels like one of the last books that was kind of written by people.

Looking back, it was an extremely valuable exercise. I think me mentally, the, you know, the idea of writing a book is, is just you just really do have to sort through so much information and, and pull it together into something. And, and I think that, that's been tremendously valuable to me. And I hope that for readers, it's, you know, it's something that they can follow and create those connections themselves and come away with different models of how to think about flow and clarity and value and, and their own environments and how to have more effective conversations in collaboration with other groups.

Steve Pereira: But I'll leave you the last word, Andrew. Where are we? Where are we headed? What, what's on your horizon? And what are you thinking about as we move into uncharted territory?

Andrew Davis: The one thing that I would say is that, and I feel like a benefit from my vantage point working in Salesforce as a local platform. We know what Low-code does. It dramatically lowers the barrier of entry of who can build applications. You can build applications on Salesforce much more easily than in JavaScript or whatever else, and it also increases the throughput.

People create a lot more stuff. A lot more people create a lot more stuff a lot more quickly. I, I'm very, very clear that AI does exactly the same thing, further lowers the barrier of entry. Who can build stuff and increase the throughput? And what happens when you lower the barrier of entry is you. People don't necessarily have all of the controls and guidance and rigor that that a traditional software engineer would have.

As you increase the throughput, the mass increases much, much more quickly. So we're very, very much seeing the acceleration just like this acceleration, you know, from the world from manufacturing to software development, there's a dramatic acceleration, which means the mass accelerates. So I know people are probably putting in ChatGPT, you know, summarizing Flow Engineering as a book and so forth.

There's still a place for old fashioned concentration and old fashioned conversations. And if you don't have those conversations around what is your process, why are we doing this? Where's the problem? How do we solve it? The mass will just increase very, very quickly. So, I hope everybody has a wonderful time enjoying, reading or looking at Flow Engineering.

Steve and I are always happy to connect.