Flow Engineering with Steve Pereira
[00:00:00] Adam Hawkins: Hello and welcome. I'm your host, Adam Hawkins. And each episode I present a small batch, but theory and practices behind building a high velocity software organization. Topics include dev ops, lean software architecture, continuous delivery and conversations with industry leaders. Now let's begin today's episode.
[00:00:26] Adam Hawkins: Hello, and welcome back to small bags. This episode is part two of my conversation with Steve Pereira. Steve is the founder of visible consulting. You may also know him as the value stream guy, and he's also the founder of the flow collective, a private group for discussing and proving flow in organizations.
[00:00:48] Adam Hawkins: In this part of the conversation, we go deep into the topic of flow engineers. Specifically the four outcome maps, also the connection between individual flow and organizational flow and kind of a hierarchy of needs for flow engineering. And with that, I gave you part two of my conversation with Steve Pereira.
[00:01:12] Adam Hawkins: All right, Steve, welcome back to the show. And the previous episode, we talked about the concept of flow of flow engineering and the four outcome maps. You gave a little bit of introduction there. I want to go deeper into it in this conversation, like why the four outcome apps, like you spoke about capabilities, like why are these things so important to like specifically designed for.
[00:01:40] Steve Pereira: Yeah, I mean four maps. Actually the concept behind for maps specifically was because we had four key metrics. This is the sneaky backdoor origins, the secret origins of the four key maps. There's four key metrics in dev ops. And for me to get early attention. On flow engineering out of all the maps that I love.
[00:02:05] Steve Pereira: And there's about six or seven, now that I use on a regular basis that are officially well, that there's nothing officially part of flow engineering, but that I run in sort of like this, this flow, this flow from outcomes all the way to. The ultimate, you know, the real path through flow engineering is outcome mapping value, stream mapping, dependency, mapping capability mapping recently added Wardley mapping because I really actually have found ways that the formats really flow into building high quality Wardley map.
[00:02:44] Steve Pereira: And then we look at a prioritization map, which is just a prioritization matrix. But a visual representation of priority and then a flow roadmap, which is a roadmap that's kind of dedicated to the how. And the reason for that is like we have product roadmaps. We have technical roadmaps, a lot of teams struggle with how do we actually connect the product roadmap to the technical roadmap?
[00:03:12] Steve Pereira: And then how do we actually do any of this? And there's no roadmap for how there's no roadmap for the machine that does the things. And so that was the ultimate culmination of the artifacts. The outputs of each of these maps is creating a flow roadmap that helps you build the machine for creating and delivering value.
[00:03:34] Adam Hawkins: So in my experience, one thing that's been really challenging for any organization is. Integrating of the product roadmap and the technical roadmap, because for whatever reason, these things are, tend to be kept separate. When I don't think that they should be, they really need to be as integrated as possible since they depend on each other.
[00:03:55] Adam Hawkins: Why is this such a common thing? Like why is this a challenging like, door to open for people?
[00:04:01] Steve Pereira: Well, I think it's the. We don't take the time and we don't have common language to come together as a product tech business and tech. These separate domains where each party has a discreet incentive, which is often elevated above the ultimate incentive, right?
[00:04:26] Steve Pereira: These local incentives, the parochial incentives of each of these groups or roles gets elevated above. The collective goal. And so that's why I think things like outcome mapping, where you bring all those parties together and everybody kind of picks at least a single, you know, high level target that that is.
[00:04:52] Steve Pereira: Higher than my incentive is higher than your incentive it's customer focused. And so it can kind of realign us from like, yeah, I'm doing the things that are going to get me, my promotion, but really the things that are going to get me, my promotion, if I think for two seconds longer than that is positive customer outcomes.
[00:05:11] Steve Pereira: Right. Right. And so. If we can get everybody on the same page about what is the ultimate goal, what's the higher goal that helps us forget about our immediate incentive, our individual incentive. Then all of a sudden, what we can do is we can use that to frame and map. So map in the context of I'm going to connect this thing to that thing, right?
[00:05:33] Steve Pereira: I mean, mapping has a couple of different meanings, which is kind of why I love it, but mapping in the sense of like, I'm going to connect this to that, and I'm going to map these things together. That's a thing that you can do a lot easier when you have an outcome app. When you have a clear outcome and with an outcome app, what we do is we break down the target outcomes.
[00:05:53] Steve Pereira: So first we brainstorm and we think of what are all the pains? What are all the goals, get them all out. You can group them, you can look at common themes. You can look at things that tie these things together, and then we can pick a focus and maybe we, maybe we ranked. A few of them in cases where there's like, you know, we're not going to do this for another year.
[00:06:16] Steve Pereira: Let's pick four, we're going to rank them from one to four. But, um, you know, Tighter, you can have that focus the better. And then we look at why, why is this outcome valuable? So that for the people who are like, you know, I don't really understand this, they get a better picture, why this outcome is even important.
[00:06:37] Steve Pereira: And we get to kind of convince ourselves that this is important by turning it around and, and kind of looking at it through that lens. And you get a little bit more excited about it. You know, you can pick something that really means something to you, and that makes it easy. Yeah, it makes it easier to be on the same page and kind of agree on what we're doing.
[00:06:55] Steve Pereira: And then we talk about obstacles. We talk about what are the things that are going to get in our way. To get those fears out, to get those, to get the people who are the, you know, the red team to give them an opportunity to speak up because they're, they're valuable members of the team. That perspective is valuable.
[00:07:12] Steve Pereira: So giving them an opportunity to surface those concerns. And then we look at really as many other factors as possible, but we can look at experiments that we might want to run. We can look at. Rules that are going to be involved in that outcome, but it doesn't have to go super deep. It doesn't have to be super extensive, but that outcome and the clarity around that outcome helps us do that mapping because now we can look at, okay, well, how does the product roadmap item that milestone relate to the outcome?
[00:07:47] Steve Pereira: And then what is the technical. Roadmap item. That's going to help get to that outcome too. And you can draw that, like sometimes you can't connect them directly, but you can connect them through the outcome or else they're not valuable. Right. It's kind of a, it's a good test because you have things on your roadmap and they don't connect to your outcome.
[00:08:08] Steve Pereira: You fail that test really easily and cheaply, and it doesn't cost you. 18 months and building out something that's useless.
[00:08:15] Adam Hawkins: Well, I can attest to that. I mean, at a company where I work, we went through the exercise of creating like a combined product and engineering roadmap that was represented in visual form in a.
[00:08:30] Adam Hawkins: Directed dependency graph. So everybody put their projects, the things that they needed to do. And then we had the global company outcomes, like, you know, there's, you know, revenue, customer facing things, all, all that stuff. Right. And then how does one dot, like one thing that you added, how does that track through to the top level goal?
[00:08:49] Adam Hawkins: Like if it doesn't, then there's a problem. Or if there's stuff that we have, that's not. In the set of agreed upon priorities or things we need to do well, then there's also a problem. This comes back to why it's so important to visualize information, because that gives you just another kind of, I don't know, test for it to like, does this actually fit the model that I have?
[00:09:12] Adam Hawkins: Like, does this fit the way that I'm thinking about it? Funding to be how you usually, the first step in any of these large efforts is just to draw something like, just put whatever you have on a white board or somewhere mural or whatever, but put it in a way that you can take this large idea, be it a value stream or some projects and way you can just show it to a person and a single picture.
[00:09:34] Adam Hawkins: That picture is worth a thousand
[00:09:35] Steve Pereira: words. Yeah, a hundred percent. And I think that it's kind of a natural behavior in architecture and in software development where people will jump on a whiteboard and throw up a bunch of boxes and. There still is a gap there most of the time, because it's usually not in the context of a customer or an outcome is usually meant to illustrate something that lives in someone's head, but is disconnected from an outcome, right?
[00:10:03] Steve Pereira: It's like I have this idea in my head for that, you know, this streaming infrastructure and then I'm obsessed with it because it's a problem that I really want to solve. And I've been dying to work on it. So let me tell you about it so that I can convince you to let me do it. Then people get caught up in that and they forget that.
[00:10:19] Steve Pereira: Wait a second, like, first of all, how does this connect to the greater purpose and the, you know, the greater outcome that we're, we're heading towards?
[00:10:29] Adam Hawkins: You know, one thing is sort of, okay, this is just sort of an omission to listener that like, you know, of course I'm really invested in these ideas. I think they're powerful.
[00:10:38] Adam Hawkins: I think there's. Some deep philosophical stuff here and using words like, or phrases like greater cause greater purpose. Like in my mind, it goes to this sort of idea of like, Hey, this could almost, there's something that could be religious about this in a sense of committing to like a certain way of thinking a certain way of acting, especially, I mean, it's right there in the high-velocity it's not the religion aspect, but just the thing that your work should always be in service to a larger.
[00:11:08] Adam Hawkins: Like the work is, should be, is end to end focused on the customer, focused on delivering value. It's all about like expanding your scope to something that's greater than the individual, like some larger purpose, bigger than you. Like you have a role to play in this plan, you know, not like God's plan, but there's this plan, you know, but that's, I think that's just how powerful these ideas are.
[00:11:31] Adam Hawkins: If you fully commit to them and focus on applying them in a different context, like you've experienced in your own. Career, like once you made this one step, it unlocked another magnitude of performance and other magnitude of like, understanding like a new, just a whole new capability in terms of what you able to accomplish.
[00:11:48] Adam Hawkins: And that all came through like a way of thinking. And all the practices that, that brought along. So not to derail the conversation with religion as something I just always think back to, but I want to turn attention to the capability map a little bit, because when we talk about visualization and trying to like talk about flow is how do we make.
[00:12:11] Adam Hawkins: Right. Like, oh yeah. We have metrics from, you know, like accelerated in the DevOps handbook, but how do you go about collecting, like, metrics about the value stream? Like metrics about like the work that you do, like, is that part of like, in your mind, like a specific capability or is that kind of separate, you know, how does the act of measuring these things fit into the concept of flow engineering?
[00:12:37] Steve Pereira: You know, I think that. It's really important to make sure that things are measurable, where we can make them measurable in some way, whether or not it's perfect, I think is, is not a reason to not try and whether it's qualitative or quantitative, you know, if we take what we can get, even if we are measuring based on a baseline of this is just how different is this from yesterday?
[00:13:03] Steve Pereira: Right. I mean, there's so much value in sort of just that consideration of progress, whether it's in a positive direction or negative direction or static.
[00:13:13] Adam Hawkins: Well, I guess my question though was more like, how do you actually go about getting the data? Like how do you have that instrumentation to your processor, to your values?
[00:13:22] Steve Pereira: Right. So the first thing is I just wanted to preface it by saying that, you know, we don't always get quantitative data, but I don't think that that is a, a problem or it's not as big a problem as people might worry about. Really, when we do value stream mapping, I don't need hard data. I actually find that there's a lot of value in just asking the team for what they think.
[00:13:46] Steve Pereira: And the reason is because it prompts people to think about and kind of map this information or reconsider their workflow in a new lens. People don't often think about measuring. Their performance, unless they're a specific type of, or nurse. Right. But even if we're measuring individually, we don't often measure holistic measurement.
[00:14:15] Steve Pereira: Right. We don't often step away and say like, how is this working for us as a team? And so they just, the act of sort of asking people like how long does this usually take. Um, and people get hung up on usually or what do you, what do you mean by usually and, well, you know, last time it was this, but it was because of the special circumstance and all of that is challenging, but doesn't discourage me from taking the approach.
[00:14:42] Steve Pereira: Asking the team, because I think there's something really magical about working with a team that is confronted with this challenge of measuring things that they've never measured before and never thought about measuring before. And they start to kind of negotiate. As a team to start to have a conversation amongst themselves, about how long does that really take and why does it take that long?
[00:15:05] Steve Pereira: And D does it always take that long or is it just that one time? And I think this is building a new lens for the team to kind of consider their work in a different way. And so the by-product of. Low fidelity measurement is something that I really valued. And I really think that it's powerful because in my experience, working with my teams before I was doing this for other teams that sparked so much creativity and just fresh thinking about what, like, wait a second.
[00:15:41] Steve Pereira: What is. And those sorts of things happen. They come to mind when the team is kind of forced to map this data in their head and navigate this information in their head and then reconcile it with everybody else because everybody has an assumption about, okay, well, I thought it took three days, but you're telling me it took a week and that's amazing to me because I always thought it was quick and easy.
[00:16:05] Steve Pereira: And I didn't know that you folks were struggling with this, that much, the conversation. Imperfect measurement is really powerful. And so I don't ask for data. Sometimes we get it and we just focus elsewhere. We focus on a place that's hard and where we don't have data, you can always use data, but I find the conversation around, pulling it out of people's heads is so powerful that I don't need perfect because honestly, the difference whether it's three days or two days, The biggest bottleneck is probably three weeks.
[00:16:40] Steve Pereira: Right. So who cares about the difference between two
[00:16:43] Adam Hawkins: days and three days? Well, I guess my thinking is more like you've mentioned capabilities, like one capability of say continuous delivery or automated testing or infrastructure as code. Like those are. Quantifiable, right. There are ways of working.
[00:16:58] Adam Hawkins: There's certain practices that apply, you know, imply different things. My thinking with like, asking about measurement and telemetry, because the same way that like we, as software developers can make explicit choices to add telemetry to our applications, we ask participants of the value stream can also make the same explicit decision to add to elementary, to the value.
[00:17:22] Adam Hawkins: And that kind of telemetry in my mind is a capability that you need to feed back up through all the other stuff. Like, yes, you can get pretty far with, you know, a coarse grain like fidelity sort of like estimations, but when you want to take it to the next level, then you have to commit to adding the specific telemetry throughout the entire process.
[00:17:42] Adam Hawkins: I think this is where the flow framework and the four metrics, like the four different types of work. What's it like, there's different names for all the metrics, but, you know, basically it's like, how long does it take to go to one end of the value stream from the other? Like how long has this been waiting in between each step?
[00:17:59] Adam Hawkins: Like some of these things, like, is that a capability that you like, I guess, do you see that in a capability the same way that I'm thinking about. I
[00:18:09] Steve Pereira: certainly see it as a capability and a very key capability. The capability mapping in the context of flow engineering is, and the reason that it, it follows mapping the value stream mapping outcomes, is that the number of capabilities that a team requires to deliver value to customers.
[00:18:29] Steve Pereira: Okay. Enormous, right. There's hundreds of capabilities and ultimately, you know, trying to assess those and things like capability, maturity models, they already exist. They're they're fine. They're going to be these kind of static checklist things. That's not what we're looking at with capability map. In flow engineering.
[00:18:51] Steve Pereira: What we care about are the capabilities that are most impacting flow for this specific outcome that we're targeting and for the specific value stream that we're targeting. So in the context of where we're looking and what we see, so not only just the value stream, but the hotspots and the bottlenecks in the value stream, those are the capabilities that we care about the most.
[00:19:13] Steve Pereira: So we will. Take the value stream where we've highlighted these hotspots. And let's say automated testing is taking way too long. Infrastructure provisioning is taking way too long and we have all kinds of other abilities like design and deploy. If those are areas of concern, like let's forget about them for now.
[00:19:35] Steve Pereira: We'll map those capabilities. We'll put them on the radar if they become problems, but we're looking at those specific capabilities around automated testing. We might even dig super deep and say, Because this is such an issue and it's so complex. We're going to look at front end testing. We're going to look at backend tests and we're going to look at integration testing separately.
[00:19:54] Steve Pereira: We're going to look at, in some cases you want like full path automation, you could be looking at any specific thing, but the value stream and where the bottlenecks are is what informs the capabilities that you care about in the context of mapping. And it could be that, you know, we don't have any visibility into our performance right now.
[00:20:13] Steve Pereira: So that is a capability that we want to
[00:20:14] Adam Hawkins: invest in. Assuming that it relates back to one of the outcomes. I guess my thinking is more, was more like one metal level deeper, which is like, yeah, you need this generally, but you don't need it in a specific case where maybe what you have your understanding is enough as it relates to whatever your outcomes are.
[00:20:31] Adam Hawkins: But fundamentally if you do care or if you commit to sort of like a global. To optimize your flow, understand flow, understand your value stream. Then just like the software that you write, you need to commit to adding telemetry throughout your process to capture what the value stream actually looks like in terms of, you know, like throughput latency, like the same way that we think about.
[00:20:56] Adam Hawkins: Other operational aspects of other systems. We can impose those on top of the value stream. Once you get to that point, you may not need it initially, but at some point in the journey you'll hit this threshold. That level of thinking is more
[00:21:09] Steve Pereira: applicable. Yeah, exactly. And I think that there's a lot of teams, you know, that they jumped straight to that and they jumped straight to measuring detail.
[00:21:18] Steve Pereira: When, you know, there's a gigantic roadblock in their value stream, but you know, it's a project that people can work on. It's got a nice clean start and finish. Ends up being this nice little piece of automation that spits out a bunch of data that you can use for anything, right. It's not going to be noise.
[00:21:37] Steve Pereira: It's going to be all signal and it's going to be great. But, um, there's very few teams that I think are in that situation. Who have covered the basics and really understand that their value stream is running at a level that they need to squeeze that level of detail out in terms of measurement. But I think that's coming, you know, I think that as the.
[00:22:00] Steve Pereira: Basics get covered and they become more accessible and the teams get really good at the basics. Then we start to see that becoming powerful in terms of value stream management platforms, where you can just kind of instrument your entire value stream and plug it into this kind of management plane.
[00:22:19] Steve Pereira: That's collecting that data and reporting it back to you. So that is coming, but I find that most teams that's not their biggest challenge. The biggest challenge is the gigantic. Or the few roadblocks that are in their value stream right now that they really could resolve in a couple of hours because all that instrumentation and spinning up those tools, you can't do it in a few hours.
[00:22:40] Steve Pereira: You know, you're not going to do it in the time that you could be doing the mapping. And so they're like the highest ROI activity is really just doing that initial mapping. And then at least, you know, what you're looking for and, you know, what's really important to you. When you start looking at, okay, how do we automate this?
[00:22:57] Steve Pereira: How do we scale it? How do we make a continuous.
[00:23:00] Adam Hawkins: Well, I think that's a good place to end this conversation and pick up next steps and what to do with this information. So, Steve, thank you again for coming on the show and listeners, we'll see you back for the next episode. Thank you. You've just finished another episode of small batches podcast on building a high-performance software delivery organization.
[00:23:21] Adam Hawkins: For more information, and to subscribe to this podcast, float to small batches.fm. I hope to have you back again for the next episode. So until then, happy shipping,
[00:23:35] Adam Hawkins: like the sound of small batch. This episode was produced by pods worth media. That's pods worth.com.
