Steve Pereira - Flow Engineering
Steve Pereira is the founder of the value stream consulting company Visible which helps boost productivity and efficiency of its clients' teams through a framework called flow engineering.
In this episode, we diver deeper into the concept of flow engineering, exploring how it compares to similar approaches such as Agile and DevOps, and taking a closer look at value stream mapping which is a key component of flow engineering. Steve explains how he arrived at this specific approach and why it is so well positioned in the fast-changing digital environment in which we're living today.
Links & mentions:
“We have to back the car up to the fork in the road where we went down project avenue and change direction and start going down product avenue or value stream avenue to be more specific, and when you start thinking in terms of value streams, all of a sudden, your boundaries have expanded considerably.”
Welcome to the Agile Digital Transformation podcast, where we explore different aspects of digital transformation and digital experience with your host Tim Butara, content and community manager at Agiledrop.
Tim Butara: Hello everyone, thanks for tuning in. I'm joined today by Steve Pereira, founder of the Value Stream consulting company Visible. Steve is going to talk to us about a framework that he's developed called Flow Engineering which can help businesses drastically improve their bottom line by streamlining essentially every part of the software or product development process. Welcome Steve, it's great to have you with us today on the show. Should we add anything to the intro or just move to the questions?
Steve Pereira: No, that was super generous, thank you Tim. I really appreciate the chance to have the conversation, I really look forward to talking about this stuff and bouncing these ideas off people and getting feedback so, I really appreciate the opportunity.
Tim Butara: Yeah, same here. I think we're in for a good conversation. Judging from the initial talks that we had around this, I think that we already covered a lot of interesting stuff. So, I think this episode is going to be a great one. So, I'll start with a basic thing because we're dealing with concepts that may not be familiar to all listeners. So can you start off by telling us a little bit about the basic concepts or key elements of flow engineering?
Steve Pereira: Sure, my career and really I mean before I even started working, I've always been obsessed with optimizing processes. That's what I do to procrastinate or when I get obsessed with something that I have to do on a regular basis, I try to tune it as much as possible which is why I wear the same t-shirt every single day and there's a bunch of other ways that this manifests itself but it's been happening since I was a little kid. And as I started my professional life I first worked in tech support which is very process pipeline driven. You're dealing with a big funnel and you've got to crank out all of this positive outcomes solving people's problems as quickly as possible, and then I moved into build and release engineering, systems administration, IT, management all of these very funnel based progressive flows of work and information and always trying to tune and optimize for my own laziness, right?
I got a big batch of work to work through every single day. How do I do that without grinding myself to burnout or just hating the work? And so this concept of flow and this concept of optimizing the end-to-end delivery of value essentially became this obsession of mine. And I discovered value stream mapping much later in my career but probably about five years ago in a software context - I learned about this at college doing a certificate in information systems management but in the manufacturing context, the traditional value stream mapping - and I didn't see a lot of applicable value. I did my own sort of like process mapping to try and tune things and really as DevOps arose and became this thing for optimizing software delivery, value stream mapping started to come up as, okay, well here's a tool that really works exceptionally well for this use case.
And by digging into that and looking at the opportunities that it presents, I started to see that, okay, well if we boil this down and get rid of all the six sigma lean heavyweight traditional manufacturing things and focus on the 20 % of value stream mapping that deliver 80 % of the benefits, then we really have something that can work exceptionally well for software development. And so I started to apply it to everything from onboarding new customers to looking at support workflows, incident management - anywhere that we had this sequential process, and the messier the better, right? The more complicated, the less it was understood, the more people were upset with the performance of the value stream, the better it worked and so I just fell in love with this because I could hit everything with this hammer, right, and we'd love to have hammers that we can hit everything with, it's like the greatest thing in the world as a tech person.
So, I went down that road for a long time and then leaving Statflo, my last gig as a CTO, I looked back on my career and I was like, okay, what do I want to do now? I don't want to join another company. What am I going to do if I start my own company? What is the thing that I believe in more than anything? What do I feel is a gap that needs to be filled? And so, this idea of value stream improvement was the thing that just kept coming up over and over again. I looked at the threat of my career and the threat of my life and it's just there the whole time. And it's something that almost nobody is doing on a regular basis. And so, I just see this giant gap between what we know works and what we're doing on a regular basis, and it's the same as a lot of places where see, like, we know what we should be doing, we just don't really know how to start and it's not easy enough to start.
And so, I've dedicated Visible to narrowing that gap between knowing what we need to do and making it easy to do that thing. And Flow Engineering is the kind of packaging of not just value stream mapping but multiple different mapping techniques that bring a team together, bring individuals together, get all of their understanding out of their heads and shared among everyone so that everyone can truly understand what's going on and where we want to go. And I feel like that is a missing tool; Flow Engineering is just a term that rolls off the tongue nicely that people tend to like because they like engineering. We have all kinds of different site reliability engineering, we have all kinds of trendy areas that have arisen out of the DevOps space. And so for me, flow engineering is part catchy title that I know people will pay attention to, but also this way of expanding the view beyond just value stream mapping.
It's not just value stream mapping, it really is a holistic start to finish process of looking at outcomes. First of all, being super clear about what we need to do or what our biggest problem is, then looking at the value stream and then looking at dependencies and then looking at capabilities. So, this flow that takes you from everything that you could possibly be worried about, to a flow of value that's going to deliver an ideal outcome and then looking outside the flow for what is possibly affecting us from outside of this value stream, and then inside capabilities is what's affecting us from inside the value stream and it really builds out this holistic picture, this high fidelity, high quality picture the teams build themselves, so they're like super invested in this because they've been a part of creating it.
And that to me is addressing this gap that a lot of teams have where maybe one person feels like they know what's going on but everybody else is like, I come to work every day and I pull something out of Jira and I work on it, but I really don't know where this is going, and I don't know if I'm making a difference, I don't know if I'm making the right decisions, I don't know if I'm heading in the right direction. There's so many ways that this gap in understanding and shared visibility, what I call perception alignment right, the things that we understand or we feel like other people should understand but they really don't and we all have different opinions about where to focus, what we're doing, what's going to make the biggest impact in our productivity and our performance.
I wanted something that will check all those boxes and make it fun and easy because I think, heavyweight frameworks, big demanding wholesale changes, transformation efforts are way too much and then you have, on the other end of the spectrum is just like rough guidance, like follow these principles and values. And there's nothing really in between that says, 'if you do this today you will get a very positive outcome' and you can do this with very little training or experience. The goal is to make it accessible and fun and productive so that you can see value really quickly, that was just a huge gap that I saw in the DevOps space especially.
Tim Butara: Yeah, it's good that you mentioned DevOps actually because I noticed a lot of similarities with frameworks and concepts and approaches that have emerged in the past few decades maybe, so, stuff like Agile, Scrum, DevOps. So, how does the framework that we're talking about today, so flow engineering, compare to or maybe perhaps in what ways does it differ from these better-known frameworks?
Steve Pereira: Yeah, I think that a lot of those frameworks, methodologies and beliefs, they're very broad which is great, it means that people can interpret them how they like and take the valuable pieces and interpret them in the way that will apply to their situation. But in reality, that doesn't happen, right? In reality people point to a company and they say, 'we want to be like that company. We want to be more like Netflix, we want to be more like Google or Amazon' and in reality, you cannot be like anyone else, right. We know this personally. It's true for teams, it's true for organizations, it's true at the macro and the micro.
And so frameworks have a limited value. And they have even less value if they're prescriptive, if they say you need to do these things. Things like Scrum where it's saying you have to perform these rituals, it's great for a team that has nothing, right. If they're starting from scratch, it might be too heavy, it might be beneficial to start with less and maybe just once a week let's check in and see how we're doing and then make some decisions on what to change. But in some teams, that level of structure is valuable.
It's very hard for a team to say, this much of Scrum is going to work for us without a ton of trial and error. So, you have people with partial implementations and they're partially Scrum and they're partially Waterfall and they're partially Agile and they've got a little bit of DevOps in their environment. Flow Engineering really is about-- it's an assessment opportunity to step away from your work. It's not saying work a specific way, it's giving you a retreat from your day-to-day, from the way things are going, and giving you tools to have really productive discussions with your team about how things are going and where should we be headed.
If we're headed in the right direction, great, we're going to feel a lot better about where we're going because we will have proven it to an extent, we will have demonstrated that and that can help with confidence of a lot that you can lean in further, you can maybe even speed up if you feel like you're-- everything is working and we've validated that and we all feel more comfortable now. But most often, teams feel like things aren't great but we really don't know what to do, right, and we don't want to run a hundred experiments before we figure out what's going to get us out of the state that we're in or help us to perform at a higher level.
So, the tools are really just mapping exercises to get a team to pull those perceptions and assumptions and information out of their heads and reconcile it with everyone else so that we can all be on the same page. And that means that you're going to be more effective with whether you are doing an Agile transformation or trying to optimize Dev and Ops collaboration or move to Kanban or get more out of Kanban or do whatever you want to do. It really is just an enhancer, it kind of is a catalyst but also a way to really accelerate things that you might already be doing in a more productive way. It can draw you out of the status quo if you're languishing, if you feel like you're stuck, but it can also take a high-performing team and boost their performance by challenging them in ways that they haven't been challenged before, surfacing discussions and showing them things in a new way that spark ideas and energy and motivation.
So, there's a lot that you can do with it, it is not something that prescribes anything and you don't even have to use the maps that are in flow engineering, like, impact maps are a fair substitute for outcome maps, event storming is a fair substitute for value stream mapping and depend-- there's a bunch of different ways you can do, dependency visualization and mapping, you could use worldly mapping instead of dependency mapping capability mapping, you can use a maturity model, you can use capability assessment, there's all kinds of ways you can do that. Flow Engineering is just my idea of the simplest way to do these things.
And that's what I find really often missing is sort of like a simple default that says, 'if you don't want to use the default go ahead and swap it with anything else'. As long as it's doing these things, as long as it's accomplishing these goals, it really doesn't matter what you use. And that, I think, is a rare commodity and the framework world is the idea that, here's a simple default but you can override it. We all love that in programming, we all love that in technical frameworks, the ability to swap out components if we find something that might serve our purpose better, but that often doesn't happen in the workflow world. I mean if you look at SAFe, they're not saying, 'well use this if you like, but like here's a bunch of other stuff,' I don't think that that conversation is happening.
Tim Butara: Yeah, it's not so much "either-or" but it's something that can work in tandem with whatever existing processes you have, basically just taking the basic concepts. And I like the distinction between descriptive and prescriptive because I come from a linguistic background, and you have such a thing as the difference between prescriptive and descriptive linguistics and I suspect that it's something similar with these frameworks. So, it's nice that you can have this framework that's kind of derived from itself and it takes the best features of all the other attempts of streamlining these work processes. Yeah, I just really dig it and I dig the title and everything about it basically.
Steve Pereira: Awesome.
Tim Butara: Yeah, just for anybody listening right now who maybe isn't familiar with some of the terms that we're using, I think we'll link all the relevant info in the show notes section with the episode, right?
Steve Pereira: Absolutely, and there's an entire eBook that I put together recently that goes through the entire thing from start to finish, including frequently asked questions because there's a lot of stuff that I haven't written that really, is just like, what about this? Well here's the quick answer to that, to avoid writing a massive book, I just wanted something that got the ideas out so that people could come back to me and say, 'well that's silly, like, I already have this thing' or 'this doesn't make sense to me.' That's what I want When I put something out into the world, I really want that feedback to highlight where I've made an assumption or my experience doesn't echo other people's experiences. Part of the value of mapping for me is I get it out, talk about it and then act on the feedback. So, that's very much how I try and run everything.
Tim Butara: Yeah, I just wanted to say that it's perfectly in line with the ethos of flow engineering, right? This being open to feedback, basically staying flexible, staying adaptable because I think it would be ... dumb almost to not take new information that you get into account, right?
Steve Pereira: Totally, I mean that'd be unbelievably hypocritical of engineering to not be adaptable, a 100%.
Tim Butara: I think that we stayed very general and we didn't really dive into specifics. Can you maybe give us some practical examples of the business benefits of adopting this approach that maybe you've seen during your work?
Steve Pereira: Yeah. So, I think that one of the major ones is that a lot of organizations are moving from project-centric operating models to product-centric operating models. So, we're aiming for more flow inside of organizations, we're trying to achieve higher levels of flow especially in software development because, Agile and DevOps and extreme programming, all the origins of the way that we build software came out of projects, they didn't come out of flow.
We started under the assumption that software was different from work of other kinds, right, even knowledge work of other kinds, and that everything would have a life cycle because we were shipping packaged products to people through the mail, you know, we didn't have continuous online operations. So, flow wasn't really a part of software until very recently. And because of all that legacy in the project world, now we have to reevaluate the way that we even think about building software and Agile was a step in the right direction, DevOps is a step in the right direction. But because they're built on the same foundation, some things don't really work that well.
You know, if we were coming from lean and we were coming from where manufacturing got to at its peak of performance and productivity and said, 'okay well let's borrow the best of that, borrow the best history of how we build and ship and deliver value over into the software world,' then we would have been here already, we would have been here probably 10 or 20 years ago. But it's slow, we're slow in adopting lean principles and the way that we think in terms of delivery and Kanban is now becoming something the teams are considering after they struggle with Agile and they struggle with Scrum and these different other frameworks, but a way to make that easier is in challenging our understanding of, what are we really trying to do?
We have to back the car up to the fork in the road where we went down project avenue and change direction and start going down product avenue or value stream avenue to be more specific, and when you start thinking in terms of value streams, all of a sudden, your boundaries have expanded considerably. So, instead of agile being software centric, so build and release, you have DevOps which is a little bit bigger, so you have to build, release, deploy, operate, and monitor and mitigate failures.
So you've expanded here; the value stream expands it to the real boundary, right, and that is a paradigm shift, that is a big change. Because all of a sudden now sales might be part of the value stream, marketing is certainly part of the value stream, success, support, all of your portfolio planning that happens way upstream, way before agile even starts to be a consideration is now part of this and all of these value streams are flowing together because you don't just have one product, you've got portfolios of products. They all leverage common infrastructure and capabilities, they all use some of the same marketing resources, they all use similar assets, there's design libraries that are shared across all these flows. But now your design system is its own product and it has its own value stream and there is an internal focus and an external focus and all of this is more complex than we ever imagined, but that's reality, right, and we have to confront reality if we really want to make a difference. You have to stop pretending that things are not the way that they are.
So, for me, flow engineering is this opportunity of stepping away from where we are, reconsidering our surroundings, using maps, so taking, okay, here's what I understand, here's what I understand, all of these different opinions from people across the value stream, building that map of the current state, what does this really look like if we all put our heads together? What does this look like? What decisions should we be making? And how should we be making these decisions?
That takes mapping and the act of mapping is the most valuable part of that, it's not even you could throw away the map at the end and still get tons of value from this because it's that pulling information and knowledge and perception out of people's heads and mashing it together, that gives you this huge change in the way that everyone thinks, that everyone sees the work and their teams and the place that they're in the organization. And that just lights a fire in people, and it can resurrect a team that is full of animosity and friction and challenges and really give them a fresh start. That's a beautiful thing to be a part of, that's the thing I love most about the work is that you get to be a part of this whole change that is showing people that it's really not as hard as we thought it was, but the possibilities are much bigger than we ever imagined.
Tim Butara: I love the point about being able to discard the map at the end if you undergo the process of mapping. It's like one of the best advice that my dad ever gave to me, like, he said that he always made cheat notes for exams and whatnot but he never used them because, he had so much value and he had to learn the material so deeply and so thoroughly to be able to make a proper and like an effective cheat note that he was able to just make them and then not use them and ace every exam basically.
Steve Pereira: 100 % and we know this, we know this from journaling, we know this from taking notes. We never go back to our notes, we never go back to our journals, that's not the point. The point is not to have something tangible, it's the act of taking something in your head and getting it out of your head that's so valuable. And it's about time that we brought that to software and we brought that to collaboration because we've been doing it as individuals for so long, but we don't do it as groups and that's a 10x, 100x opportunity because it's, really is the difference between all pulling in different directions and all pulling in the same direction.
Tim Butara: When you really think of it actually starts to make more and more sense, and it starts to become one of the only things that makes sense because let's face it, we're living in the world of the digital now which is completely different, the pace of everything, the world of software is unlike anything that we've ever known for basically the entirety of human existence. And we cannot expect to achieve the same level of success that we've been used to or that we want to, with the techniques that were basically effective in a totally different world, right? So, I feel like flow engineering is the mindset that you need in order to thrive in this really digitalized 21st century, this period that we're kind of heavily transitioning into now.
Steve Pereira: 100%, and I think that, that is the point. It's not about the maps, it's not about what I do in what I call flow engineering, it's really this gap between what we want to do and where we are and not having a how. We're just missing this focus on how we do things, how we do the work. Ways of working is now becoming something that we really focus on and a lot of people are obsessed with this idea of ways of working, but what does that mean? I think that's too broad to be very valuable just in the same way that DevOps was too broad and was really confusing to people. I think we run the same risk with something like ways of working or transformation of any kind. It's just too broad.
So, I think what I really want to see from flow engineering is: here's something you can do tomorrow with your team and you can extend it as much as you like, you can do different types of mapping, but this, it's a very easy way to address that how, like how are we doing any of this stuff? By what method? One of my favorite phrases of all times, "by what method", like what's-- how are we actually going to do this thing? We spend a lot of time on what we want. We've always got that north star. We have a huge product backlog. We can come up with ideas all day, but what's actually going to make any of that happen? That gets so little energy and attention people just say, 'well, slap some Scrum on it and it'll get done sooner or later,' but who knows how well you're doing Scrum? You're going to have to step away and assess that.
And I find that a lot of teams have these methodologies and these frameworks and they're following them or they think that they're following them, but there's enough ambiguity between having a retro and having a productive retro. There's a huge gap and it's very easy for teams to say "yeah, we’re doing it, we're not really getting a lot of value from this or it hasn't changed us, we're not performing at a higher level, we're just slowly getting better". I think what I'm looking for is those Pareto moments, what is that 20 % that's going to give you 80 % of the value? What is that one thing that's going to 10x your performance?
That's what I'm obsessed with, because then it really doesn't matter what you're doing on a daily basis because if you can step away and level up instantly like or in a matter of hours, then you don't have to worry that you're slowly getting worse or that you're not improving, because you always have something that can boost your performance with very little effort. At the same time, your team comes together and you do, you feel closer and you might be able to reassemble your teams based on something that's actually going to make a difference, rather than like shuffling around people on the org chart because you think that, 'oh! well what if we just put these people together.' Why are you putting these people together if you don't have a value stream? If you can't see your value stream, then how are you making decisions on who works with who? It's just arbitrary or we're just guessing.
Tim Butara: Yeah. Basically, if everybody works with the end in mind and being aware of the whole process, basically every stakeholder for a specific process, project, whatever, product that's when this thing can really work, right?
Steve Pereira: Well, that's when you know that something is working because you can feel and measure and see the flow. Otherwise, you don't really know how good it could be and I think that's a big thing. We're worried about not getting worse or not wasting time, but we're not usually aware of missed opportunity and missed capacity and capabilities. So, how much could we be doing, how much better could we be if we looked at this a different way? If we measure it by a different yardstick, if we saw the big picture.
Tim Butara: Also, it often happens in these kinds of projects and processes that you have to make compromises, right. You have to make, okay, we have to work longer so that the product will be better or maybe we have to silo a bit so that the process can go easier; but if I understand it correctly with flow engineering, you can basically apply it to any part of the process and improve any part of the process and it doesn't need to come at the expense of another part of the process. You can have that better collaboration and you can be faster and you can use better tools and yeah, it's just an all-around benefit.
Steve Pereira: Yeah, it's, when you put it that way, it sounds too good to be true and I hesitate to paint it with that brush. There is no silver bullet and I will throw a big asterisk and caveat on it but, what I really see as the opportunity is, a lot of organizations make these choices about how they're going to change things when they won't actually see a benefit for months and there could be a massive cost in both morale, productivity and money. If you're choosing, we're going to do this thing, we're going to adopt this framework and it comes with a bunch of certification and it's hugely disruptive. I mean, you've got storming and norming and all these like transitionary periods of implementing a new structure by dropping a cookie cutter on the organization and saying now we're going to do this, we're going to operate this way, it's not driven by the teams, it's like a top-down mandate thing.
Then you're so far from recognizing the benefits and then when is your expected ROI going to factor in? When are you going to see the benefits? I don't think anyone ever measures those; I don't think anyone ever measures like we expect to see a 30% increase in performance after six months. Nobody's doing that, I mean maybe the best performing organizations in the world but they're not the ones who implement these frameworks. So, it's like it's a double whammy because you have teams that are implementing these heavy mandates from the top down and they're not measuring the outcomes so, you're just-- you're getting it like all this-- problems from everywhere multiple problems and you're just going to react by trying something else. With something like the approach that I am suggesting, you will see a benefit while you're in the workshop, while you're actually doing the thing, you'll see the benefit. And that instant ROI, for me, it's a totally different value proposition. All of a sudden, you don't have to wait six months to find out that we're actually worse now, we have more problems than ever before.
You're going to see this improved clarity right away, you're going to see this improved morale, you're going to see improved engagement and if you don't, you're going to surface a lot of things that have been hidden below the surface for a long time. So, even if things are bad, you're going to see how they're bad and be able to steer that in the right direction, but that happens instantly and then it's carried on for six months and then you can do it again. But you're getting the return on investment right away which I think is very rare right because when you try to change your ways of working you don't usually see a benefit in the short term, you're usually see disruption in the short term and then things level off, but you probably don't remember how things were before and you weren't tracking any metrics.
So, how are you going to know that you made the right decision and whether to lean into it and do more? Expand your pilot, go beyond-- if you are doing this as an experiment with a pilot team. How do you know when it's time to scale it up? Or what we should change? Or where we should adjust? I think these are all like cons and pros and why this focus on ways of working is such a big deal right now is because we're starting to realize, we don't really have great answers for this stuff.
Tim Butara: So, to tie everything that we've talked about because I think we covered a lot we covered a lot of insightful points.
Steve Pereira: I certainly did, you let me ramble forever. So, I appreciate that but I also apologize.
Tim Butara: I know that you're so knowledgeable on the topic, I mean you did come up with it after all, I know that you could have talked even longer so I was like, okay I know that probably everything that I think of you already thought of and you'll mention it a bit later if I just let you talk.
Steve Pereira: Oh, that's being very generous. I mean, in reality this is a bunch of stolen and borrowed techniques and practices that I've adapted to just make as simple as possible. I really didn't invent any of this stuff and I've discovered it over a long time of, I'm just going to add this one little thing to it, and you know that works and I see that, but the way I think about it is a little bit different, so let me just add this and it's going to incorporate what I like about that, what I see works but it's going to be a little bit different to try and be maybe even a little bit simpler and maybe just to attach a little bit cleaner or tighter to this other piece of the puzzle. So, all these things like outcome mapping and dependency mapping, they all exist elsewhere. I can't claim that I invented any of this stuff, but I think packaging it is valuable so that it's easier to talk about and it's easier for people to say, 'oh! I'm going to try that thing,' because, instead of, go try a bunch of stuff and see what works for you, that's not great advice, right?
I like, here's a suggestion if it doesn't work for you feel free to tweak whatever you like, if it doesn't appeal to you use the parts that you like, but I think this like here's a menu from like a typical Chinese restaurant that has 300 items on it, like, you just stare at it forever and you can't make a decision. I don't want that. I want basically, like, this is the best place in the world for this specific dish and you can ignore everything else on the menu but, like, we know this is great so, if you're interested in that then this is, this is for you. I'd rather have that scenario. I'd rather take the best of many different things and package them together in a very clear and simple framework that people can use today, you really can use, like, you can read the book in I don't know 20 minutes and you can pick one of the mapping exercises and do it with your team. You can even do it on your own and it really just helps just like journaling, just like writing notes, it's just pulling stuff out of your head and letting you see it, which I think is, it's missing, we don't do it enough.
Tim Butara: So, I can't really assume that you have one major piece of advice for anybody listening right now who maybe isn't sure how to get into this, how to start implementing this. If you had to say, like one major thing or a few major things to these listeners what would your advice be for them?
Steve Pereira: I think for me it's very valuable to just step away from our work, it's very easy for us to get so into what we're doing on a daily basis that we forget to step away and wonder, how is this going? Is there something that I'm missing? And just asking the question, is everyone that I'm working with on the same page? That is where to start really, because if the answer to that question is not yes and I bet it's not, then there's something that you can do. And I'm not suggesting that flow engineering is the thing you should do, but that's the idea. The idea behind it is, step away wonder if you could be more aligned with the rest of your team, if you could understand the big picture and the flow of work and information better, then this is a thing that you can use that will not take you six months to figure out or to see the benefit from. And, you know, best of all it works remotely, it works over Zoom and a collaborative whiteboard, like, all these things that everybody has and everyone is used to working with by now.
So, I think that there's very little reason not to do something and that's really, I would just encourage people to do that, step back and wonder how much of this do I really have figured out? And is that true for everyone that I'm working with? Maybe there's someone who just joined the team and the fastest way to onboard them and make them feel comfortable and make them feel like they understand how to contribute and what the big goal is, and how everybody works together. If you do a value stream mapping exercise with your team, that person is onboarded in hours instead of weeks, they don't have to do pairing, they don't have to sit with someone for weeks to figure out 'here's how things actually work,' you can do it in so much less time and you can actually take that opportunity to realign someone who might be veered off in their own direction.
They might have been there for five years, but they've been stuck in one specific mindset and making assumptions that everyone sees it the way that I see it or I understand things and I'm fine, but once they realize, well, this like 30 % of my team really didn't know what was going on and we really didn't know what our biggest bottleneck was. These are things that you can solve and there are ways to solve them. So, I just want people to take that step back and use something to get those assumptions and perceptions out of the individual and bring it to the collective.
Tim Butara: Yeah, that's definitely a key piece of advice. Just before we finish, we mentioned earlier that you have an eBook available which we're going to provide access to in the show notes, but also you said that you didn't want to write a really long book, but that's also what you're doing, right, you you have a book coming out is it in early next year, if I'm not mistaken.
Steve Pereira: It's planned for early next year, there's actually one coming out in the meantime. So, the current eBook is the smallest most concise skipping over a lot of detail just the absolute basics, the book that's coming out in the next couple of weeks, that people can be signed up so if they sign up to download the book, they'll get a heads up about the next book that's coming out and every, all the material from now until the biggest book comes out. But the next book that's coming out soon walks through things like a whole organization narrative. So, it takes you from an entire story of someone learning about this and how to implement it and the outcomes and there's cases mentioned and it goes into a lot more detail.
So, that'll be a lot more valuable to folks and that's why that's coming out and there's going to be a lot between now and when the big book comes out, because there's a lot to cover. There's tons to talk about and I think this area just has so much that we need to figure out and I'm always finding new information that I'm trying to put out and share with people and get feedback about, and collecting more stories too. I'm starting to have really good conversations with organizations that are starting to use these things and I've got partners now who are contributing to flow engineering and growing it as a practice and starting to use it in different contexts, so there's going to be a lot of material about here's how this works in this specific case and here's how it works for things like a sales pipeline or here's how it works in healthcare. There's all kinds of different specifics that I think will really help make it applicable and make it real for people and help them place themselves into a very specific case that resonates with them and reassures them that, oh, this is something that will actually help me for sure because, I don't want anyone to take my word for it.
Tim Butara: So, if listeners want to pre-order the book or if they want to reach out to you, where can they do that?
Steve Pereira: Well, I'll share my email address. My website is visible.is and I've got a contact form there that's where you can sign up for the eBook as well but we'll put a link directly to that. Signing up to download the e-book, will put you on a list that will qualify you for pre-orders and discounts and everything that comes out. So hopefully, that's a one stop where people can follow on with everything that's coming out.
Tim Butara: Awesome, I'm glad we got to cover this topic today Steve. It's been a great conversation. I loved speaking with you today, thank you so much.
Steve Pereira: Thank you Tim.
Tim Butara: I hope our listeners will also enjoy it and get something useful out of it. So, to all of our listeners, that's all for this episode, have a great day everyone and stay safe.
Steve Pereira: Thanks everybody.
Thanks for tuning in. If you'd like to check out other episodes, you can find all of them at agiledrop.com/podcast, as well as on all the most popular podcasting platforms.
Make sure to subscribe so you don't miss any new episodes, and don't forget to share the podcast with your friends and colleagues.