April Book Club - Flow Engineering by Steve Pereira and Andrew Davis

Transcript

Mandi Walls: Welcome to Page It to The Limit, a podcast where we explore what it takes to run software in production successfully. We cover leading practices used in the software industry to improve the system reliability and the lives of the people supporting those systems. I’m your host, Mandi Walls. Find me at LNXCHK on Twitter.

Mandi Walls: Alright, welcome back everybody. Welcome to our April episode of our book club. This month we’re going talk about an upcoming book, Flow Engineering from Value Stream Mapping to Effective Action by Steve Pereira and Andrew Davis. And this time I actually have the authors with me. So this book is going to be released on May 14th by IT Revolution Press. So you’ll find links for that in the show notes and you can pick up this book in your favorite format. So here you are. We have the authors with us. Steve, start us off, introduce yourself, what you do, how you came to caring about flow engineering.

Steve Pereira: Thanks Mandi for having us. This is wonderful to get a chance to talk about the book and these ideas. I have been in tech for over two decades now. I started actually in tech support and I worked my way through systems engineering, build and release engineering. A lot of the different roles that hopefully listeners are familiar with, whether they’re in them or that have been in them. And I sort of left the contribution world after being a CTO and learning a lot of things the hard way and then moving into consulting to kind share what I learned with different companies also because I like testing ideas in different contexts. So it was a great opportunity for me to say, okay, let’s see if this works over here and then over here, and I’ve been doing that ever since. So for the past seven years of been consulting, the light bulb moment that drove me in that direction was discovering value stream mapping.

Steve Pereira: I didn’t even know it was called that when I stumbled into it. It was just a way of dealing with friction and waste and delay and how long it took to get everything done and being constantly overwhelmed and interrupted all the time. So we just stepped back from the work, mapped it out and tried to understand it. Then I started talking to everyone and they were like, yeah, we need to do that. We’d love to do that. That sounds so important. And whenever we’ve done it, it’s been amazing, but we never have time to do it and we can never get it done. So flow engineering is kind of the culmination of how do you deal with that problem knowing the solution, but the solution as most people interpret it, is too daunting, too much work, too much time, too complicated.

Mandi Walls: And Andrew, what’s your story?

Andrew Davis: Sure, yeah. So I’ve been a long-term technologist, but also very focused on the human interactions, human development and so forth in different roles. The last 10 years I’ve been focused in the Salesforce community and I moved very quickly from being a full-time Salesforce developer to being the release manager for a Salesforce team because I was the junior guy on the team and nobody else wanted to do that job. So that’s a short stick and discovered it’s really, it’s quite a miserable process, very painful, difficult, trying to get all the deployments done. So I became very interested in how do we bring modern, what you might call DevOps techniques to the Salesforce world. Starting initially with just the tactical things, version control and automated deployments and then encountered it revolution, DevOps Enterprise Summit now called the Enterprise Technology Leadership Summit. That really kind of blew my mind, open the aperture on what DevOps really meant.

Andrew Davis: And it began to see this. There was this rich community at the convergence of tech and humanity, and I thought these people are deep thinking. And I became a big fan of Jez Humble, just sort of binge watching everything I could get my hands on from him. And he made frequent references to value stream mapping as an activity, and I had a fascination. I went to a workshop, Steve was leading on value stream mapping three and a half-ish years ago at DevOps Enterprise Summit. Said, Hey, any books you’d recommend on the topic? And he’s like, well, there’s Karen Martin’s book, but then everybody feels like it’s too heavy, it’s too much, and so forth. And I had written a book mastering Salesforce DevOps on DevOps for Salesforce. It’s a funny thing about books. I think my relationship with books a little bit like some women’s relationship with having children where it’s excruciating and you swear to yourself you’ll never do it again, but then shortly afterwards you’re like, huh, I could do another one. So I proposed to Steve, Hey, we could write a book and three years and lots of pain later. It was a joyful process, but it’s been quite an amazing undertaking. A ton of thought has gone into this and great discussions

Mandi Walls: As I read through it. The amount of research that’s in here, the six page bibliography, there’s so many things and it’s so deep and so dense. I am just thinking this is a lot of research and a culmination of what seems like a lot of work with all of these things. There were some things that most of our listeners are probably familiar with, but there’s also some stuff in here that I hadn’t heard of or maybe hadn’t heard of recently. And the first part of it, even in the very beginning, you started talking about a concept called cybernetics, which I don’t think I had ever heard in this particular definition before. So can you start us there? Just start us off with what is cybernetics? How does it set the stage for what you’re going to go into with the value stream mapping and then eventually flow engineering? Andrew, if you could start us off there.

Andrew Davis: Sure. So it was an interesting, I dunno what it was coincidence that Steve and I both at some point raised the topic of cybernetics to each other, and both of us had been super interested and excited when we tapped into it and we realized that there was a shared fascination with it. So cybernetics was, I guess you’d say an intellectual movement that started around the time of World War II and continued in earnest for 30 years or so as one of the early systems thinking movements where 20th century thinkers were trying to figure out, there’s a lot of similarities between the biological world like medicine, how the body works and the mechanical world, and we need to accomplish these really challenging mechanical processes. One of the original research topics was how to point a gun during World War II at an aircraft that’s flying and there’s a very challenging problem, lots of differential equations, and they realize that the body does that naturally, right?

Andrew Davis: Your eye can track an airplane flying across the sky quite naturally. How do you do that? Well, there’s feedback loops and mechanisms within the brain and the eye and so forth. So cybernetics is the root discipline that later, the reason you haven’t heard about it is because it turned into artificial intelligence and machine learning and robotics and cybernetics, movement in sociology, cybernetics movement in cognitive science. It basically branched out into a whole bunch of disciplines. But what it was originally, it was very cross-disciplinary. It was a convergence of lots and lots of disciplines. The cybernetic thinkers were generalists and they were finding common patterns across all of these systems. And the word is the same root word as Kubernetes. And so all the DevOps people who are sort of run that word across their tongue and through their head, Kubernetes, what it means is helmsman. So it’s like it’s the process of steering. It’s an interactive process of feedback targeting where you have an outcome, a target goal, and you’re checking your current state and then assessing what’s the future state you want to get to and making adjustments on an ongoing basis. So there were lots of reasons why we were and are still very, very interested in this. But …

Steve Pereira: Mandi, I’m glad you went to Andrew first. He always explains this much better than I could. But I will say you mentioned all the stuff that went in the book. You should see how much material on cybernetics we cut out of the book just because we could write an entire book on cybernetics or flow engineering in the context of cybernetics. So we basically did it and we’ll trickle that out as people show interest in the material. But the thing that I will say maybe to anchor this in the context of the audience is the example, the classic example for cybernetics is a thermostat like set a target and then evaluate the current state in relation to the target and then make up the difference, essentially aim, understand, and then act. It’s a little bit different than uda. People might’ve heard of OODA before. It’s all really in the same space and coming out of the same body of knowledge, but it really kind of let us anchor the content of the book and we talk about effective action.

Steve Pereira: We had to go back to cybernetics to really understand it. Do we understand that? Do we understand what it means to act effectively? And we started seeing all these patterns the same way that people have seen them across cybernetics and all these different domains. What are the few things that are really underpinning all this stuff so that we can anchor what we knew and what we’d seen and what we’ve heard onto this bedrock. So we know that we’re building on a solid foundation and we’re not just coming up with stuff. All of this connects to these few kind of common solid principles and scientific reinforcement that really landed credibility. So you don’t have to take our word for it. All of this comes from rich history and body of knowledge that people can dig into if they want. And that’s kind of the reason for the extensive bibliography is we’re standing on the shoulders of a lot of research and a lot of efforts that came before us and just kind of tying it together in a new way, hopefully an accessible way for folks because to tackle that problem, how do we actually do this?

Steve Pereira: How can we do this thing we know we got to do, but it’s a lot of time. It seems complicated. How do we connect it to the goals of the organization and all this other stuff that gets in the way?

Mandi Walls: Yeah, absolutely. And I’ll say, I think you did a really good job of distilling all of this. I found the concept to be really easy to follow, and I do have some familiarity with value stream mapping and some of the other things I hadn’t heard of all the maps that you outlined. So the way the book is organized, part one, sort of an introduction sort of lays out some of these baseline definitions and some of your initial premises and all that kind of stuff. But then part two, it gets into all these mapping exercises and there’s what four different ones outlined in the book. I liked how you put them together with why you’re pointing in that direction, why you want to do this kind of mapping. But then there’s also parts, the end of the chapters to actually how you go into each of them, how you should run the exercise and all those kinds of things.

Mandi Walls: So as you’re looking at working through these exercises with a team, should teams be approaching these with an eye of completing all the maps? Is it an exercise that you should do from step one to step five? Like altogether, like take a week and do it, or is it something that sort of strings out along over a couple of months, it seemed like there were maybe opportunities to start a map, work on it a little bit and then come back in a few weeks to see where things sat. I don’t know if you have some recommendations for that, Steve.

Steve Pereira: We say in the book, and it’s probably lost in the context, but if you and everybody that you’re working with know exactly what to do and how to do it, you don’t have to do any of this, right? I mean you’re essentially acting effectively already, so carry on. But if you hit a situation where you are uncertain on how to proceed or there’s this distribution of certainty where some people seem to know exactly what they’re doing, maybe they do, maybe they just assume that they do, and then there’s other people who are maybe a little bit more cautious or considerate thinking, I really think we’re not necessarily on the same page here. This is an opportunity to step back from that uncertainty and look at evaluate the landscape and try to effectively synthesize it to get back on the same page. And so we present this in a specific order to build you up from situations where there’s a large number of considerations to synthesize.

Steve Pereira: There’s different goals, there’s different pain points, there’s different ideas, there’s different context. Bring that together and focus on a specific deliverable or target outcome as we phrase it. And then go from there and look at, okay, what’s involved in delivering that? What’s happening currently? Where are these pain points that we can dig into and understand at a deeper level? And how do we take everything that we discover and make it actionable, put it onto a roadmap and give it some ownership and give it some measurement and give it some clarity so that we can actually go forward, whether it’s together or we split up, but we are still not working against each other and we all end up where we aim to end up. So the ordering is deliberate, but it’s optional depending on what you need. And so we really aim to be helpful without being prescriptive and enabling these dynamics of collaboration to kind of create outcomes that are really tailored to the situation, circumstances, the organization, the target.

Steve Pereira: And to your second point, what’s the timeframe? We want all of this to be very accessible. So the target is 90 minutes for every map and hopefully that’s fits into gaps that you already have, whether you run retrospectives on a regular basis or you regularly step back and do some kind of measurement or evaluation or retroactive analysis or you do lunch and learns or whatever. And ideally what you do is you go from that state of uncertainty to clear next steps over the course of a couple of days. Then what’s going to happen is when you act, you’re going to change the circumstances, you’re going to change the bottleneck that you had. Bottleneck ideally isn’t the bottleneck anymore and it’s somewhere else. And so in three months and six months you could come back to it and map again and find your next opportunity.

Mandi Walls: Yeah, one thing that really struck me about some of that was there’s one vignette, I forget which chapter it’s in, but talking to the folks in the story, the parting comment was this is “the first time we’ve ever been in the room altogether before”. And thinking about that and the amount of game of telephone that can happen with teams that don’t communicate directly and don’t have the same viewpoints on the whole whatever you’re working on, whatever the workflow is, everybody sees their little part of the elephant and they don’t know what the whole elephant ends up looking like was really striking for taking an exercise like this and being able to say, well, this is what our team sees, but this is what the next team down the line sees. And giving that new lens to everyone in this kind of exercise that feels like it should be pretty speedy and pretty collegial and a lot less, I don’t want to say fighting, but everybody’s got their own viewpoint in it, so there’s not necessarily a need to really get belligerent about all of it. It seems like a more positive kind of experience for most people who would participate in it. I don’t know if you would agree with that or not.

Andrew Davis: Yeah, there’s a balance. Two couple of poles or extremes we talk about in the book. One is prescriptive, the other is generative. And so prescriptive is the idea of a top-down approach. This is where we’re going, this is the direction we’re going to prescribe something. And generative is like bottom up, what should we do? Share your ideas, share your understanding, and both of those are necessary. And really even that is a cybernetic principle. You need high level direction, a clear outcome and so forth. But at the same time, the assumption, the presumption or assumption that everybody on the team knows why we’re doing this initiative and knows how important it is, is a gross exaggeration in general. So you can roll out a top-down initiative, but the first map of the five maps outcome mapping is mostly for the purpose of just helping to ensure that the team actually knows what they want to do and that is not something you should presume. And so anyway, these two polls of prescriptive gives a real direction to things. But degenerative side, it’s all participatory is to focus on engagement and really drawing everybody out and sharing all of our diverse understandings and so forth, but in an intentional and directed way. So it’s not just wandering or endless chatter for a point.

Steve Pereira: The mapping aspect of it kind of navigates this middle way where the shape of the map, that kind of template of the map or the rough structure of the map gives you the prescription. Something that gives you enough certainty that if I fill these things in, or if I start building it out this way, then I’m on the right track, which is very helpful I find. Because when you have a blank page, who knows what good looks like and who knows what your first step is and who knows if you’re headed in the right direction. So you need prescription for that situation to get you started, give you the comfort that you’re on the right track and keep you constrained in positive ways so that you don’t blow up your scope. It doesn’t take too long. And then the generative aspect really is okay, given the structure, what is our context within the structure?

Steve Pereira: What can we create and what represents our situation if we are looking at it through this lens and how do we represent our situation using this structure? And that way you’re getting a completely unique outcome. An output of each map is completely unique. The dynamics involved in the mapping are completely unique to not only your organization and your team, but that point in time. So that changes and it’s never the same twice. We’re trying to enable with constraints and then govern effectively with constraints to help people kind of get started with enough confidence that, okay, I can do this. It’s not just a blank page, it’s a process I can follow. But what they create, and one thing that we really emphasize is that the mapping is more important than the map. It’s that creative conflict, that constructive discussion and dialogue that comes out of this is really the most valuable thing. It brings you closer to your team, it brings you closer to that person who you’ve never been in the room with before. And that’s incredibly valuable.

Mandi Walls: Yeah, absolutely. So well, you run these kinds of exercises with teams. What do you see as the instigation of this? Are folks kind of mired in the muck, they’re stuck in something, or do you see this as a follow on to a major catastrophe or a failed project or people just unhappy with the steady state? What kind of instigation, when do folks think about actually taking the route to doing these exercises?

Andrew Davis: I mean, I would say the subtitle of the book is from value stream mapping to effective action. So thinking about first of all, the context of a value stream map, it’s a visualization exercise and an improvement exercise related to a value stream. So this is relevant, flow engineering is relevant. I mean there’s lots of bits for the book that may be useful no matter what you’re doing, but this is relevant when you want to look at optimizing a value stream. And a value stream is a relatively stable process involving multiple people who need to work together in some kind of a synchronized way to produce value at the request of a customer, external customer, internal customer. And so the book really is about process improvement. And so it’s for when you have a failed project, there could be all kinds of reasons, but a value stream is more closely aligned with the idea of products where there’s something, some stable value delivery process that’s long lasting, long lived, but you want to do some continuous improvement optimization around it.

Andrew Davis: And so within our organization for example, we think a lot about value stream mapping with respect to our customer support process. Customer support requests come in, how long does it take before they get fulfilled, right? That’s a value stream. All the people who touch a ticket before it gets resolved, the product development process, new feature development, our release process, the engineering process, any of these or the customer onboarding process, there’s lots of these internal processes that are repeated lead generation process, content creation for website, for marketing, any of these stable recurring processes where there’s some aspect of it, either timing or quality or whatever that’s causing pain, it’s causing enough pain that you think we need to do something better here. And that’s where this is a worthwhile investment is get everybody together. You’re going to have to take a relatively large group of people, all the people involved in the process for it’s only 90 minutes per map, perhaps Some of my mapping sessions are closer to two hours, but I think 90 minutes is a good human attention span, but it’s a bunch of people for a bunch of hours.

Andrew Davis: So it’s an investment. When and why do you make that investment when something’s really just not working as well as it could be. There’s no better alternative to bringing people together, getting them all coherent on the same page. And if I can continue for a moment more when you pointed out, Hey, this is the first time we’ve all been in the same room together. These kinds of things can happen in value streams in big industrial organizations where people are still working in real life, but it’s much more the case. I think in the digital world. There’s a saying in the lean community, if it’s in the computer, it’s hidden. If it’s in the computer, it’s hidden. When I first heard that, I thought, oh, we’re in trouble over in the IT world, there’s a lot of stuff in the computer because people use the real world to integrate their understanding. So if you’re in the same room together, your understandings naturally integrate with everybody else in the same space. But if we’re all off on laptops especially spread around the world, I think people do not fully appreciate how different our worlds look from those vantage points and how much work it takes to synchronize and how important it is to synchronize on a regular basis.

Mandi Walls: And you made a point early in one of the chapters about people’s frame of reference and how that applies to the documents and artifacts that they prepare. Yeah, you are talking to numbers people, they’re going to give you a spreadsheet even if that’s maybe not the best representation of what they’re trying to get across to you. And folks who work in a more narrative style in a word doc are maybe trying to get their point across and maybe they need a table or graph. And I think that part really struck me as like, oh yeah, everything is in the computer, but it might be in a million different documents in a million different places that aren’t well integrated, that aren’t well collated, I guess, or curated even to give the whole story, to give the whole everyone’s perspective across what’s actually going on in the organization. And that did stick with me too.

Steve Pereira: There’s a couple other perspectives that I have encountered in terms of applying this and where this applies. And one of them is in incident response. So something that might resonate with the audiences, and I’ve used it very effectively in the context, is what happens when something goes wrong? How do we resolve it? What’s our process for resolving it? And it’s very similar to support and product development in that you don’t exactly know how it’s going to go and you maybe have a different outcome every time. You might navigate a different path, but there are this standard activities that happen and they happen in order and some of them might happen in parallel and we can visualize that, but without looking at it and trying to illustrate it, I find most of the value here is when you try to take something that is challenging to think about or illustrate and you try to do it, that is illustrating the complexity that you have to deal with.

Steve Pereira: You might end up with a mess, but that’s just a representation of how messy it really is, which is valuable to consider rather than just going about your business and dealing with it every day. Maybe that’s a catalyst for simplifying or making something a little bit more streamlined. So it works really well in these situations where you think, well, we’re not building widgets here. We’re not just pumping things off of an assembly line. Everything we do is different. Well, that could be a good thing, that could be a bad thing. It could be that you’re doing things that you don’t want to do or you don’t have to do in service of those different outcomes, and those things could be automated or they could be standardized or they could just be simplified or you could just get people on the same page to understand them better.

Steve Pereira: Another case is moving from projects to products. So this does work extremely well in a product context, but I’ve worked with a few organizations that were in a project centric operating model and they wanted to get out of it, they wanted to be more sustainable, move towards flow, move towards a more consistent workflow. And so we could look at how they do projects and use that as a basis for mapping a value stream and understand, okay, well what would we want to keep? We want to build into a value stream. What are the sort of things where we can eliminate waste and delay, make the handoff smoother? And so it is really helpful in those contexts.

Mandi Walls: Yeah, absolutely. One of the other maybe subtopics that is kind of sprinkled throughout the book is the concept of doing these things at scale. And I feel like we’ve got a pretty good mix of our audience and we know there’s folks out there working in very, very large organizations, some folks who work in smaller organizations for folks who are working in a large organization and working towards this kind of maybe suggesting this to their management or they’re in management and they’re like, my team could really benefit from this. How do you keep the mapping exercise from getting too large? You can kind of envision we’re in a microservices environment and we have lots of different teams, have lots of different dependencies. They’re all involved. Do we bring everybody in? We’ve only got, we want to keep this to two hours. It feels like you have maybe a number of people that will also be constrained to keep things productive. Is there some rubric or guidelines that you set for folks for how many people to bring to the table when you’re first setting out?

Andrew Davis: We’ve got a recommendation in the book of not having a group any larger than 13. 13 even is a little bit getting big and weighty and so forth. So you want people who are representatives of all of the respective departments who have some ability to affect change in those different departments, but to keep it constrained just because the complexity with every additional voice and point of view you bring in, obviously you only want to bring in people who are happy to be actively engaged, more actively engaged people you are the greater the complexity of the interactions and so forth. And if you’re obviously in a massively complex environment, you have to descale the problem. You have to break it down to, okay, let’s take the interactions between this particular microservice, which they’re never able to release patches as quickly as we need them to or whatever else.

Andrew Davis: And so you bring it down to a context at which you can think about it at human scale, and then you work on a little bit of optimization there. And this is meant to have kind of a fractal nature where you can kind of work through these exercises across the organization, across teams, but that’s the area where you would apply it right at that scale where something where you can bring a group of people together and it be relatively, it could be done at a very large scale in the organization. Tell us about your customer onboarding process. And there’s all of these groups from marketing to sales to whatever else, and you have representative stakeholders at a relatively high level in the organization who have responsibility over those areas. The level of granularity you get to is not as high, but everybody can walk away with some clarity on what seems to be the issue. We think it’s the handoff from sales to customer success. That’s the gap. Let’s target that.

Steve Pereira: Yeah, I think about this in Andrew’s context of fractal representation, like the idea that a small thing can be just a micro representation of something very, very large, as long as this same structure and dynamic supply, then you can kind of zoom in and you’ll see a representation of that thing at small scale. And it’s very similar at larger scale. I think that the thing that outcome mapping is doing for us is setting that focus on a single target outcome that’s achievable within let’s say six months or three months if we want to get there and then observe the effects for a while and make another decision. So that kind of target scale allows us to take everything that follows and say, well, does that fit in this scope or not? Is this part of getting there or not? And so if you work backwards from the target outcome, one of the biggest reasons why echo mapping is so valuable, aside from alignment and clarity on this valuable target, is as a constraint to keep us from looking at everything or tumbling down rabbit holes.

Steve Pereira: And so the other thing about fractals is you can kind of represent anything super complex in a single sentence. If you do a great job, you can talk about the history of cybernetics in one sentence. You can talk about the history of western civilization in one sentence, and you can also go into exhaustive detail. And knowing what is valuable investment in detail is really a question of who’s the audience? Who is this for? And oftentimes it’s for the group of people who are part of that exercise. But what is really important to consider is you probably aren’t allocating budget or giving yourself space to improve things or investing in specific capabilities. And the people who are probably don’t care about the level of detail that you do, they probably have completely different goals. They have a different perspective. So another really important aspect of that is if you can’t include them from the beginning, be able to clearly describe what the value is from their perspective. And that’s where we get into benefits in the outcome map is really to think about, okay, how does this resonate with everyone else? How is this important to our customers or the board or our senior leadership or the marketing department or whoever else is involved or affected?

Mandi Walls: Yeah, absolutely. I feel like you did a part of it being that discussing incentives and how this whole process fits in with the things that your organization is already headed toward or already incentivizes or is already part of the goals. And then distilling it down into, okay, how do we change our day to day in service to that? And I like the discussion at the beginning too, where there’s a bit of, and if you’ve worked for large organizations, you definitely feel like you’re too many spans of distance away from the customer and too far away from what the customer actually wants out of the day. And I have definitely been places where I’ve felt that as someone who sits in sort of the middle distance and I’m requesting things from someone else who was way far in the back and they never interact with the customer and never really see that interaction. And it’s very hard to balance that, to sort of walk that line for what the customer is going to find value and what our sort of generic organizational goals are and how that distills down into your day-to-day processes and work. It’s super interesting.

Andrew Davis: It’s very unnatural to work in organizations of the scale that we’re working in these days. And so it shouldn’t be surprising that they’re naturally dysfunctional, but it’s dehumanizing in a sense, not in a malicious way, but it’s dehumanizing to be in a job where you’re too many arms lengths away from the customer as you said that you struggle to understand what are you doing? Why are you doing that? You lose that orientation to a sense of purpose and meaning in your work. You don’t really know how anything that you do matters. And I mean literally if you go down that line of thinking, you’ll end up depressed, profoundly depressed about your life purpose. But the thing is, typically you are already helping lots of people. You’ve just lost sight of that. You’ve sort of lost the perspective. And so the first map, arguably the most important map outcome mapping, is about trying to rehumanize and reestablish a sense of purpose in what we’re doing. We’ve got a dedication in the beginning of the book. This book is dedicated to everyone brave enough and idealistic enough to bring humanity and flow back to the workplace. That’s one aspect of,

Mandi Walls: Yeah. Excellent. All right, so wrap everything up. For folks who are on this journey or think they would want to go on this journey, the book is a great place to start and like I mentioned at the beginning comes out May 14th looking for folks who are facilitators for these kinds of things. Is this something that they should be looking at hiring the consultant to come in and help them out help or should large organizations be thinking about investing in their own teams that can run these kinds of exercises across the organization? What does that look like? Steve, you’re nodding

Steve Pereira: As a longtime facilitator of this kind of thing. I think that there are a number of opportunities inside of most organizations. They probably already have a large number of facilitators that are doing different things. They’re doing agile coaching or they’re operating as scrum masters or maybe even product owners who like to step away from the work and think about how are things going and how do we move things in the right direction? And I think that that motivation is very powerful and can be kind of channeled towards this effort of flow engineering. There are a lot of benefits to bringing in an outside perspective, whether that’s outside the company or out in another team or in another division because you really don’t want to be too close to the outcome. You don’t necessarily want a vested interest in the outcome and you’re going to start steering things or getting too attached and distracted because it’s a lot of conversation that you’re generating and you want that to be a generative exercise.

Steve Pereira: You don’t want it to be prescriptive or shaped by the facilitator. The facilitator really has to be good at picking up on weak signals, making sure that everyone is contributing equally and people are heard and that they’re calling out patterns and things that are present and emerging out of these mapping exercises. That’s a skill and it’s the most difficult part about this is building facilitation skills and being very good at that, getting people comfortable and creating a safe space for collaboration. And so I would say it’s not just something that people casually decide to do and think that following the recipe in the book is going to drive the best outcome if they’re not interested in facilitating. That being said, you could follow the instructions and you will absolutely get benefit, but facilitation really kind of dials up the impact of all that collaboration and makes sure that you get the best outcome.

Steve Pereira: And so someone with facilitation experience I think is very valuable in that context. And with what we said about proportion and how you scale this, if the scale of the impact that you’re targeting is multiple millions of dollars, then contributing an investment to this that’s proportional, I think makes a lot of sense. If you’re just trying to get out of a sticky situation, really anybody could follow the book and get a great result from that. And so I think along that spectrum, that might not give you a clear prescriptive answer, but hopefully that’s some guidelines that kind of highlight the stakes are high and the opportunity is high. If we’re in a multinational organization that seems to be just hemorrhaging money all day, it might be something that you want to invest in.

Mandi Walls: Alright, well thank you guys both for joining me today. This has been great. This is a great discussion. I learned a lot from the book. I have no dreams of being a facilitator or anything like that, but I did learn a whole lot more about the stuff than I knew before because we’ve had a couple other episodes about value stream mapping and some of these other things, but there’s a lot of context and like I said at the beginning, a lot of research and history that’s in here that really makes everything sort of hang together very well. Hopefully some of our audience will also find super helpful. So in the meantime, where can folks find you? Are you online on social media? Andrew, do you have any social media pages that if the folks want to learn more about what you’re up to that you’re on?

Andrew Davis: LinkedIn’s my active social media platform at the moment. You can find me Andrew Davis at LinkedIn. If you search for Andrew Davis Salesforce or DevOps, that’s more likely to find me. We have a website as well. Flow engineering.org.

Steve Pereira: Yeah, good highlight. I’m the same. I spend a lot of time on LinkedIn. There’s a lot of great discussion happening on value stream mapping and lean and agile and the intersection of all these things. And we love to be talking with folks about their experiences and their challenges. There’s a lot of really great discussion that happens on LinkedIn, so very happy to be there and connect with folks.

Mandi Walls: Love to hear it. So thanks for being here. For everybody else, we’ll wish you an uneventful day. If you have a book recommendation for our future book club episode, you can email my team. We’re community team@pagerduty.com. If you’d also like to be a guest or if you’ve written a book you’d like to come on, let us know. We’ll be scheduling episodes for the next several months and looking forward to it. So Steve, Andrew, thank you again so much for being here. This has been great.

Steve Pereira: Thanks so much Mandi. Thanks for having us.

Mandi Walls: That does it for another installment of Page to the Limit. We’d like to thank our sponsor, PagerDuty for making this podcast possible. Remember to subscribe to this podcast. If you like what you’ve heard, you can find our show notes at page to the limit.com and you can reach us on Twitter and page it to the limit using the number two. Thank you so much for joining us and remember, uneventful days are beautiful days.