Episode 94: Steve Pereira on Value Stream Management

Brian Dawson: Today, I have a conversation that I’m extremely excited about, though I am disappointed I’m going to have to squeeze it into the time we have for the podcast. But what I’m excited about is we have Steve Pereira, the Founder of Visible. More importantly, and I think I’m going to borrow what I believe it says on Steve’s LinkedIn, is the Value Stream Guy.

We’ve had some conversation and there’s a zillion really important threads that we can pull on under that value stream topic. So with Steve here today, we’re going to try to cover as much as we can.

Hello, Steve. How are you?

Steve Pereira: I’m good. Thanks for having me. This is a pleasure.

Brian Dawson: Thank you for joining. We have crossed paths a couple of times in recent months, and what you were talking about was really compelling. So I’m excited to have you on to dig into that.

I guess to get in, so we can reserve some time for the meaty stuff, I’d like to start by asking you if you can give our listeners an overview of what you do today at Visible, this new role and venture of yours, but then if you can also tell us how you ended up there.

Steve Pereira: Sure, yeah. Kind of a quick summary of what I’m calling my work these days is the idea of flow engineering, the idea that we can look at how we are delivering value in organizations as large groups of people in complex environments, and trying to improve that process of creating and delivering value to customers, whether those customers are internal, external. This I find is something that often gets forgotten about because we focus on the technical aspects of engineering. We focus on product. But we don’t often focus on the how, like how does all that come together. What are the ideas that really help give us a boost and get us to higher levels of performance?

That’s what I’m fascinated about. How do we really consistently and predictably improve the flow of value through organizations? That’s what I do with Visible through workshops, through coaching and advisory services. I’ve got a few specific maps that I’ve created that I build out with teams. It really allows them to kind of visualize and measure how they’re doing things, but then reimagine how they’re doing things to get to that higher level of performance.

Brian Dawson: Okay. A real quick question on Visible. How is it going? I think one leading indicator of need or leading indicator of success is have you been able to get work.

Steve Pereira: Yeah. I’ve actually been very surprised by that. When I started Visible, it was absolutely driven by passion and this belief that the future of software delivery and DevOps is in the value stream. It is in rethinking how we see value creation and delivery in organizations.

I had this moment where I stepped back from my last job and tried to figure out what do I want to be doing. Where do I want to be investing the next 10, 20, indefinite years of my life? This idea that an organization is a collection of value streams, and the same ideas that work for software delivery, engineering, delivering value in any context apply universally across organizations.

That just, for me, cracked it open and I realized if I can create a valuable framework for improving performance inside of any value stream, whether it’s software delivery or elsewhere, it can be applied almost universally through organizations. That, to me, is the gigantic opportunity that really gets me excited. But in the short-term, we have so much we can do with software and with cloud migrations, and with helping customers take advantage of technology to drive better outcomes.

So I’ve got my work cut out for me. I’ve always been conscious that this is a very long play. Regardless of where trends take us and regardless of where adoption takes us, I’m willing to put all my chips on it.

Brian Dawson: A less tacky way to phrase my initial question is: are people seeing the value in what you’re offering? Are you finding that people are coming to inquire about Visible and look for the benefits that you all can provide?

Steve Pereira: Yeah. It’s very different, depending on the size of the organization and the stage of the organization. In a lot of cases, with a smaller organization, what they get out of it is that clarity and alignment. Because smaller organizations tend to be moving much faster, much more chaotic, they need to step away and look at how things are going in order to make really good decisions about what to do next and where to invest and what’s happening, and bring everybody on to the same page about that.

In large organizations, they’re usually hitting situations where they’ve hit sort of a stall or they’re trying to level up. They’re trying to take advantage of new technologies and techniques. So the benefit to them is this level of visibility that shows them things that they’re missing, but also, again, realigning, not out of chaos necessarily, but out of a need to innovate and a need to be pulling in the right direction and maybe boost some energy.

A lot of these companies have been through a couple transformation efforts that have not delivered results. They need something fresh. They need something new that’s really going to resonate with both the tech folks and the business folks. I find that the value stream context speaks to both really effectively.

So what happens in these large organizations, where I’m seeing the biggest benefits, the payoffs are much higher. The higher the stakes, the higher the waste, the higher the complexity. People will say, “I’ve been here for many, many years,” in some cases 19 years, and they’re telling me, “This is the first time I’ve ever seen our process end-to-end.”

These are organizations where they’re using safe. They’re using some of the best that the ecosystem has to offer, and they still don’t have the level of visibility that really drives higher performance and these insights that are going to help them level up.

Brian Dawson: Please don’t take this personally, but I’ve got to ask. Is value stream management, value stream mapping just the new fad? I’m going to make my case, and I feel bad saying this to the value stream guy. But look, the idea of value stream mapping couched in Lean manufacturing and in manufacturing overall has lived for a long time.

In fact, I watched very rapidly as it went from this thing that you do, right. Let’s do value stream mapping where it applies. It helps us identify waste, lockers, and then ultimately unlock flow and value. Then, all of a sudden, I went to sleep one night and I woke up and it was a market and everybody is talking about it.

Now we’ve watched the kind of quasi-Gartner hype cycle of DevOps as a term. To an extent, I would argue that I still think overall it’s very much net positive, but I think there’s been times in its lifecycle where vendors and interlopers kind of came in and took over the term, and I would argue inflated it, created a market around it, but sometimes that was at the cost of the original intent.

Now this is op-ed. That’s my opinion. So I challenge you, Steve. Is value stream just another way to sell stuff?

Steve Pereira: There’s a lot to unpack there. I share your perspective on things like DevOps, and it’s a reason why I don’t talk about it anymore. The context where I’m talking about DevOps is trying to transition folks from talking about DevOps in every possible scenario to talking about value streams more often, to talking about value, to talking about flow.

DevOps as a term, it’s so easily misapplied or misunderstood, because very few people hold to the concept that this is just removing the space between dev and ops and it’s no more complicated than that. It gets overloaded and we add things like other roles into it, and we’re expanding the scope constantly.

The beautiful thing about value streams is that you cannot expand the scope too much.

Steve Pereira: Right. It is end-to-end. It truly is what a lot of people think DevOps should be or is. It actually is and it always has been that. I find that in tech what we tend to do is reinvent the wheel because we don’t know a lot of history.

I don't know how many people going through product or computer science degrees have had any exposure to Toyota manufacturing methods or the history of Lean, where all this stuff comes from, time and motion study. A lot of this is over 100 years old and people just discover it as we go, and they discover it the hard way in many cases.

So I think there’s a lot of opportunity to bring back old tried and true methods that have worked in prior context and find out, okay, what works in a modern context, not wholesale cargo culting, bring it in and say, “Yeah, you have to run your software delivery like it’s a factory.” But what benefits can we get by thinking more systematically, and thinking of flow and thinking of value, and then applying what we know about process improvement and automation, so that we stop doing the things that we don’t want to do, that we can easily automate, and have more time to be creative?

A lot of people think about value streams and say, “Oh, you’re just going to make software like manufacturing, and then everyone is going to be working in a factory and hate their job.” But that’s not what it is at all. That’s not even what it was when it was Toyota. Toyota was all about let’s remove all of the manual crap that no one wants to do, so that they can be as creative as possible and they can enjoy their job as much as possible, because they have autonomy and mastery and purpose built into their job, and the value stream perspective gives them that.

So that’s a long way of saying that it is so underhyped that I cannot express myself enough. There are so few people talking about this and it is the most valuable way of thinking in an organization right now.

Brian Dawson: So I’m going to challenge you then again. I appreciate that. So I’m almost sold, let’s say. By the way, I’m playing some alternate character here.

Steve Pereira: I love it.

Brian Dawson: But let me ask now, coming out of the character. Is value stream management something that can be sold?

Steve Pereira: Yeah, absolutely. We’re in very early days of this market, frankly. I think the tooling really has a long way to go before we see the full potential of something like value stream management. But there is such a dire need for end-to-end visibility throughout organizations.

We have all of these teams with all of their own value streams, with almost no apparent or visible connection between them, and our brains make up the difference. We have all this cognitive load that says, “Okay. When they’re done with their thing, then it comes to me and I’ve got to pick it up. Then I’ve got to go back to them because it’s missing some details.”

We lack this end-to-end visibility. We lack this end-to-end visualization and measurement of flow. And the customers suffer. The employees suffer. The company suffers, because we’ve got all these gaps where work is slipping through and waiting and piling up, and we feel it. You feel the friction. You can feel the toil. But you don’t necessarily see it and you don’t necessarily measure it. That means that the humans pay the price for it and I think that needs to go away.

Brian Dawson: Well said. As usual, there are so many threads I want to pull on there, but what I will say, kind of going off of my question, to interject some of my op-ed here, is one of the reasons I ask, “Can you sell it,” yes, you can sell it. In fact, I’ve spent my entire career really in buying, building, training, et cetera, on tools to multiply our capability as humans, but not to replace us as humans.

Something I stumbled on the other day is what we want is – you may have looked into how the – [indiscernible, audio warbles] – they’re building exoskeletons. So instead of building drones or cyborgs, there’s a thought that I really think is akin to what we talk about with value stream management and tooling in the software space or biz space, is it’s really our exoskeleton. We just really want to be able to multiply the powers that you already have.

So I really do believe in tools as enablers, but all too often, and this happened with DevOps and we’ve got to be careful that it doesn’t happen with value stream management, that we sell the tool as the solution. Yes, we need tools for value stream management. Yes, they bring it to bear. They reduce cognitive load in the process of value stream mapping and management.

But to your point, and reflecting back on what I’m hearing from you, we have to deal with the soft science as well. We have to understand the human element. We have to solve for that.

Steve Pereira: A hundred percent. What can easily happen with value stream management is once you have a view into the end-to-end performance of your software delivery organization, it gives you the ability to point fingers, if you want to point fingers. You could target individuals as bottlenecks and weaponize all these metrics that are available to you. So in the wrong culture, it could be detrimental.

The tool is not going to give you the guidance and say, “Don’t go talk to Sally about this. Don’t point out that it takes her too long to deliver her portion of the value stream.” It’s also not going to say, “The reason that’s taking too long is because of eight things out of her control,” dependencies that you cannot see in the value stream management solution right now. You cannot see the meetings. You cannot see the approvals, the SLAs, the cumbersome tooling that’s in place.

That is a gap in value stream management right now. If you really believe that it’s a silver bullet, it will lead you in the wrong direction. So that’s why I’m so passionate about pairing mapping in this collaborative workshop approach of bringing the humans together to map, because you catch a lot of things that are missing in the tools. I don't know when they’re going to be in the tools, but really, if you don’t have the full picture, you can really target the wrong thing.

Brian Dawson: I’ll hark back to what me and my peers or colleagues at the company that sponsors the show have been talking about for the past couple years, software delivery management in just the short plays. Software is a core business function, and software cannot successfully drive business outcomes if your software function operates in isolation. So you need to establish a single source of truth, common data, universal yet bespoke insights, and then you need to arrive at a place where all functions are collaborating.

Now the key thing that I bring up here is some of those are technical entities that you build up, but all functions collaborating. Is it supported by but not codified in a tool?

So I’m going to beg to say to your point – and then I realized we eventually have to – we still haven’t passed question one, by the way, just so you know. We’re going to have to get –

Steve Pereira: We can run a whole series, right. It’s not a problem. I’m here for it.

Brian Dawson: I’m game. Let’s meet afterwards. Look, I do struggle in this seat because as people know, Brian is never accused of being brief or not having an opinion. So it’s always hard. I’ve got to sit back and I’ve got to ask questions.

But look, I think there’s elements of it we should never assume that putting or capturing that information in tools is going to solve the problem. Yes, if you start to look at the whole value stream. Look, you have to deal with things like we’ve got to sell these things. We’ve got to go to market. How are we dealing with things like skewing? What are our different training progressions? How are we analyzing personas and how those deliver?

If you think the downstream delivery, even before we hark back to the upstream, the hypothesis and planning, there’s a lot there. There are a lot of data entities. We can start to capture them in kind of single source of truth and have universal insights on them, but to collaborate the human element is never going to go away.

Steve Pereira: Yeah. We can’t expect that something like value stream management providing us a capability is going to work out any differently than any other tool. Look at something as simple as Slack. That can have disastrous effects on a company if you approach it with the wrong mindset and the wrong behaviors, and it's just a simple chat mechanism.

Something like value stream management that’s surfacing more data than you’ve ever seen before in one place can absolutely pull you in the wrong direction if it’s not paired with a value stream thinking mindset, and understanding of what you should do with all these levers and dials that you now have available to you.

Brian Dawson: All right. So that was question 1a. Now, let’s go back to question 1b. You’ve had a pretty varied career. As I prepare for these and we have crossed paths, so it’s not like we’re completely new to each other as we found out. But you started out really as a – you had an interesting start. Let me not try to blow the lead.

How did you start in computer science? What’s the short version of how now you ended up in this seat you’re sitting in today, founding a company to optimize the practices of and around software?

Steve Pereira: It’s been a long road. I can go back to playing with computers as a child or playing with broken telephones that my dad would bring home from work. He worked for Bell, so he always had something that we would be very curious about. It saved buying new toys, which was a win-win-win. So I was always fixing technology, taking it apart and putting it back together, fascinated with how things work. I think that’s a common thread for me.

I officially got in tech in tech support, answering phone calls, helping people with Microsoft Office, which I cannot recommend. It was great insight into building empathy for customers, connecting tech with people and empathizing. I learned never to blame the person. I learned that the problem is always in the tech being either misapplied or incapable. So I’ve always been team human from the very beginning.

When I think back to there, from another thread that’s been very common, is this idea of flow. One of the first projects in tech support was looking at, just for my own laziness, how do I answer fewer calls? How can I get better results by doing less?

So one of the first things I came up with was a frequently asked questions that we sent out to all of our customers, and we cut the call volume down by 60 percent. To me, that was my first interaction with a value stream, the constraint in the value stream, trying to alleviate and elevate a constraint. I didn’t know it at the time. I had no concept of this.

Brian Dawson: If I’m gathering – keep your place please. Don’t let me throw you off. This was at around 17, I believe, or somewhere around there.

Steve Pereira: I was probably 19 at the time, maybe 19 or 20, so straight out of high school. Actually, a slight diversion into computer graphics, but that’s another story for another time.

Brian Dawson: I’d would love to talk about it. You know I’m a game guy, a graphics guy. I always figured if I had Maya I could be a 3D artist, that the tool would solve my problem, but –

Steve Pereira: Exactly. I was always more obsessed with the tech, mistakenly. I always thought that these tools are so cool, but, at the end of the day, it’s all creativity. What does it let you do? What is it facilitating? What capabilities does it bring you?

Steve Pereira: So through IT management, which is where I got a Lean education, I learned about value streams. I learned about value stream mapping. It went right over my head, basically. I said, “This is super-complicated. It has nothing to do with what I’m doing right now. Interesting, but pass,” and I didn’t stay in that game very long.

Then I moved into building release engineering, which is very flow-focused, very much end-to-end lifecycle. That was incredibly rewarding. Then I moved into infrastructure automation. Then consulting, because I realized some of the things I learned are way ahead of where most people are. So how do I bring that to more people and have a greater impact?

Then I signed up with Statflo, which was an opportunity to go from employee number four through scaling a rocket ship, a startup, learning everything the hard way. I felt like that was necessary to really round up my experience and learn a lot of the leadership things that I needed to learn, a lot of the big picture, high consequence, difficult decision making that I needed to learn to feel like I had the right education.

Then coming out of that, taking the time, taking a step back and thinking: what are the common threads? What are the things I’m really obsessed with that I really want to invest my life in? I was at this confluence of Lean and Agile and DevOps and business transformation, and all of these things came together under the value stream concept for me. It’s a set of techniques that I’d used over and over without even knowing it throughout my career, and learning more about that and what it’s capable of and where the future is, that just caused me to put all my chips on it.

Brian Dawson: Interesting. I love the story. I love the tieback and how support gave you this exposure. I am also kind of seeing that all along with what you were doing in high school, tinkering and then fixing computers and then support, I’d say there’s a thread there that says you were always kind of destined for entrepreneurial work. I don't know if destined is a heavy word or not, but I can see you building up towards it.

You actually triggered for me where I think we have some alignment in that. My father was a mechanical engineer, who eventually was at SGI, but in between was doing computer aided analysis on Blackhawk helicopter rotor vibrations.

On the other side of the house, my mother spent 30 years in health and human services for San Mateo County, retiring as the director for health and human services.

So you’re being my therapist, right. So on one side, I have this really sort of technical engineering-focused thing, and then this really human-focused thing, but my mom’s human-focused thing actually had to also deal with implementing policy to help humans. So it’s very interesting. Okay.

Steve Pereira: I’ve got to jump in on that because my background is entirely similar. My mom was a school trustee while we were growing up. She was a stay-at-home mom, but she had a part-time leadership position as a school trustee. She was passionate about education. She was taking her degree remotely. It took her years and years and years, and she got her degree and then went into teaching. So I’m this mix of teaching and tech, and that’s very much in my DNA.

Brian Dawson: Yeah. Honestly, that’s our other – when we start our whole thing, one of things we’ll talk about is DNA and coding nature or nurture, at some point. That’s awesome, that correlation.

So you recently tweeted that the next level of DevOps is value stream management. You spoke about this at DevOps World Predict. We’ve covered some of that correlation, value stream management being DevOps. But one of the things that I’ve been wanting to ask you in that context is, okay, this is great, but what does value stream management – why does it matter to developers? And when developers think about value stream management – I’ll go as far as to say practitioners. It could be DevOps engineers, application developers, system administrators, but kind of that technical practitioner execution level, why should they care about value stream management?

Steve Pereira: That’s a great question. The first thing I’m going to say is that value stream management is necessary, but not sufficient, just in the same way that DevOps is necessary and not sufficient. The truly valuable and overarching concept that is more valuable than any of it is value stream thinking, the thinking behind the flow of value through organizations, and how that applies to individual contributors, even in the context of value stream management.

It’s really important for all of us as contributors to understand our contribution to the whole. It’s truly valuable for us to understand that what we do matters and it contributes to outcomes. That drives so much motivation. It drives so much satisfaction.

One of the main motivators that we have as humans is a sense of progress. We have to feel like what we’re doing is moving us forward. It’s moving something forward, that we are contributing to something. The potential of value stream management is to give everybody a view into not only their contribution to the whole, but the net effects of what they are contributing to. Customer outcomes show people that there’s activity driven in the app that they’re building because of the thing that they built. That is missing. That’s missing from so many views now in the industry.

But the other thing that’s missing is how individual contributors depend on each other and are affected by and are affecting other contributors in the value stream, which is a huge empathy building capability that is incredibly valuable. So the idea that there’s people before me in the process that are sending me work, work by other people. We’re all sending work to somebody else, and ultimately we’re sending work to the customer. So an understanding that all of this is flowing, and we have to do the best that we can to add value in the piece that we own, but in the service of this larger picture is absolutely critical. It puts all of this into context.

Brian Dawson: Yeah. I’ll try to pare down my op-ed, but I believe a lot of us who are problem solvers, creative problem solvers, want to be empowered with context. We want to an outcome of having an impact. There’s so much there. I appreciate you sharing that. There’s some new insights and a lot that there I am just spot on in agreement with that.

So now speaking to that, what you’re doing with Visible, Some of the work you do is you’re helping organizations get started. So for the people that can engage with you here that are looking at dipping their toe into the VSM, the value stream management waters, what are your recommendations for what they look at first, how they get started?

Steve Pereira: Therein lies the challenge. I think that one of the biggest issues with value stream thinking and material right now, value stream mapping, is that it is closely tied to its roots in manufacturing, which means it comes from fairly complex origins with different focuses than software delivery.

In the world of value stream management, if you take it out of Wikipedia right now, you’ve got factories. You’ve got trucks. You’ve got raw materials like steel. All this stuff does not matter at all to software. Yet, it comes in this package of what people think of as value stream mapping in value stream thinking.

So we really need to create a whole new set of materials for a software context that leaves all that legacy behind because it can confuse the process. We have a lot of education that’s tied to those old methods around Lean, like Six Sigma that is valuable, but it’s a ton of stuff that we don’t need in a world that’s entirely virtual and software-driven.

So what I’ve been doing with material that I create and content that I create is focused entirely on what are the bare minimum components that we need to get value out of ideas and practices like value stream mapping in a software context. What do you absolutely need? And how do we make this accessible to everybody, whether they’re a board member who is just looking at a map for the first time with no context, or someone who just joined the company yesterday?

I want to make maps that everybody can read without looking at a legend, without looking at, “Okay. What does this symbol mean? What do these glasses mean? Why is there a smokestack in here?” All that stuff comes with value stream mapping in the legacy context and we need to move beyond it.

There is new material coming out all the time, but I want to be a part of crafting that message, too, so I’m working on a few things that will coming out over the next little while and then further out in the future. I’m writing a whole book on value stream mapping, the way that I see it in the next 20 years.

I don't want to forget the past. I just don’t want to confuse people with a complex, challenging version of what I see as very simple to get started with. We can go as complex as we want, but I’m a big fan, especially back to my customer success days and my customer support days, graduated complexity. What do you need to get value right now? Then how does that allow you to grow as you get more context, as you get more experience, as you become more capable?

Brian Dawson: Yeah, PLOD or Progressive LOD, progressive level of details.

Steve Pereira: Yes.

Brian Dawson: It’s funny. I was saying something will get to a piece, kind of four quadrants of DevOps maturity, which maps to your four-by-four. One of the things that I struggle with, frankly, that I would underline that you said is simplifying things is hard, to slaughter a Steve Jobs quote, but once you simplify, you can move mountains.

You may have progressive level of detail where complexity necessarily creeps in and needs to be addressed. But just like we focus on with Agile versus waterfall, if you try to solve it all upfront, you know what, you’re going to solve nothing.

So shifting to that actually – well, actually I’m going to stay on that for a quick moment. Hopefully, we can hit it quickly. Recently you had been referencing this change management model called ADKAR that focuses on developing awareness, building desire, arming people with knowledge, and then driving the ability to influence the change, roughly. You could probably argue that I’ve slaughtered that.

So when I think about where people get started, I’m curious if – and think internally in the organizations you’re dealing with or how you engage them externally – how important or what is the role of the A&D, awareness and desire? Do you have any thoughts about where that fits into your view of shifting people to a value stream mindset?

Steve Pereira: Yeah. That’s a big reason why I’ve shifted my attention from exclusively value stream apps to this much more comprehensive portfolio for maps that work together. The one that’s critically important here is the outcome map. In some cases, before that, we’re doing discovery mapping, just to get all the perspectives out, get everybody sharing the same view. But the outcome map I think is critically important because there are many cases in the past where I’ve operated under the assumption that the desired outcome was known and aligned and clear, and everybody was on the same page before we started doing value stream mapping, because the goal is super-critical. It frames what you look at.

It goes back to graduated complexity and that level of detail, because you don’t want to measure everything. If what you care about is lead time, look at time. Ignore quality for a bit. We don’t want quality to suffer, but let’s not analyze it and scrutinize it in detail if quality is not what we’re aiming at or value is not what we’re aiming at or hand-offs, or trying to minimize the number of touchpoints.

You could go down any of those rabbit holes if you don’t know what your desired outcome is. And knowing that outcome and being super-clear about it, knowing where your obstacles are in delivering that outcome is just going to save you so much time down the road. So that’s become absolutely critical. Do not map without doing outcome mapping at this point.

Brian Dawson: Sorry to jump in. It is kind of that move slow so you can move fast. Spend that time. I know we iterate don’t try to solve everything, but what I hear a bit of what you’re saying that aligns – or at least what it triggers in me is you’ve got to get some alignment and buy-in upfront. It’s going to have immense returns as you move forward down this path. Fair?

Steve Pereira: A hundred percent. There is no substitute to that. It’s the equivalent of sharping a saw before you go to work, trying to make an impact in a bunch of trees. It pays off to step back and say, “What am I really trying to achieve? What am I working with? What do I need to do the job at hand?”

These days, you need a team. You need a diverse group of people working together. So common understanding of a desired outcome in what we’re looking at, what we want to achieve is going to drive that desire. It’s going to drive that clarity. You know now by looking at all these failed transformations that clarity is the number one missing piece in all the failures.

Brian Dawson: Let’s double-click now. You talked about the four-by-four methods of DevOps. It is couched in four areas, but also kind of manifested in four additional mapping techniques. I’ll call them out, but then I’ll ask you to explain a little more about the what and why of this.

There is an outcome mapping activity. There is a value stream mapping activity, which we’ve talked about. Dependency mapping, and capability mapping.

I’m curious. Why did you feel the need to kind of define, create, and then ultimately visualize these other maps? Maybe you can quickly run us through what they are.

Steve Pereira: Sure. So starting from outcomes, it’s a piece that you really can’t avoid or you avoid to your peril. Then value stream map, really to me, is looking at what are we doing right now? We’ve got a desired outcome. We have a target. What is the landscape that we’re going to have to navigate on the way to that destination?

So value stream mapping is really looking at: what is the path ahead of us? What are the existing processes that we’re working with right now that likely need to change?

Also, you need space to make these improvements. So another side effect of value stream mapping is you’re going to eliminate waste that you can put towards innovation, that you can put towards investment. Because if you can save one day a week of your team’s time, you can put that one day towards whatever you want, whether it’s delivering more product, whether it’s investigating new opportunities.

That frees up room. That means you don’t have to do more to do more. All of a sudden, you’re doing less. You’re getting more. That starts the wheels turning. That starts you moving in a new direction.

A lot of times when we ask teams for transformation, it’s, yeah, keep the lights on. Keep doing what you’re doing, and do more on top of that. So the value stream map really gives us the opportunity to save some of what we’re doing and dedicate it towards new opportunities. That I think is super-powerful. It pays for itself many, many times over. But you have to start with outcomes.

Following the value stream mapping, what I found was really important was to look at all the factors outside of a given value stream and a given team that we’re looking at, because we not in organizations with autonomous teams. We just aren’t. Nobody has a team that’s an island unto itself, that is entirely able to make its own decisions, deliver its own features on a platform that it owns.

There are dependencies everywhere, whether they are meetings that we have to do, to bring other people up to speed and make sure that we’re not stepping on toes, or getting approvals, or waiting for SLAs, while people have agreements to fulfill part of what we need to deliver our product. There’s dependencies everywhere and we have very little visibility into them. So I thought that it was really important to look beyond the team that we’re looking at, and find out what are the things that could be affecting the value stream from outside.

The other piece is looking at what could be affecting the team from the inside. So the capability mapping is an effort to look at based on the value steam and what we highlighted as opportunities or risks, the gaps in the value stream, the wastes, the delays, where quality is breaking down. What are the capabilities that are going to make an impact on those areas?

Brian Dawson: It could be skills, I assume, but it also could be things like do you have a robust automation pipeline. Is that true?

Steve Pereira: Exactly. I think a lot of people, if they hear capability mapping, they’re saying, “You’re going to be scrutinizing people’s skills,” and that’s not what it’s about at all. It’s about supporting people with the right tools and resources and skills, and proper redundancies as well, that deliver those desired outcomes and address those gaps that we have in the value steam.

So if we were to highlight the fact that our testing or validation takes way too long and we want to drive that down, what capabilities do we have to actually make that better? You can’t just say, “Oh, we’re going to do better,” or, “We’re going to fix this.” What’s actually going to make that happen? What makes that probable? What makes that possible?

So we look at capabilities as, okay, we’ve got three priorities we highlighted in the value stream. The key capabilities contributing to those are going to be what we look at. Then we’re going to look across the team and say, “Does anybody own that thing? Is there a backup for that person, so that they can go on vacation or they’re allowed to be sick? What kind of training does it take to do that capability? Do we have tooling or APIs or documentation even for that?”

You will develop this visibility of no wonder this is a problem. We’ve got super-low capability here across the board, not just skills, but everything contributing.

Brian Dawson: Awesome. There is so much. I’m stuttering because I’m processing a bit how much I want to dig in. We just know we’re going to have to dig in some more at some point later. Honestly, I can’t wait, Steve, till the pandemic starts to die down and we’re actually back at conferences. There’s benefits to the virtual world. What we don’t get is being at DOES, and going down to the secret bar behind the barber shop and being able to talk about this stuff.

Steve Pereira: Right.

Brian Dawson: And work through it, which is enjoyable. The one I’m going to point you to, well first that I loved about this. Actually, I’ll put it this way. I developed and spent a number of years talking about the 4 Qs or four quadrants of DevOps maturity. It was a lot about a very gross way to highlight how different parties needed to be involved, and doing it on one team is different than doing it at scale.

It was well received and I built out sort of a measurement model. What are some vectors that we measure to determine which quadrant you fit it? It was received very well, but it got to the point that it’s like, “Great. Now how do I get into the detail of this?” This big high-level view is great. How do I get into the tactical?

I just want to point that out to you personally. This is a private one-on-one conversation between you and I, not the thousands of people listening, right. I would love to maybe offline dig into that and see where the two dovetail, because I think that this is doing a lot of what that didn’t in a complementary way.

Steve Pereira: Yes. Something I’ve really been passionate about through my whole career, especially with DevOps, is the how. What are the things we can give people that’s going to move the needle for them tomorrow, for the next week, for the next quarter, and throughout the lifecycle? That’s really been the primary focus of all these mapping techniques. You don’t need anything. It’s doesn’t require you have a tool. It doesn’t require you to have anything. You can start with it tomorrow.

You don’t even need me. I’ve shared enough material that people can be doing this on their own. That’s what I think is super-powerful, because there’s so little about the how. We’ve got big, big frameworks that say, “Here’s what you should look like,” but nothing about getting there, unless you want to hire a ton of coaches and cross your fingers. Then there’s tools. And it’s like how do you get the most out of the tool? What is the tool supposed to mean to you?

So all these maps, they actually come together in something that I call a flow roadmap, which is meant to be this layer between your product roadmap and your technical roadmap that focuses entirely on how, because I think the how is where the value is. The how is where the challenge is, which is why I’m obsessed with it.

Brian Dawson: Okay. So we’re going to shift to our standard stuff, so we can get you out of here and solving the flow problem for people. For you, I want to dig into something that I do, Steve, and this is for people who have a pretty wide Twitter presence. I like to bring up their social media handle and dig into the why.

So first of all, for those of you that do or don’t know, Steve’s Twitter handle is @SteveElsewhere, which we’re going to get to that in a minute. His profile description – I don’t even know what we officially call these things – is Value Stream Whisperer @ Visible. I think we get that. Forbes 10B under 10B. Marie Kondo of automation.

So we’re going to hit a few of those, just quick like of lightning. SteveElsewhere, why?

Steve Pereira: I think that comes out of me traveling a lot for work and conferences and always being on the road. I always felt like I was in a different place. Especially with Twitter, you can reach people regardless of where you are, and I always kind of like that. It’s always a user name that tends to be available.

Steve Pereira: You’ll find me at @SteveElsewhere or @SteveSomewhere, and that tends to work out.

Brian Dawson: Okay. So anywhere you will find me at @SteveElsewhere or @SteveSomewhere. And because of time, I’m going to jump to the Marie Kondo of automation. I’ve still never watched that. So who is Marie Kondo and why are you the Marie Kondo of automation?

Steve Pereira: Twitter is me being goofy all the time, but for me, Marie Kondo is looking at what you’ve got and really being intentional. Her whole thing is trying to get people to declutter, right. Get rid of junk. Focus on what is really bringing them joy in their lives.

Something that’s super-common with DevOps and automation and technology is people are constantly parroting this idea of automating everything. I see that as just accumulating a bunch of crap that we don’t need. It’s not tied to value. It’s not tied to what’s actually delivering the highest return, and it’s not informed by any kind of specific requirement. It’s not prioritized.

I see that as wasting tons of time and effort, and I’ve been in that camp. I’ve tried to automate things for the sake of automating. It’s a bad scene. So I want people to be –

Brian Dawson: Pursue what makes you happy, right.

Steve Pereira: Pursue value. Exactly. So instead of automating everything, automate the things that drive the most value. Really be intentional about things like automation, because it does not come for free, and it is always at the cost of something else that you could be automating. Priority matters and value matters.

Brian Dawson: Awesome. I’m glad we picked that one to dig into. I’m going to shift you to another, a DevOoops. We love to hear what people’s DevOoops moments are. I’ve got this down now. Not DevOps, but DevOoops, asterisk, asterisk, asterisk, Dev-O-O-O-P-S.

Really, what this is, is usually a technical or software development challenge that you have experienced in your career that may be even embarrassing to share now, but it offered you a lesson and it offers a lesson to our listeners. Do you have a DevOoops that you can share with us?

Steve Pereira: Oh, a hundred percent. It’s something that I think came up many times in my career as an individual contributor, just the idea, and it dovetails with what we just mentioned, this idea that all automation is valuable, and trying to engineer solutions regardless of an awareness of the value, awareness of the context, awareness of the customer.

I find that a lot of folks in engineering and technical roles, and this is my history, is trying to deliver what I thought was valuable in a given context, without awareness of the big picture. The pain of building things that ended up not being valuable or ended up being counterproductive or wasteful.

Brian Dawson: I’m going to squeeze you a little bit – not to discount that answer. I love the answer, but to help it stick, do you have an anecdote? Is there a –?

Steve Pereira: I was working for a company was doing financial services, a financial services SaaS company. We were working on infrastructure automation. I was focused on making developers’ lives easier. I was building developer infrastructure on Vagrant. So we were spinning up virtual machines. I would be building them out with Vagrant and Packer and Chef at the time.

I had spent tons of time trying to get this perfect, so that it never had any errors, and you could throw it all kinds of different parameters and it would build out whatever you want. I’m just working away in isolation. I’m super-happy. I think I’m doing a great job.

Meanwhile, it’s taken weeks and weeks to get this thing right. And if I had just stepped back and talked to all the engineers in the organization or even just a sample greater than myself, I would have realized that the real pain point, the real desired outcome, the real value that they were looking for was just to shave off a few sharp edges. Just help us – if we have to tear this down, just shave one step off or the most painful piece.

If I had looked at the value stream of what does it take to stand up a developer workstation or a developer environment, these are the worst aspects of that. These are where the bottlenecks are. I would have been there in half the time. I wouldn’t look like an idiot for building something that people don’t need. And I might have hair right now, to be honest.

Brian Dawson: That is great. I wish I could dig in. Thank you for sharing that anecdote. I think that that’s very transferrable and powerful.

All right. We’re going to shift you to this. What is a resource, a book, a podcast, a blog, maybe it’s a personality on Twitter that you follow that has been very valuable to you, and you absolutely encourage our audience to go out and acquire or follow or read right now?

Steve Pereira: That’s a big ask.

Brian Dawson: You can give two. We’ve had people throw three in, if dwindling down is difficult.

Steve Pereira: To me, I’m a man of diverse interests. So I’m thinking of things like political podcasts that I love, and VC and startup podcasts that I love.

Brian Dawson: That’s fine, yeah.

Steve Pereira: Really, I’ve been kind of blown away by – there’s a recent podcast, for instance, by a16zed – or a16z to you folks. That’s Andreessen Horowitz. There’s a VC firm and they run a podcast.

They did a tour of – basically, a tour with the CEO of Moderna about their vaccine development and deployment, which was fascinating. I recommend it to anyone who is curious. I think it’s very timely, but it’s also a lesson in innovative thinking, new approaches, everything from supply chain to thinking of how do we use the latest techniques, the latest ways of thinking to change games, and really leverage a lot of huge opportunities that we have with tech by rethinking the way that we do things. So I thought that was pretty fascinating.

In terms of value stream resources, there’s a great e-book that I always recommend by Jeff Keyes, who is at Plutora. He does a really good run through of value streams and value stream mapping. Hopefully, I can build a more complete resource with the book that I’m bringing out, but that’s a fantastic starting point and I recommend it a lot.

Brian Dawson: Okay. I do apologize, Jeff, now that I know, for calling you Jeff Keys [ph.] because Steve pronounced your name correctly.

Steve Pereira: It does happen. It happened to me.

Brian Dawson:But Jeff never called me. I’m going to take you to final thoughts, but I can’t help – I had my vitamins today, so I have a lot that I want to share in addition to asking questions. But it’s really key when you talk about the vaccine makers because it is very transferrable. We talk about we have to achieve speed while maintaining quality, so we can capture market opportunity.

We have to be very metrics-driven, even get words, right. You can’t compromise the science of this. You can’t compromise the data-driven development. But you have a small window that you’ve got to try to hit and you’ve got to get there in – I don't know what it was, a tenth of the time that you normally would.

You just triggered something in me in that, so I look forward to actually hearing the podcast, but also seeing what other literature comes out sort of analyzing how the companies brought this stuff to market.

So, Steve, it’s been awesome. I think, as we suspected, an hour was not enough time, but I think maybe enough time of our listeners’ ears. So to send us out, do you have any final thoughts that you want to leave the listeners with?

Steve Pereira: Yeah. I’m really excited about this space and where we’re going with visibility, and our ability to recognize the contributions of everybody in an organization in delivering value. I feel like that’s very powerful for individuals, companies, and customers. It’s really going to bring us to a new level of empathy and understanding and contribution that I think will be really motivating.

If you can see how you’re involved and you’re part of this value delivery process, whether you’re in sales or marketing, or in success or in software development, you’re all on the same team. Your organization is just a collection of value streams. Some of them are more customer-focused than others. Some of them are closer to the customer, but they all contribute.

So the more we’re able to see that and understand that, I feel it’s very empowering. It’s very encouraging to me. I find it energizing.

People who leave workshops that I run, they come away with this appreciation, not only for their own jobs, but the jobs of their coworkers and their colleagues and people that they’ve often never sat in the same room with or met with. They realize that they depend on each other and they’re all part of the same team. So to me, this is about much more than delivering software. It’s about having fulfilling careers and really feeling the craft of our jobs.

This is why I get so passionate about this and I’m happy to talk about it forever, and I will never stop talking about it because I just think that it’s ultimate goal, regardless of where technology takes us. It’s a big reason why I’m looking beyond DevOps these days, because I see this as just the ultimate. This is the big, big picture and the big thing that really drives value and meaning and purpose and fulfillment these days and into the future.

Brian Dawson: Well, Steve, thank you for those thoughts. Thank you for this conversation. I wish you the best success on this mission that you’re on, and I look forward to speaking to you in the near future. So you have a good day.

As we wind out, which I fail to do often, I do absolutely want to thank CloudBees for sponsoring this podcast and giving us this platform to share these valuable insights, such as Steve Pereira has for us, with the larger community.

Steve Pereira: Thanks, Brian.

Brian Dawson: Thank you and bye.