Product Roadmaps and Tooling Planning with Steve Pereira

In this episode, Steve Pereira—the founder of Visible—talks about how his unique approach to mapping helps customers get products out of the door fast and efficiently. Maps flow to build alignment, clarity, and confidence, and Steve focuses on two primary areas to drive exceptional business outcomes: Flow and value. Value stream thinking and methodologies, augmented by continuous improvement and performance.

Subscribe to
our podcast:

Listen on Apple Podcasts


CHARLES LOWELL: Hello, everybody, and welcome to the Frontside podcast. My name is Charles Lowell, a developer here at the Frontside with me also is Taras Mankovski.


CHARLES: Hello, Taras. And today, we are going to be talking with Steve Pereira, who is the founder of Visible, which is a company that is aligned in many ways with the way we like to think about stuff, so we wanted to have Steve on the podcast. I understand that Visible has a quite unique approach for how to realize getting products out the door and making your organization such that it delivers. So maybe, Steve, we can just start by talking about how you ended up coming to found your own company dedicated to this.

STEVE PEREIRA: Sure. Well, thanks for having me on. I really enjoyed our previous conversation. And I think that we definitely do have a lot in common in terms of beliefs and approach and how we see the software development space. Visible is the culmination of about 20 years in the industry, basically fumbling my way through understanding process and value and the ability to combine the two to actually deliver value to customers. I come from tech. I come from hard tech. I started my career building computers and fixing computers, crawling under desks in IT. And I was always missing the value piece, and the customer piece, and the big picture view of how all that fit together and how we can combine efforts to drive creation and delivery of value, and I've seen it missing everywhere, and I still see it missing. Twenty years later, I see a lot of people working on micro-optimizations or working in their own silos struggling to collaborate with other teams, other groups, other roles, and we incur a lot of waste as a result.

So what I've become very passionate about is stepping back from a process or a team or an organization and then crafting a map and this big picture view of what is going on, where the bottlenecks and opportunities and risks are, and then creating insights and data that will support a prioritized list of actions that are actually going to move the needle. So instead of having eight people's opinions on eight different bottlenecks that we could tackle and arguing for weeks, whiteboarding ineffectively, or meeting ineffectively, or writing a bunch of documentation that no one reads, we create maps together. And so everybody is on the same page from the very beginning. And the map shows us where we are going to see the maximum Return on Investment in a way that the C-level executives could understand it, the person who just joined the team yesterday could understand it, somebody in sales, marketing success, or IT could understand it because it's a simple, clear representation of what's actually going on. I think that that's incredibly powerful.

CHARLES: Well, it means that you can be intentional about what it is that you want to do instead of reactionary. Oh, here's this circumstance, and I need to do it because where I sit and what I can perceive this is the most critical thing that I could be working on, so I'm going to react to it rather than having some sort of outside information of an overall priority list.

STEVE: Exactly.

CHARLES: Yeah, it's one way to think about it. There's this phenomenon of. . .what's the word? Priority inflation, where when you're dealing with issues, and you don't have any structure over it, there's this creep of priority to where everything all of a sudden becomes critical. Is it meant to address people operating in those little critical criticality bubbles?

STEVE: Yeah. That's definitely a benefit. It's resetting priority to be globally calibrated instead of locally calibrated because everybody does have their own perception of priority, and very few people approach it systematically. Very few people are running mapping exercises to throw their priorities or their possible priorities onto a matrix and relatively calibrating them. When they do, they might be using impact and effort or RICE or WSJF as a prioritization method, but it's usually not based on a lot of data either. They are still bringing a lot of assumptions, and they're bringing a lot of opinions to the prioritization process. So they have a hard time because you can map a bunch of priorities, but then you've got to go to war arguing with everybody else who argues with your prioritization. So unless you do these things as a group and it's based on a foundation of data that people can trust, then you might not be much better off than having nothing at all.

So the mapping techniques that I'm a big fan of and that I've assembled together in this flow gets you to that prioritization method by way of almost like a blockchain of logic where you can trace a prioritization or an initiative or a decision back through all the contributing factors that said here's how we know that this is a high-priority effort and it's related to value, it's related to quality, it's related to global maxima instead of the local maxima. And it's tied directly to this either Big Hairy Audacious Goal or a desired outcome that the entire organization shares or the team shares or our division of the company shares. And so you can trace these things all the way through. And all of a sudden, people trust it, and people align, and people are ready to go and deliver because they understand it. You've brought them along instead of handing them something and saying, "Here's what we need to do because of reasons."

CHARLES: So as I'm listening to you, I'm thinking, okay, how can we make this concrete? What's an example of how one of these maps might be constructed? If I was on a project, how would you take me through this process?

STEVE: That's a great question. So often, probably the most common case here is teams wanting to go faster. So, we'll have a team that's releasing maybe on a monthly basis, and they want to get down to two weeks. And when they're on two weeks, they want to get down to one week. So that would be a desired outcome that we could start from. And we would set up a workshop where we map that outcome to the contributing factors that we could consider before we move on. So you want to tease that apart and look at not just that outcome as a focal point. We want to say, okay, what are the obstacles that could interfere with us delivering that outcome? So we get that out of the way first, which means the team can dump their fears, share their fears, share the things that they're concerned about. It gives the people on the team who might be somewhat cynical or the people who focus on risk a little bit more than others. It gives them an opportunity to voice their perspective and contribute from the very beginning. Then we also look at countermeasures. So the optimists can weigh in and say, "In order to avoid that obstacle, we could do this or potentially, here's something that we have at our disposal that could help out with that obstacle."

So we break apart an outcome in a way that we make it real, and we get the team to buy into it in a way that we know what it looks like really well because clarity is the most important thing to start out with: it drives alignment, it drives confidence, it drives energy. It takes it from okay, well, we have this thing, and we have no idea how to do it to we understand it a little bit more; we can move on and, we can move forward. And you go from that outcome map to the value stream map because the value stream is the process. It's the engine that's delivering that outcome. So we look at the value stream from end to end at whatever level. So it can be at the organization level if we're looking at we want to deliver three times the portfolio that we did last time, and that would be a very high-level value stream that we're looking at. It could be release level, so we want to release every two weeks. If we go back to that, then we're going to look at the release process. So we're going to look at okay, here's where we have a product change request on one end, upstream the initiation of the value stream. On the other end, we have customers using the release software, or we're collecting data about user activity. So you've got the entire value stream.

What we do is as a group, we will map out each distinct activity, and then we'll measure it. So we measure the time it takes to do each activity and the wait time in between those activities, and those are the primary measurements. So not only do you get this representation of the process, you get the measurement that's going to tell you here's where most of the time is being used. And you can go beyond that to layer all kinds of things like value created by each of the activities or quality like what percentage of this work gets thrown back to prior steps? Or when do we find bugs in this process? Where are we discovering errors? You could layer all that data on, but the most important things are the steps and the timing.

TARAS: I could see these two things in my mind. It's a thing that I've been thinking a lot about lately and specifically around the work that we do at Frontside around optimizing delivery pipeline with engineering organizations and the approaches that we're bringing there are certain kinds of techniques that we use to address a specific quality. You could say an almost measurable aspect of delivery which is there's latency. There's a latency in the system. And I think a lot of people don't think about latency this way, but there's a latency that is usually related to dependencies. So if you have a front end team, and this is a really common case, so if you have a front end team that is waiting for a back end team to give you the API, that latency can occur in a few different ways: one is you could be simply not able to do your front end work because the API that you're using is not reliable. It's either going up and down all the time, or it's always shifting because of under active development, or it's simply not available when you need it.

So your front-end team might be really excellent, or you put together this mobile team that really knows what they're doing, but the back end to match takes a long time to build because there's a lot of legacy. The mobile app could be a greenfield, but the back end API is relying on existing systems. So there could be legacy or technical debt that is preventing things from moving. And there's this latency in the actual process. Is this an example of what you observed? How does this occur to you, what I described?

STEVE: This is a great example. So I would say that the top three issues that I discover when we map value streams is the planning process, so a lot of delay, a lot of waste, and upfront planning that is not visible to the teams because it happens before anybody really thinks that development has started. And a lot of people criticize development because it is expensive and it is complicated, so that tends to slip under the radar, but it does influence lead time. It slows down our ability to deliver and collect feedback and move on and pivot or adjust and adapt. The second one I would say is infrastructure automation, so things like standing up environments, refreshing environments, scaling, upscaling and downscaling, making configuration changes because that's often a dependency that's outside the team. It's not usually a capability within the product team. And then, the third and the most important and the most critical most common is testing, which in many cases is test automation. It's automated testing or a lack of automated testing. And there's also validation throughout the value stream that often gets batched up and is happening in a QA phase. It almost gets compressed into this window where we throw things to someone who runs QA, or there's just this very waterfall activity where we start testing after we've finished development. So those are super common.

This dependency that you're talking about, the front end and back end, is very real, especially in the release process if we're looking beyond a scrum or a sprint. If we zoom out to the release level, that front end back end friction, the delay, is huge, and that's what would bring me to the next map, which is the dependency map. So the dependency map looks beyond the team or the area that we're focused on in the value stream. And it allows you to see what is contributing to any delays that you're seeing in the value stream. So, in this case, the front end and back end, we would see that delay represented in the value stream as this we've finished work on this one part of the front end, and we have this delay while we wait for the back end to be available before we can validate that everything is working correctly and move on to the next activity. But why is that happening, and what is contributing to that delay? We might have an idea, but what does it really look like? So we do the dependency mapping to call that out. We pull that out of the team, and it gives the back end team the opportunity to say, "Well, we have to wait for this. We're waiting for validation of an open-source library that we need to use because this is asking for a new capability," blah, blah, blah. There are all kinds of things that can be surfaced in that. And we go from the back end is just not fast enough, and we're going to have to deal with it, or they're going to have to get faster to we know exactly what's happening. We know where things are breaking down, and we're that much closer to fixing the problem or addressing the problem directly.

CHARLES: So, at what point do you make these determinations? Is this all in one workshop? Because what I'm hearing is getting stuff out of people but then also collecting hard data and doing research. How do you actually construct this map? Is it something you do in two hours? Is it a process that takes weeks? How do you make sure that what you are drawing really is an accurate picture?

STEVE: That's a great question. It's a number of workshops. So commonly, what I'm aiming for is a separate workshop for each purpose, so outcome mapping is one workshop two to three hours maximum. I aim for two hours for everything, and I budget for three hours for everything, two hours for outcome mapping, two hours for value stream mapping at a high level. That's not looking at ideal state or future state. It's really just current state, and two hours for dependency mapping, and two hours for capability mapping. That means that people can stay engaged because when you get beyond two hours, people start, especially on Zoom, to sort of lose their energy. And if we have to come back to it and schedule another session, we can, but two hours is a nice time box.

In terms of accuracy, the interesting thing is a lot of the data is coming from people. It's coming from people's recollection of what happened last time we did this thing. We're not usually doing these things as they happen. We're usually looking at okay, well, think about the last time that we had a release or the last two releases, and we'll kind of average them out. The interesting thing is that we don't need high fidelity data for this because the bottlenecks are really dramatically outlying from the typical activities in the value stream. And what that means, in other words, is there's going to be parts of the value stream that are days instead of hours and hours instead of minutes, and so the exact number of minutes and the exact number of hours becomes insignificant. You get diminishing returns from getting detail because you don't need it. And we're bringing in stakeholders from a number of different roles inside of the value stream, so you get this balance. So you've got multiple developers, you've got product, and maybe you have a scrum facilitator; you can collect data.

And as a facilitator with 20 years of experience, I know what a reasonable number is for things. I know what seems accurate, what sounds okay. And that's all you need. You don't need perfect detail because all we're looking for is priority. We're just looking for show me things that I'm missing. Show me things that are going to actually move the needle, and then let me prioritize those things so that I'm focusing on the most important thing. And it doesn't necessarily matter whether it's seven days, eight days, nine days because it's going to go from nine days to one day. And the less time we spend on collecting that data and worrying whether it's accurate, the more time we can spend on actually doing the thing because you don't want to invest too much on assessment. You don't want to invest too much on figuring out what's going on. Your job is to be doing things and improving the situation. So you just need enough data to make a decision, which is usually 70% of the data.

TARAS: I'm curious, what level of access do you need to have? What's the best entry point in your experience to have this conversation?

CHARLES: That's a good question. So it really depends on the value stream in question or the outcome that we're aiming at. If it's a release process that we're trying to cut in half, then we'd probably want to be working with at least the VP engineering, somebody who is incentivized on delivery value and velocity, but it could be customer onboarding. I could be working with a sales team that's trying to close a funnel of -- They have 5,000 prospects, and it takes them three weeks to engage with all of them. They're never going to get through them, so they need to take their process down from three weeks to two days, in which case I'd be working with a VP of sales. So it's really important to get leadership. You don't have to go all the way to the C-level. It's really who's incentivized on the success of this particular value stream.

And then, we involve representative stakeholders from the entire value stream. So if QA is a part of it, we have to make sure that we have representation from QA, at least one voice, likewise with product, likewise with engineering. We would want front end and back end if we're talking about that situation where people are experiencing friction with that or people complain about it a lot; those are good signals. And we can use that to build out that list of stakeholders. You don't want more than 12 people. You don't want too many cooks in the kitchen, but you also don't want too few because you don't want to be missing data and information.

TARAS: One of the challenges that I see with a lot of big companies is that there is usually impact. The activities of one side of the business can have an impact on another, and people don't really realize that there is an impact until they're stuck doing things a particular way. They'll say, "This is how we do things." QA is a perfect example of this. QA might say, "We need three weeks to QA this application." This is the worst-case scenario, and you hopefully don't have this. But there are companies that operate this way where there's a bunch of development that happens [Inaudible], and now you've got three weeks of QA that needs to happen. Do you ever find this process changing people's minds, causing people to change direction?

STEVE: Oh, absolutely. That's one of the best parts of my job. I've worked with a lot of companies where people are commenting that "We've never been in the same meeting together." But they're part of the same value stream: They hand in work to each other all the time. They depend on each other. They're upstream and downstream from each other. So they should be collaborating on a regular basis, but they've never had the visibility to see that they are that closely coupled and that they do depend on each other, and it is really important that they collaborate. I've had remarks where people who've worked in extremely large companies for 19, 15, 14 years and they say to me, "This is the first time I've ever seen the process from start to finish," which is crazy. We know that that is true because what opportunity would they have to see the process start to finish? This is not a regular practice. This is not something that people do, but that's kind of what I want to change. I want to be part of this movement towards increased visibility, increased transparency, increased representation from everybody involved in delivering value because I think it's incredibly powerful not just from the perspective of delivering better outcomes faster and making people happier to do it, but it just builds so much empathy, and it builds so much personal ownership as a contributor. So everybody can see here's how I fit into this, here's how I'm helping to row the boat. I think that drives alignment and drives this sense of unity that is so powerful.

And we have so few ways of doing this other than team-building exercises or looking at a CI/CD pipeline, that's giving you a slice. It's giving you this tiny view of what's going on, and that causes problems because we think that this is all I need to be looking at. We need to step away. We need to look at the big picture on a regular basis because we all have more in common with the people that we work with, with the people upstream and downstream from us. To quote Sesame Street, "These are the people in your neighborhood," and we need to work together because that's how you get positive outcomes, that's how you get Return on Investment, that's how you satisfy customers.

CHARLES: In terms of the philosophical underpinnings of what you're describing, it's reminding me a lot of the Toyota Kanban process with how they run their factory floors and maybe not so much in the details of the process you're describing but in the spirit of everybody in the assembly line being able to understand everybody else's job and everybody in the assembly line knowing what's upstream and downstream and anyone being able to even take that knowledge and having a free hand to suggest improvements to the process and being able to do that as someone who has knowledge of that entire assembly pipeline. That's something that they tout highly in Toyota is that they have factory workers on the floor who are able to actually improve the process because they have that global knowledge of the assembly, and they know what their neighbors are doing. And it demonstrably engenders that unity and that pride and that belief in the shared purpose. So as you were speaking, I was like, wow, this is so similar to what I've heard described is going on there, which would seem to validate the idea.

TARAS: That's exactly where it comes from. Toyota invented value stream mapping, and all of their lean manufacturing processes are what are now coming into software and leveling everybody up because we've learned a lot of lessons in manufacturing. There's a lot more in common between building software and building a car than I think we commonly acknowledge. There's a lot of creativity that's involved in software but not necessarily creativity that adds value. And I think we need to focus on creativity that adds value, variability that adds value and get rid of robotic activities and things that can be automated so that we can focus our time and energy on the things that should be and can be creative and can add value.

Right now, we have this mix where we do a lot of things that aren't necessarily creating value or increasing value, but we don't look at them. We're not measuring these activities against each other. We're not saying, "Well, we get 10 times the return doing activity A than doing activity B, and yet we invest the same time and energy and concern in both." We're not focusing on the things that will ultimately drive an incredible amount of value to our customers. And that's just going to be the next 20 years of software. That's where we're going. Because the companies that do that, the companies that recognize that you are creating a machine that delivers value and it's not artisanal -- We're at the scale now where software has to be delivering results. There has to be clear ROI. We're running the world on this stuff now. We're past the point where you're building toy applications that can just be working on a tiny corner of your business. We have software now that runs massive multinational corporations and partnerships and platforms that companies are building their platforms on. This is demanding a level of attention and sophistication, and automation, and coordination that just makes all of this mandatory. We cannot treat software development as this ad hoc seat of our pants. Figure it out as we go along activity if we want to maximize value and if we want to achieve everything that we can achieve with value delivery.

TARAS: So we work with engineer organizations, and so we help them. Steve, in your terms, it would be ‘help them improve their value stream.’ But one of the challenges is that it sometimes requires work that people don't see value off for some time. You mentioned before that introducing a platform can be a solution, but introducing a platform can take some time, and quite often, it doesn't translate into productivity. It could be easily six months before all of the framework or foundational pieces are in place for people to actually start seeing the outcomes. So I think if there's a way to create confidence along the way, I think that'd be really helpful because you want to be able to maintain a certain degree of enthusiasm for what you're doing, and it is probably the worst to get to a point where you're 60% there, and that's when everyone starts to doubt whether this is still the right way to go.

STEVE: I think that that is a huge motivating factor towards this movement towards value stream thinking and big picture thinking and really visualizing end to end process because a lot of individual contributors are going to hear this said "Oh, you need to now take what you know and layer on this extra thing. You need to now be worried about two things instead of one thing," or "You need to now be doing this thing that maybe is pulling you away from where you want to focus." And I think that's the wrong way to go about it. I think that the right way is to represent the value stream, allow people to see how their contributions are affecting the team and affecting customers, and affecting our ability to deliver, and then allow them to contribute in a way that they are most valuable.

But also, it gives us the ability to say, okay, well, instead of you just adding five new capabilities to your portfolio and then shifting your focus all the time between these new capabilities -- Because this is an activity that is critical to the value stream, and it's an opportunity that we need to capture across all of our teams, let's build that capability into some form of automation or self-service right into a platform or leverage a solution that allows our specialists to remain specialized or focus in an area that they really want to be contributing instead of saying, okay, well now you have to do this, and this, and this and be good at all of it. I think that's not necessarily the solution. I think the solution is basically stepping back and saying okay, well, if we want the flow of value through the value stream to be optimized, if we want better performance and we want fewer things to slip through the cracks or be delayed by handoffs, what would it take for us to automate or augment or support that activity? And in some cases, that's going to be a platform even if it's a minimum viable platform. In some cases, it's going to be pairing. In some cases, it's going to be cross-training, but you have to look at the big picture in order to make those decisions really with a high degree of confidence and capability.

So the visualization of the value stream is really going to put you in a position where you can say, you know what? There's no other way to drive the level of performance and value that we need without you in addition to doing software development, starting to do infrastructure development. That's just the best solution that we have at the moment. But you're going to be able to say that with high confidence, and you're going to be able to show your thinking, is the other thing, which means instead of someone grumbling that now I have double the workload or I have to be an expert in this thing that I don't care about, you can bring them along and show them here's what that means. It means we can go from three days for a new feature to two days, and that means you get faster feedback, you get to work on more new things, and that also means you wait around less. All of these things can be clear and visible. And I think that's super, super powerful.

I've been in this situation of trying to convince people that an investment that had a somewhat distant time horizon for realization or a Return on Investment was the right decision. And I was always looking for ways of showing my math and showing my math in a way that would resonate with a bunch of different stakeholders because, in some cases, I've got to go to the board with it to make the case. So having a map and having this visualized representation of the data from a number of different perspectives we're looking at and not just the value stream. We're looking at dependencies that are involved. We're looking at capabilities that are involved, and we are tying it to a specific outcome. That makes it real for people in a way that you're almost getting value right away. In a few hours, you're getting value because -- I don't know the saying off the top of my head, but it's if you plan to a certain level, you're half done. If you've got clarity on what you need to do, you're half done, and that really can drive people past the point of the trough of disillusionment after they're working away and they haven't seen the results yet. It's going to carry them through because not only do they have more clarity on what needs to be done, what things are going to move the needle, and what is going to show progress as they go, they can see the finish line with a lot more clarity.

So I do think that it has a remarkable impact on our ability to tackle larger, more ambitious initiatives and maintain that level of enthusiasm and confidence through the times where this just got a little bit more complicated. It's more complex than it seemed at first, or we couldn't see everything at first, and maybe we have another factor to consider. You want something that carries you through, and the mapping does that because not only does it give you that good starting point, but you can revisit it, and you can plug in new data as you get the data. So you could go from, okay, well, this was what it looked like at the time; we now know that it looks like this. What does that mean? Does that mean we need to adjust the course at all? Does it mean that this is still a good decision? And that can carry you through in a way that if you're just working off of here's what we want, and I hope that everybody's on board, that seems like a gamble to me knowing that the maps are an option.

CHARLES: That actually touches on what I wanted to ask as I was listening to it is what is the average half-life of one of these maps? Things do change. We know that different circumstances arise. So what level beyond that initial investment? You described, I think, about four or five workshops three hours each, which that's a large time investment but probably relatively inexpensive in the grand scheme of things if you don't have to repeat it every two weeks. What is the process by which you tweak these maps? How often do you have to do it? How much time do you have to invest in each thing? Is there a systematic way, or is it just kind of as needed, we make tweaks?

STEVE: That's a great question. And we're going from a situation where nobody has ever mapped before, so basically, anything greater than zero is fantastic. We're in the early days of infrastructure automation, where it doesn't really matter what you do for infrastructure automation. Just start doing it, just something. But in an ideal scenario, what you're doing is you’re mapping or updating your mapping every three to six months. Because what's going to happen is the moment you do mapping, 20% of the value stream is going to pop out to you as things that you can just chop off immediately. You can just remove waste immediately because it's visible. You can see very clear low-hanging fruit opportunities. So all of a sudden, the next day, your process is different, which means that your map really is out of date, but it doesn't matter because it just has to be useful. It doesn't have to be accurate. It doesn't have to be current either. So what you're doing is you're eliminating low-hanging fruit immediately. You've got maybe three to five high-priority prioritized initiatives that you could tackle. Once you knock those off, your value stream is also different, so your map is again inaccurate. But then when you go back to the map, you already understand the process, and your second map, the one that you do three months later or six months later, your team knows how to do it. They're familiar with the process. All of a sudden, your mapping activity is an hour maybe, and that's every three to six months. That's tiny. That's less time than we spend on sprint planning. And I would argue that it's 10 times 100 times more powerful and valuable than that.

So we talk about a large investment of time, but it does get a lot easier, and the Return on Investment is incredible. It saves millions of dollars. It saves months of time. It can really turn a team around from just being buried and fighting fires all the time to having time to spend on experimentation and innovation. So I've never seen anything more powerful in my entire career. So in terms of ROI, it's unmatched. There's nothing that will actually deliver the same impact, especially in a short amount of time, in hours we're talking. There's nothing you can automate that would be that effective, especially when it's telling you what to automate. So to answer your question, three to six months is a cadence where you're going to be capturing current state that is notably different, I would say remarkably different. If you're actually delivering improvements, then your value stream looks very different three months later and three months after that. But you could do it every six months and still be miles and miles ahead of your competition that’s not doing this at all.

TARAS: Did we cover the entire process? I think we might be at the third map, or did we get through all four?

STEVE: Oh, you're right. So capability mapping is the last one, and it's a little bit different than dependency mapping. Dependency mapping is looking outside the value stream at what the value stream depends on or what activities in the value stream depend on. The capabilities piece is inside. So what do we need inside the value stream in order to deliver the best performance? So capability mapping is looking at opportunities to better support the team in areas that are going to contribute to the top priority items to address. So we're not looking at every capability that the team has or that is required for the value stream. We want to focus mostly on the bottlenecks and the gaps, and the risks, and the areas of concern because we don't need to know everything about everything. We need to know where to focus, and we need to know where to invest. So we look at capabilities that are directly tied to the dependencies.

In the case of our example of front end and back end, maybe we are lacking a capability to mark or to leverage skeleton back end capabilities or something that would allow us to decouple and work asynchronously or work in parallel. Maybe there's a tool. Maybe there's some training. Maybe we need to pair. Maybe we're lacking documentation. All these things come out in capability mapping. And it allows us to say, okay, well, this is a hotspot, our ability to create automated tests. We're probably at a six, and we need to be at a nine or above. That's going to give you this extra dimension on those priorities to give you even more confidence even more clarity on how you go from where you are to the next step in the right direction.

TARAS: Are there tools? What tools do you usually use to create these and maintain these maps?

STEVE: That's a good question too. I use MURAL for this because I used to use Whiteboards and Post-its when everything was happening in the real world. But nowadays, any collaborative whiteboard is great. I've used PowerPoint in some cases where that's all I could actually get access to in a client situation. But MURAL works fantastically. Any collaborative whiteboard. . .Google Drawings would work. Anywhere where you can have multiple people participating and working together is more than enough that you need. You're really just building a picture together, and what it looks like is less important than the content, but that's what I use on a regular basis. I've got hundreds of MURAL boards now. I probably spend 80% of my day in MURAL.

CHARLES: It would be great if the entire team could be part of this exercise, but you already said you don't want too many chefs in the kitchen. Once you've established, once you have your maps, how do you go about socializing them to everybody on the team in a way that's not oh, this is just another business tool that I've got to digest as part of my job. How do you evangelize and get that buy-in?

STEVE: That's a great question. There's a number of different ways that you can do that, but I think starting early with that communication plan is really important, saying from the very start, "We'd love to have every single person involved in this. It's just not feasible, and it wouldn't necessarily be valuable." And it's expensive to pull everybody out of their job and get them all in a room. So being very clear about that from the start and then saying that "We can record this entire process, so you can see exactly how it came together, and it will be accessible to people who couldn't participate or weren't able to participate for whatever reason." So it gets historically recorded, and that's adding to that transparency. But we also have the board afterward. The board gets provided, so anybody can go in and look at it themselves, and it can be a living artifact. People can comment on things. People can take the artifacts and the results and remix them in different ways. They could say, "What if we did it this way?"

One thing that we didn't talk about was ideal state maps and future state maps. But you could basically take your current state map and have anybody in the organization remix it into an idealized state. So what would it look like if it could be whatever we wanted? Or a future state, which is what could it look like in six months? What could it look like three months from now? And I think that really is very inclusive and accessible. It just keeps the doors open to anyone who wants to be a part of the process rather than being handed something from leadership that says, "Here's our three priorities, get to work." It allows anybody in the organization to see the map. They can see okay, well, I understand these priorities because I can see the missing capabilities. I can see the dependencies that we're trying to break. I can see the bottlenecks in the value stream, and I can see how all of that is contributing to the outcome that we've all identified that everybody's on board with.

TARAS: It's very interesting. There's a lot to think about and process. Would you be able to share some examples? I'd love to be able to put some on our website so for those who are reading the transcripts would be able to see. We'll include some links to your website in the show notes as well. And I think it'd be really great for people to see an example of these things.

STEVE: Yeah, absolutely. I would love to share some more. I've got an exhaustive end to end case that I call the four by four method, which is connected to the four-door metrics just as a way for anchoring something that people in the DevOps space are really enthusiastic about and paying attention to. The four by four method is basically how do you take the four key maps that I've created and packaged together and link them to the four key metrics as a way of making progress or getting started to improve those metrics? In some cases, how do you get started measuring them? Because a lot of these things either you don't know what they are, or you've got to instrument a bunch of your tooling in order to gather that information, but you can get it from the mapping. So it's an option for people who are really wanting to get started with tracking the four key metrics and don't really know how to do that. Or they're looking at that long time horizon where it's like we're six months from being able to collect this data. This is something that you could do in the week ahead to collect that data and get started.

So I've got the four by four method. I've got an ebook coming out that talks from a team topologies perspective, an enabling team that you could stand up inside of your organization to do these kinds of activities because I think that's something that's going to be coming very soon. Hopefully, in the next five years, every company has an enabling team that's doing this work because it doesn't make sense for me to go around and do it for everybody. It should just be part of everyone's organization, so that's an ebook that's coming.

I've got a real book that I've just started writing with a great co-author by the name of Andrew Davis, and that's going to be about value stream thinking. So, how do we adopt this way of looking at software development and knowledge work and leverage tools in order to get people together rallied around a very clear outcome and then getting ROI from very specific prioritized action items?

TARAS: Well, I look forward to seeing these things come out. We'll share them on our Twitter. So let us know when the ebook is ready, and we'll share it with everyone and same with the book.

STEVE: Thanks.

CHARLES: Thank you, everybody, for listening. Steve, thanks so much for coming by.

STEVE: Thanks, Charles, and thanks, Taras.

Please join us in these conversations! If you or someone you know would be a perfect guest, please get in touch with us at Our goal is to get people thinking on the platform level which includes tooling, internalization, state management, routing, upgrade, and the data layer.

This show was produced by Mandy Moore, aka @therubyrep of DevReps, LLC.

Subscribe to
our podcast:

Listen on Apple Podcasts