People Driven Development

Episode 12: Where's my innovation?
===

Morgan VanDerLeest: [00:00:00] Hey, everyone. Welcome back to the PDD podcast. Today's question deals with one of the more layered topics we've covered in this show, and that's the topic of innovation. Innovation is a pretty tall order from an R&D organization. Not the least because it sits like right at the top of the pyramid of what a high functioning organization really is. A lot of things need to be true in order to foster that innovation. But in today's episode, we say, with everything else being equal, what distinguishes those teams who not just deliver, but deliver that thing, which unlocks the next stage of company growth. Eddie, would you do the honors with the question?

Eddie Flaisler: Of course. Dear PDD, I am a newly hired VP of Engineering at a Series C company. Before this, I was a very senior IC at a company renowned for delivering cutting edge technology. The founders here hired me, hoping I would bring the same spirit to this place. They are concerned about stagnating growth, believing that the current product has largely exhausted its market reach.

Eddie Flaisler: They think we need to pivot and experiment with new ideas, but they [00:01:00] found it nearly impossible to do so. Not only are the existing resources consumed by keeping the current product alive, but our setup also seems to make it hard to iterate quickly and repeatedly experiment with fresh ideas or radical changes.

Eddie Flaisler: I'm supposed to solve this, and honestly, I have no idea where to start. Send help.

Morgan VanDerLeest: Why does it sound to me like if we don't do a good job today, that somebody's going to get fired?

Eddie Flaisler: Oh, because they probably are. Love me a good high stakes problem. Cue the intro, and let's go pretend we're saving the day.

Morgan VanDerLeest: I am Morgan.

Eddie Flaisler: And I am Eddie.

Morgan VanDerLeest: Eddie was my boss.

Eddie Flaisler: Yes.

Morgan VanDerLeest: And this is PDD: People Driven Development.

Morgan VanDerLeest: Eddie, not to rain on your delusions of grandeur slash savior syndrome, but I am a little worried about this one. I think it's fairly obvious from the question that whatever makes it difficult to pivot seems to run much deeper in how this company operates. And it's probably not just limited to engineering. That really makes me wonder about the extent to which a head of engineering can even be helpful in unlocking [00:02:00] innovation. But I also don't want to blame this on a lack of alignment with the business side of things

Eddie Flaisler: Yeah, so there is surprisingly quite a lot that engineering and product can do here on their own. But before we dive into all the techniques, I think we need to spend some time on the motivation for innovation. Meaning, when and why would you as a product company want to try out some new ideas, call it innovation, pivot, or what have you.

Eddie Flaisler: You know, at first glance, it's pretty obvious. We need something exciting and new because the current thing we have is no longer serving us in achieving our financial goals. But it's much more nuanced than that. And, and I think that understanding the specific use case helps make the problem more tractable.

Morgan VanDerLeest: Can you double click and say more about the granularity there?

Eddie Flaisler: Yeah, so here's the thing. I don't think it's possible to know in advance which company will succeed and which will fail. But there are two things that are certain about the life cycle of a technology product. One is that it follows a fixed adoption curve. You first get [00:03:00] those customers who have to try everything just because it's new. Then you get the early adopters who see the value before everyone else does. Then you're stuck. Because you need to figure out a way to sell to the majority of the public, and the majority are those who are not visionaries but just want something that has worked for others.

Eddie Flaisler: And then, If you did that, and you essentially took over your market, it's by definition just downhill from there in terms of growth. The second thing is that once a company reaches that point of stagnant or even negative growth, so you're losing customers and revenue, it's very, very difficult to tell if it's simply because you just reached a mature market, so you kind of juiced humanity of everything it's willing to spend on your current idea and implementation of it.

Eddie Flaisler: Or if you're simply not selling or marketing or operating in a way that supports profitable growth. So, not only getting more customers, but also having new customers contribute positively to the bottom line. You know, it's like [00:04:00] that AI startup meme where the founder boasts the company's 5 million in revenue, but they spent 100 You can't have that long term.

Morgan VanDerLeest: For sure, even in a startup burn environment, you still need to act like a business, right? If you're burning X over some period of time, it is because at some point in the future, you expect to have Y return, and if you're not at least somewhat familiar with what those numbers are, you're not acting like a startup business, much less a regular business at all.

Eddie Flaisler: Totally.

Morgan VanDerLeest: So we're aligned on these kind of universal truths about the technology life cycle. What does that reveal about this kind of motivation to innovate?

Eddie Flaisler: Yeah, it reveals two things. One is that once you have something you built that has acquired a certain customer base, and it's no longer super clear if your next growth driver is building more new stuff or doubling down on sales and operational efficiency, it's risky to the point of suicidal to go all in on either of these drivers.

Eddie Flaisler: Because you don't know, right? You [00:05:00] can keep pushing engineering for new stuff when in fact your business and expansion model still needs work. Or you can transform engineering into this low cost maintenance shop where what you really needed was something new and shiny.

Morgan VanDerLeest: It's a really interesting balance, isn't it? And it really shifts over time for any business. What's the amount that we want to put into kind of either of those things are on that scale of thing of the new thing, the maintenance thing. What's that line and figuring out, how to balance that over time is incredibly important and not losing sight of how to do that over time. It's key to innovation.

Morgan VanDerLeest: All right. You mentioned there were two things. What's the second one?

Eddie Flaisler: The second thing is that it's necessary to build your technology or processes and your team under the assumption that sooner or later you will have to innovate. It isn't Yagni, right? You ain't gonna need it. It's not the nerdiness of someone who's detached from the reality of the business. It's forward thinking.

Eddie Flaisler: The only question is how much you invest [00:06:00] in the future versus the now, but you have to do both.

Morgan VanDerLeest: Yes, the "you have to do both" approach the "it depends" approach that seems a little meaningless on the surface. Let's let's dig more into that. It sounds a bit like you didn't really say much of anything. That's kind of the day to day of every single engineering leader I know it's involves juggling between building new stuff, maintaining existing tech.

Eddie Flaisler: Absolutely. But you know, Morgan, my point is that just because we always try to do both doesn't mean we do that effectively. And the question is, if there can be some method to the madness, can our VP who asked the question, navigate their mission to reinvent the product while not neglecting their responsibility to support the business in getting more out of current offering.

Eddie Flaisler: Which is where the founders are getting stuck.

Morgan VanDerLeest: Ah, and this is where our story begins, doesn't it? You want us to talk about lean.

Eddie Flaisler: First, you said it, not me. My husband and I don't use that word. We're both overweight and it's a trigger. Second, yes. [00:07:00] But before we get into the mechanics, I want to close the piece about when and why we focus our innovation again. By talking to a final point.

Morgan VanDerLeest: You go for it.

Eddie Flaisler: Yeah, so every business leader who wants to do a good job, including engineering executives, will eventually find themselves having to consider three horizons. That's not me, that's Jeffrey Moore, and it's also super accurate. The first horizon is the next 12 months. You optimize for cash flow and profitability.

Eddie Flaisler: In engineering, that's most likely efficiency related work, reducing infra costs. Automating repetitive manual tasks to save engineering time, investing in quality and performance so the team doesn't spend their lives firefighting, and despite that you still have customer attrition and one star reviews.

Eddie Flaisler: Stuff like that.

Morgan VanDerLeest: This is something that we've gotten into more in the past and won't dig into a bunch here, but this is one of those key reasons why your engineering culture, now is so important and why you need to be investing in that 12 months ago. Cause while, yes, your time horizons looking [00:08:00] forward are here, the horizons that affected now and these next couple of horizons were the things that you've done in the past. So how do you make sure you're maintaining these things so that when you are reducing costs, automating repetitive tasks, getting folks bought in to spend the extra hours on pushing through that deadline for that new feature. That these things can happen well and on time and not burn folks out so that this 12 month period is not just what are the things that we're doing for like engineering and the business?

Morgan VanDerLeest: But also how are we maintaining our people and growing our people in this process as well?

Eddie Flaisler: Yeah, I think this is a very solid point, and, Essentially, it's not that it's too late to start if you haven't started 12 months ago, but I think the underlying idea is you need to get people used to the idea that running an efficient business and efficient organization isn't a sign of drowning.

Eddie Flaisler: I think we talked about that in our unit economics episode, right? It's part of the business, right? I listened to a QCon talk today, where the person said [00:09:00] something really clever. They said, every engineering decision is a buying decision. It's so true because the decisions we make impact how much we're going to spend on infrastructure, on processes, on people to fix what we did, And that's not something that if you're mindful of, it means you're poor or the company is going to shut down.

Eddie Flaisler: It means we are doing our job as engineers.

Morgan VanDerLeest: I think we kind of lost sight of that in some of the low or zero interest rate years. The only reason that we stopped thinking that way was because money almost lost its value for a little while, but Oh, Hey, like we're back to reality where you do have to worry about these things. And at the end of the day, again, you're a business. You have to think about what are the costs of things? How long is it going to take? What's the value we're going to drive and whether or not it's worth to do that thing at all.

Eddie Flaisler: Always.

Morgan VanDerLeest: So what's the next horizon.

Eddie Flaisler: Yes, so we talked about the first horizon. The second horizon is 12 to 36 months. [00:10:00] That's more preparing the Eng team for handling growth. So how do we support the creation of new revenue streams out of existing products? How do we adjust the changes in customer needs? A lot of incremental work that needs to happen fast.

Morgan VanDerLeest: And for that, you probably focus more than anything on developer productivity so that you can move fast when that need does arise.

Eddie Flaisler: Bingo. That's exactly right. The third one is the horizon of 36 months and beyond. It's basically saying, once we're done writing the current wave, what's next? And the only thing that's next is again disrupting a market or creating a new one.

Eddie Flaisler: It doesn't mean changing what you do entirely, right? You can be adding something like Apple did with the iPhone. Most companies don't operate at Apple's scale, but at least in concept, we have to innovate to stay alive.

Morgan VanDerLeest: But hang on one second, I want to make sure that I understand, because at this point, some listeners are probably like seriously. So he's saying that if I want to do my job as a VP of engineering, I need to invent the next iPhone. Apple didn't just add the iPhone. That was a big [00:11:00] deal.

Eddie Flaisler: 100%. And the answer to what you asked is not at all. You don't need to invent the next iPhone. The opportunity, not to mention the foresight to create something as groundbreaking as the iPhone. is not something most of us will experience firsthand. I know I won't. But what we will experience is change.

Eddie Flaisler: And that's actually the point I'm trying to make. Change is guaranteed, and it is an inevitable part of at least two of the three horizons. The second, and the third. No person can be expected to come up with the next big idea, but what we can expect of ourselves is to prepare our org for the next big idea.

Eddie Flaisler: People can and have built engineering organizations that were a little less rigid. And a little more adaptable to changing as needed.

Morgan VanDerLeest: You know, I like how this is starting to come together. And that's one of my big focuses in my day to day is acknowledging reality, right? Change is reality and you need to build that into the way that you think and process and do work if you're going to be [00:12:00] successful, especially within the engineering world where a lot of times you do need to move both quickly and maintain what you have already. So. We started this conversation talking about finding that balance between innovating and supporting the immediate needs of the business. I don't think anyone really has the algorithm right for that balance. And I'm not sure it's there's one right algorithm anyway. So I don't think it adds too much value.

Morgan VanDerLeest: If we just tell people, all right, that's what you guys need to figure out how to do.

Eddie Flaisler: That's right. There's no formula for that. So the balance itself is not what you're actively pursuing.

Morgan VanDerLeest: Okay, but what you are saying is that we can build the capability of moving the dial between invest in today and invest in tomorrow with relatively little friction. I'm guessing that's the adaptability you're talking about.

Eddie Flaisler: Yes, exactly. That's what I hope we can spend the rest of this episode describing in detail, how to build.

Morgan VanDerLeest: Yeah. You know, Eddie, this mental model of the problem is starting to make a lot of sense to me and I love that adaptability. There's another great book "Team of Teams" by General Stanley McChrystal that talks about [00:13:00] how for a long time, the military was focused on efficiency, it was all about efficiency and that mapped very well to manufacturing engineering and things in the past, where you have this idea of a machine that you can optimize for utmost efficiency and get as many widgets out at the end as possible. Software engineering, while yes, code and machinery, in some sense, Is much more people focused as we've talked about a lot. And that's why that emphasis on adaptability is how you get the biggest wins, I think at the end of the day, and by enabling that and that adaptability to work well, you get to those better outcomes.

Morgan VanDerLeest: And I'm sure we'll dig into some of this as we kind of get through this, but we don't want local optimization. We want global optimization. And if you're going to have that, you need to be, you need to be adaptable.

Morgan VanDerLeest: You need to be organic. You need to have your teams able to communicate and talk well and deal with things that arise and not have like a person deciding all the things. We'll get to that, but in practice, it's just, does sound a little kind of paradoxical, doesn't it? We have these kind of. two ends that are [00:14:00] like quite different needs where we have this innovation side that's focused on constant change, trying to find product market fit, solving problems people didn't even really know they had. And then another one that's much more focused on whatever your current offering actually is and following a strict roadmap and meeting those targets. Right. And I get that on paper, you can allocate time for both of these, but those do sound like quite different cultures, you know, I mean. How much risk are you willing to take?

Morgan VanDerLeest: What's the meaning of failure? What are the skill sets that are appreciated more than others? I don't think you just flip a switch between these, and you have the same people.

Eddie Flaisler: You know, I cannot agree more. And quite frankly, many companies who could afford it have taken the approach of spinning up completely new business units operating independently so they could start fresh on the new thing. Right, free from the constraints of the old system. But, do you know who didn't think any of that was needed?

Morgan VanDerLeest: Who?

Eddie Flaisler: Toyota.

Eddie Flaisler: The Toyota Production System, or TPS, is probably the [00:15:00] most famous example in the world for a socio technical system. So basically an organizational work design that does not ignore the fact there are humans involved in the process, but builds on that.

Eddie Flaisler: Now, I know this is a family show, but I find the fact that TPS came from Japan fucking crazy. Japan is one of the most hierarchical societies on the planet. The boss is God, and you are still expected to give your everything, forever, no matter how you're treated. And if there's a single listener right now who's rolling their eyes and thinking to themselves, Oh, I didn't realize I was listening to Joe Rogan, I recommend they go to the Country Comparison Tool by the Hofstede International Culture Institute and compare Japan to the US.

Eddie Flaisler: The reason I went on this tangent about Japan is because this is super telling. One of the most non individual centric societies in the world, at a time when they're also one of the highest economic achievers in the world, produced one of the most successful companies in history, and did so by developing a [00:16:00] method that is people first.

Eddie Flaisler: Almost 80 years after its inception, this method is still at the core of how Japanese auto manufacturers Consistently deliver the highest quality in the industry in costs substantially lower than those of US manufacturers.

Morgan VanDerLeest: It is amazing that a place known for such Efficiency and quality and things that we really aspire to as engineering organizations has such a people first methodology. It's kind of an interesting thing to ponder in your mind for a bit.

Morgan VanDerLeest: Now, I know there's a lot more to say about this method, but how would you like us to tie this into our problem statement today so that our listener can benefit from it?

Eddie Flaisler: I think we can do that by translating the two pillars of TPS into actionable engineering strategies. The first pillar of TPS is called Jidoka, which literally means automation with a human touch. This is the more human centric pillar, which we'll get into first.[00:17:00]

Eddie Flaisler: The second pillar is just in time, making only what is needed, when it is needed, and in the amount needed. This one is very mathematical, so we'll do our best to give an intro to the three main tools used in implementing it: value stream mapping, cost of delay analysis, and Monte Carlo simulations. To those familiar with the topic, please note that I said value stream mapping and not value stream management. We'll touch on the latter a bit in our future org design episode, but value stream management is a whole thing that I personally have not seen implemented well in practice.

Eddie Flaisler: Unlike value stream mapping, it's not easy to introduce into an existing organization.

Morgan VanDerLeest: I love it. I'mm excited to dig into this a bit more. Now let's go head-first into people-first., let's talk Jidoka.

Eddie Flaisler: Okay, so I find Jidoka incredibly layered because it says things that sound very generic, but it actually implies a lot more. Its two foundational aspects are, one, every employee should aspire to develop [00:18:00] mastery and strive for continuous improvement of themselves and what they work on. Two, every employee is empowered to ring the alarm bells and stop production when something is wrong.

Morgan VanDerLeest: You know, Eddie, we started this episode by stating how innovation is at the top of the pyramid that represents a high performing engineering organization. And I feel like those two aspects are again something that needs a really solid foundation to sit on. You know, we've talked in the past about how you can't just expect a person to be passionate about what they do simply because you're paying them like, this is a really a different level entirely.

Eddie Flaisler: So I think I mentioned on some episode that I had heard this interview where an executive was describing how Gen Z cares a lot less about work and does the bare minimum compared to older generations. I really don't have the data to support or deny this claim, but here's what I can tell you.

Eddie Flaisler: Today, there's a lot more awareness about the kind of treatment you're given as an employee. And you know, when your bar for that is not met. It's more difficult to be all in. I don't think it's our job as managers to make a [00:19:00] person excited about something. You know, passion is oftentimes more intrinsic than extrinsic.

Eddie Flaisler: But we do have to not mess excitement up, right? Like, I know for a fact that if we dehumanize a person, then even if the mission of their team is right up their alley, it'll be very difficult for them to move past that and focus on making the mission successful.

Morgan VanDerLeest: And I think I know what you meant here, but I wanted to clarify, you say dehumanize, that sounds a bit extreme, doesn't it?

Eddie Flaisler: Well, dehumanization doesn't have to be this blatant form of humiliation or mistreatment. It can simply be the naive expectation from people to get on board and collaborate with ideas that, you know, while potentially beneficial to the company, are definitely detrimental to the individual employees. I'll give you an extreme example to make my point.

Eddie Flaisler: A few years ago, I was interfacing with a company where the size of the engineering org was approximately 100 people. For the complexity of the system at the time, that was appropriate. A very senior engineer came up one day with an idea that they pitched the CEO.

Eddie Flaisler: They said that in under a [00:20:00] year, they could rebuild a v2 of the system that would do the exact same thing and require no more than 10 people to operate. That conversation through the leads into an almost month long uphill battle trying to explain why they did not believe the engineers would agree to invest their time and brain power into building a system that would put 90 of them out of a job.

Eddie Flaisler: They were ultimately overruled, and a team was assembled to build just that. It's been quite a few years now, they're still building.

Morgan VanDerLeest: You just, you can't make these stories up. I'd actually love to throw in another example of dehumanization that I think a lot of organizations do and don't think about how they go about this. When you boil somebody's work down to a matrix and a couple metrics, you are dehumanizing someone. Everyone, and while it may not impact everybody in the same way, some folks may not think about it. That doesn't mean that it's not impacting everyone. The way that we go about measuring engineering and engineering output and things... We need to be particularly careful about those things, how we go about it, how [00:21:00] we communicate that and how we share, this is part of a broader context that we want to be a part of, and not just strip away all the pieces that makes a person, a person. Here's a couple of metrics that would have come out of a machine. Okay, cool. Now this is how we measure people. Need to be careful with that.

Eddie Flaisler: Yeah, and I think that's why we said in the past that metrics are a very powerful tool and it gives you some very helpful insight when applied at the organizational level, not on the individual.

Eddie Flaisler: On the individual, it's 99. 9 percent of the time just creepy. There are exceptions, but very few.

Morgan VanDerLeest: Very true. So that definitely gives us some prerequisites before we expect employees to strive for continuous improvement. What about ringing the alarm bells?

Eddie Flaisler: I think this one has tentacles in the human aspect, the process aspect, and the technology aspect. You know, the economist William Deming, to whom some of the greatest success stories in American and Japanese corporate history owe a huge debt of gratitude for his work on process management, used to [00:22:00] repeatedly say, Whenever there is fear, you will get the wrong figures. And that's a really elegant way to say, You cannot be an unapproachable, conniving, and short tempered a hole using your manager role as an excuse and expect people to feel comfortable coming to you bearing bad news.

Morgan VanDerLeest: That's such a true point. I think that's also one of the things that shifted in engineering culture over the last couple of years is getting to more of the SPACE framework and whatnot around metrics. And it's not just numbers from the system, it's qualitative things and surveys and understanding the teams and your people. And if that data is muddied because people are scared and they're not telling you the truth, your data is muddied and you're going to make bad decisions based on that. All we can really do as leaders and managers is create the environment for somebody to be successful. If any individual or team is not being successful, that is not because of the individual or the team that [00:23:00] is because the environment that we have created is not a place where people can be successful. That is where our focus needs to be.

Eddie Flaisler: 100%.

Morgan VanDerLeest: All right, let's dig into the process aspect.

Eddie Flaisler: I think the process aspect boils down to how defects are handled in the organization. I worked in teams that were extremely meticulous about bug triage and constant prioritization of tickets. They made sure that show stopping issues were addressed immediately, That P1 issues were release blockers, et cetera.

Eddie Flaisler: I am personally biased towards that, because I've seen it result in very satisfied customers, but I know it's very common for engineering teams, especially in more early stage environments. They have a more lax approach toward defects, and focus more on managing the expectations of the customer than on building good quality into the product.

Morgan VanDerLeest: You know, I personally don't think there's a right answer here. Every business has its own priorities for what's important. You have time to market, volume of features, security and compliance. These are all more or less of an issue and we can't judge. [00:24:00] I do think the old saying about the cost of fixing a defect increases exponentially the later it is detected in the process is very relevant here because the more issues and workarounds that you accumulate, think tech debt, the more they compound into a system that becomes increasingly difficult to maintain and fix. Even if one day you do decide that you care about quality.

Eddie Flaisler: That's incredibly astute, Morgan, and I completely agree. This is actually where the process tentacle meets the technology one, because It's your choice as an engineering leader, if you build something that requires a lot of manual engineering involvement to maintain, or runs for the most part without human involvement, just like TPS intended it to.

Morgan VanDerLeest: Yes, 100%. Eddie, I think it's time we moved on to the just in time pillar, but before we do, I want to make sure we leave our VP with some crisp, actionable advice, summarizing Jidoka. What are we recommending here?

Eddie Flaisler: I'll stick to the most powerful one. Diagnose how decisions are made and executed. If the organization's power [00:25:00] dynamic around making decisions doesn't support Jidoka, you either need to change that, or the battle is already lost.

Morgan VanDerLeest: Jeez, decision making. That's podcast episode in and of itself.

Eddie Flaisler: It really is.

Morgan VanDerLeest: So give me some highlights.

Eddie Flaisler: Okay. One. Are we customer centric? And checking for that runs much deeper than just hearing people say, we need to be customer first. It includes things like, is the design domain driven? So, when a new capability is proposed, is Is there a clear articulation of the customer value, given what we know about our customers?

Eddie Flaisler: Or, do the engineering team and the business side have a common language to make sure we're building the right things? You know, if people are using different terminology to describe the same thing, requirements will get lost in translation, no matter how small or early stage the company is. In a fairly recent example, I realized my product lead and engineering lead were interpreting a customer related metric in two different ways.

Eddie Flaisler: And the actual definition was the third [00:26:00] one.

Morgan VanDerLeest: And that is not only sad but terrifying, that that kind of thing happens. And it's funny how we lose focus of being simple, and I know that's something that a lot of organizations will talk about or come back to, uh, I mean, there's a lot of sayings around like, Oh, like the simple thing is hard or getting too simple is hard. It is so important so that you can be talking that same language and have consistency in the things that you're doing. And so folks on one side of the business and the other who may not talk at all, like the engineering lead and a product lead, okay, they're probably talking in a regular basis, probably not a good thing that those folks are not aligned on what a metric means. But if you can have people on opposite sides of the org who almost never interact talking and thinking through things in a similar way, because they know what's important for the business, because leadership in the business has spent time simplifying that and making sure like we get it, we repeat it or people understand this. That's huge.

Eddie Flaisler: That is why languaging is [00:27:00] super important.

Morgan VanDerLeest: Yes. It's also important to remember that internal customers are included in the definition of a customer. I think there's this tendency to assume that just because the function you're building for is within your company and not a paying customer that you know better than they do what they need. We don't, we just talked about that different sides of the org, different areas. If you're not super clear on what those things are, you're going to run into trouble. I've seen so much time wasted building the wrong thing and with so much friction and frustration.

Eddie Flaisler: Could not agree more.

Morgan VanDerLeest: Okay. What else on decision making culture?

Eddie Flaisler: So while on the topic of internal customers, I think it's extremely important to observe how internal technology migrations happen within the company. That's a mirror to the overall mindset. This is probably less relevant when you're a 10 people company, but for even 50 and above, it becomes very relevant.

Morgan VanDerLeest: Say more about that.

Eddie Flaisler: Love to. I love storytime. In one of my product engineering roles, I inherited a team where I had to [00:28:00] work very hard to get them to start delivering and actually meet targets. A few months into my tenure, when we were finally starting to see some results, an email arrived from the Infra team a few short weeks before a long awaited customer release.

Eddie Flaisler: It said, Hi, we are replacing the event management system your product relies on in two weeks. Please get your affairs in order and migrate. Thank you. When I was done with my panic attack, I asked around to see if I somehow missed some previous communication or, I don't know, a meeting to gather requirements.

Eddie Flaisler: No one knew anything. So I reached out the head of Infra and asked if we could meet to understand the change and plan for it. I was trying to be very, very constructive about it. They responded that they didn't have time and that we needed to comply. I responded that given our externally dictated deadline, which the strategic customer mandated or else they would leave.

Eddie Flaisler: We wouldn't be able to. They forwarded my email to head of engineering saying it was a shame that the company hired people who did not know how to be team players [00:29:00] and collaborate. So my head of engineering ended up calling me and said they would try to talk to the customer to push out the delivery date and ask that I collaborate to restore organizational peace. I did. And two months later, it happened again.

Eddie Flaisler: No requirements gathering, no timely warning, just escalation on those who objected, which this time actually wasn't me. They ended up also giving in and it resulted in one of the company's biggest outages in my time there. As we mentioned in the beginning, technology changes follow a predictable life cycle.

Eddie Flaisler: You cannot force a different curve and you cannot squeeze a timeline. Even if you're building something for internal customers, you are building it for the customers.

Morgan VanDerLeest: You know, please get your affairs in order is not something I want to see from an internal communication. all right. Final something for the VP to diagnose before we switched to just in time.

Eddie Flaisler: Yeah, sure. The most important thing. How comfortable do people feel sharing feedback with their superiors? I learned [00:30:00] from personal experience, unfortunately, that no matter how hard you try, it's still very difficult to make people not scared of authority figures. You remember the moment Erin revealed that the team at Lob was scared to challenge me when I rolled out cycle time tracking.

Eddie Flaisler: I still need to think what more I should have done there, but what I know we can do for a fact, at the very least, is to make the space for these dissenting opinions. When I was bar raising in hiring committees at Uber, we had this beautiful rule that was very effective. The manager and bar raiser spoke after the IC interviewers, not before.

Eddie Flaisler: Because they found that unsurprisingly when the manager sets the tone for the conversation by saying they like or don't like the person, most people's opinions magically shift to align with what the leader said. People need to feel comfortable to express different views, including constructively saying no to things, as we discussed in the past.

Morgan VanDerLeest: 100%. I love that process. Speaking after ICs or giving folks a chance to speak first.There [00:31:00] are e so many scenarios where just good facilitation of a meeting or a conversation can make such a big difference on the outcome of that conversation. Where it's not just ideas being thrown around, but like a really good dialogue that helps bring about a better outcome than we would have had otherwise. And again, a lot of folks kind of go into those thinking like, oh, I'm, you know, I'm the manager and the most senior IC. I'm the one who's going to have the idea that needs to come out of this. That's most important. Like, well, hang on. Like we don't know. And the vast majority of folks, like our businesses serve a lot more than like a very narrow niche of customer. There's a lot of demographics behind that. And by not including a lot of the people in the room on how you think about things, whether it's lower tenure, different background, et cetera, all these voices matter and making sure that the folks feel comfortable sharing what they think needs to be shared.

Morgan VanDerLeest: Yeah. Sometimes, you know, People are going to say something that it's like, okay, I'm glad they said it, but not as applicable [00:32:00] here for some reason. But there's a lot of really good stuff that people bring from everywhere, all other aspects of their life. And if we're not tapping into those things in our day to day, you're really missing out in your org.

Eddie Flaisler: Yeah, facilitating a conversation instead of taking up all the air in the room is not a bonus, it's an obligation. So that's something the manager has to do.

Morgan VanDerLeest: Very true. All right, let's switch gears. It's just in time time.

Eddie Flaisler: As my idol Lizzo says, I've been waiting for this one.

Morgan VanDerLeest: All right, Eddie, when you gave a high level review of just in time, you mentioned a few things. You mentioned value stream mapping, cost of delay analysis, and Monte Carlo simulations. Before we dive into each of those, how about we talk through how all these things fit together.

Eddie Flaisler: Yeah, totally. So just in time is about prioritization and risk management. These are the two key elements. If you remember, one of the things I always say is that the role of a manager involves a lot of individual contribution as well, just not necessarily on the core offering of the [00:33:00] business.

Eddie Flaisler: This is a perfect example of that because if, as discussed, we want to be very efficient about moving our proverbial dial between invest in today and invest in tomorrow, we as the manager have to be the world's number one expert on the work our team does. Notice what I said. I said work, not the product spec, not the technical design.

Eddie Flaisler: Experts on who's doing what, when, and most importantly, why. You know I'm hugely opposed to the manager being the technical know it all, but when it comes to prioritization and trade offs, or identifying and managing risk, I'm the manager, it's my job. I totally get it that some prefer to use their time differently and will delegate this sort of activity to a program, a project manager, or consultancies if they can afford it.

Eddie Flaisler: Anything works, just do the thing. Now, to specifically answer your questions how everything fits together, Here's what prioritization and risk management means to me in [00:34:00] order. One, value stream mapping. So you basically understand how value flows to the organization from concept to customer. When you map out all the activities involved in getting the thing done, it's shocking how easy it makes it to identify inefficiencies, to identify bottlenecks.

Eddie Flaisler: This is a great opportunity for me, by the way, to plug the book, Flow Engineering. It's by Steve Pereira and Andrew Davis. That book makes the concept of value stream mapping super accessible and gives very helpful examples.

Morgan VanDerLeest: You know, this is a great example of one of those things that, it's a relatively simple thing to do. It can really be a big unlock for your org just to be able to find these inefficiencies and things within your company in a way that, you're missing out if you're not able to do these things now. And just laying it on the table and being able to see where those bottlenecks and inefficiencies are, that could be huge.

Eddie Flaisler: Absolutely. And it also makes everyone feel a lot more involved, because it's a really fun group exercise.

Morgan VanDerLeest: 100%. All right, value stream mapping done. Next.

Eddie Flaisler: So, once you [00:35:00] identify the bottlenecks and inefficiencies through value stream mapping, the cost of delay analysis, or COD, helps you determine the cost of those bottlenecks, and which one to address first. Of course, sometimes the cost is clear and you don't need to go through this exercise, but for when it's not, it's a very powerful tool because it establishes a clear prioritization mechanism to focus on the most valuable, you know, and time sensitive work.

Eddie Flaisler: Now, in theory, you could stop here, right? You know your risk areas, you know what to prioritize, how much of your resources should go to what, but not really. The problem is that COD analysis typically assumes static timelines and doesn't account for the uncertainty and variability of In actual delivery times. So in simpler terms, I can put in my COD table five weeks to do something because that's what my engineer told me. But more often than not, it ends up being not five weeks.

Morgan VanDerLeest: Isn't that the truth, we did a full episode on the lack of predictability in software engineering.

Eddie Flaisler: That's right. So sometimes you have very high [00:36:00] confidence in the effort estimate of an item on your priorities list. But other times you need a probabilistic view of delivery scenarios because you don't know when exactly things will converge.

Eddie Flaisler: That's where Monte Carlo comes in.

Morgan VanDerLeest: And that's a great example too, of how important your communication and trust and comfort is with your team. because folks need to be able to give you as accurate of an estimate as they can not sandbagging either way and also with the understanding of like hey if these things happen it could affect our estimate in certain ways if we don't get certain thing done or if this other thing comes up etc. And again folks need to be comfortable telling you what to do The truth here and not something worse.

Morgan VanDerLeest: And of course you can still have that conversation around like, Hey, did you consider what might happen if X, Y, Z happens and help get to that better outcome or that better understanding. But it really depends on how you're able to communicate here and build that comfort and trust with your team.

Eddie Flaisler: And this [00:37:00] connection you just made between just in time and Jidoka is the core of the TPS mechanism.

Morgan VanDerLeest: Love it when I say the right thing on accident. So Eddie, as people probably realize by now, each of the three components involved in this just in time philosophy for decision making is in and of itself, a topic we can dive into more, it could be properly studied. And this podcast is definitely not the place to go into that full depth class. What I do think would be useful though, is if we can give people a good sense for like how each of these things work, what to look for and where to find more information. How about that?

Eddie Flaisler: Let's do this.

Morgan VanDerLeest: Okay, cool. So let's dive into value stream mapping more specific current state value stream mapping. What does the team's work look like at present? The idea is that you map out the activities the team needs to spend time on to make a thing happen either for the customer, the business, or both. And that something is the value. It can be a feature. Building capability like implementing sales tax could be a performance improvement and for cost [00:38:00] reduction, reducing carbon footprint of the product. You just need to be able to clearly articulate the value of the thing. Now, a typical panic question at this point is wait.

Morgan VanDerLeest: So now every checkbox in my UI needs to have this exercise done. And the answer is of course, no, but because this checkbox or that banner share a workflow on the R&D side, you go through the same activities. So you group these things by workflows.

Eddie Flaisler: Identifying the workflow is a team exercise. Not the least, because even if you think you know your Eng team software development lifecycle by heart, there's always that vendor someone needs to ensure backward compatibility with, and always that meeting someone config file we keep forgetting to update.

Eddie Flaisler: So the more input, the better. The list of steps you come up with is called the value stream. You

Morgan VanDerLeest: Just to be clear, a full value stream mapping is very scientific. If you do it by the book, you end up associating specific metrics to each step and define all these data driven goals, don't bother really. It just makes the whole [00:39:00] concept more daunting and you'll never get to that. And I don't want that to get in the way of y'all actually going after this work. When we never spent the time to understand what our full list of activities around delivering value actually looks like, even figuring that out gives so much clarity that if we act on only that, the improvement is still insane. Just do the exercise of discovering the steps, work back from the value delivered.

Eddie Flaisler: PagerDuty's magnificent head of engineering, Paula Thrasher, defined a very useful framework to identify value streams. It's called the 5Rs. I'll shorten it to 4 to keep it simpler. It needs to be recent. It needs to have real business impact and not just say a dependency upgrade. It needs to be representative of how you do your work, and not a one off request, and it needs to be row tested.

Eddie Flaisler: That's probably the most important thing, row tested. Something that's in production, ideally with telemetry and customer feedback. This is important because if [00:40:00] it isn't in production, then you don't actually know if you did all the steps you needed, Nor if it actually delivered value.

Morgan VanDerLeest: A basic stream mapping exercise entails selecting the value, identifying the respective stream of activities and adding timing to each activity, which honestly does not have to be an exact measurement. Public survey of the team is fine. Hashtag wisdom of crowds. You'll find that bottlenecks and areas of focus pop up immediately.

Eddie Flaisler: That's how we found out that people were spending days trying to make flaky tests not even related to what they were building pass and thought that was acceptable.

Morgan VanDerLeest: You know, it feels like you're looking over my shoulder at every company I join. And that's all we're going to say about that. Go look at the book Eddie recommended.

Eddie Flaisler: Flow Engineering.

Morgan VanDerLeest: Yes, next.

Eddie Flaisler: Okay, so this one would be a little bit less of a rapid fire because it requires more background. The concept of cost of delay, or again, COD for short. is foundational to financial investment, but using it in IT [00:41:00] projects is a fairly new thing.

Eddie Flaisler: When we say cost of delay, it's not about what we're actively paying for something, but about the money we're leaving on the table by not taking on that opportunity right now. So if I know today that I have a certain amount available, which I would like to invest in an instrument that gives some fixed interest, and I sleep on it for six months, during which the money continues sitting in my checking account, then the interest I could have earned between today and six months from now is my COD.

Eddie Flaisler: Similarly, for an R& D organization, my cost of delay for value X from the list I built in the previous step, is how much money I'm losing or not making by not doing it. COD has a weird history in technology. You know, there are two famous, mind blowingly successful case studies on using COD to improve the velocity of value delivery by orders of magnitude. The Maersk Shipping Company and the US Air Force. Both transformations took place between 2010 and 2012, but what's interesting is that [00:42:00] COD didn't quite catch after that, even though the technique is not complicated.

Morgan VanDerLeest: I'm curious, why do you think that is?

Eddie Flaisler: Truthfully?

Morgan VanDerLeest: Always.

Eddie Flaisler: Well, the short version is that for a decision making framework to be adopted, you first need to believe in the relevance of scientific and not purely socially driven decision making in the environment you're in.

Eddie Flaisler: The long version is that I think decision making is the most challenging part of a manager's work. Not because of the intellectual complexity of making the decision, but because for most of us, most of the time, present company included, our ego gets in the way of making the right decision. You know, we all have our pressure points and triggers, so we react to some requests better than others, regardless of what the right thing to do is.

Eddie Flaisler: We also get anxious when results are poor, and subsequently not only do we make reactive decisions that further worsen the situation, but But we can also make a point to ignore the data and go with our gut instinct just to feel in control. I can go on. But all that is to say [00:43:00] that while we can remind ourselves and others of all the available techniques to do the right data driven thing for the business, it will ultimately boil down to whether or not the company we built is an environment where people feel supported in making the right decisions.

Eddie Flaisler: You know, I've heard quite a few people throughout my career say that this whole idea of empowering employees is BS. Because the person needs to empower themselves. I could not possibly disagree more. Empowering is a thing. If you're aware of your surroundings, the way you make decisions is always a reflection of the environment you're in.

Morgan VanDerLeest: Yes, I love that, and I'll actually make another book plug here. How to Decide by Annie Duke. One of the best decision making books that I've ever read. Around how really what goes into different types of decisions, how you can come up with those, how you can talk about like probability cause outcomes. Cause I think one of the most important things that we forget is just because the outcome of a previous decision was good does not mean that you made a good decision.

Morgan VanDerLeest: And I'll let that sink in [00:44:00] for a second and I'll even repeat it just because the outcome of a decision went well for you, or it was good does not mean that you made a good decision. It could have been an incredibly reckless decision that happened to turn out okay, thank goodness. That does not mean that you should be making the same decision making strategy in the future.

Eddie Flaisler: Luck is a factor.

Morgan VanDerLeest: True story. In any case, our VP is dealing with a high stakes situation, so it's as good a time as any for their organization to try something different. Let's talk about how you do cost of delay. One quick thing before we do, in product companies, you often hear the term RICE score. Is that similar?

Eddie Flaisler: So there are many types of scores and excellent methods for prioritization. One of the biggest contributors, if not the biggest, to the effectiveness of any model is the quality of the data. So the more assumptions you have to make to fill your dataset, the worthless the model is. RICE is Reach, Impact, Confidence, and Effort.

Eddie Flaisler: Four different things you basically need to guesstimate. [00:45:00] With COD, you typically only guess one thing. And that in my mind makes it much more reliable.

Morgan VanDerLeest: Fair enough. That's a really good point. Just reducing the amount of variability, often a good thing. Let's go.

Eddie Flaisler: Okay, so this is again a situation where visual aid would have been super helpful, so I'll try to keep it palatable. A COD analysis is a table. It's a table where the rows are the value streams you identified in the previous exercise, or just simply put, the things your org needs to do. We can think of all the rows as features, if that's easier. The columns are where it gets interesting. First, you have the benefit type. What are you gaining by doing the value stream?

Morgan VanDerLeest: Yeah, so things like reducing cost, increasing revenue, protecting revenue. It's probably important to know because it reminds you how to approach calculating the benefit amount, the amount of money you'll gain or not lose by doing the thing.

Eddie Flaisler: Bingo! The second column is the more interesting one, but luckily the values are from a fixed list [00:46:00] so you can just use them as are. It's called urgency profile. The urgency profile of a value stream, simply put, is how will the financial from this value stream change over time?

Eddie Flaisler: This is super important because there are different levels of urgency, and they dictate different calculations. Here are the scenarios. 1. Long life cycle, peak unaffected. Okay, remember that. Long life cycle, peak unaffected. It means this is something where the benefit remains stable, regardless of when you deliver.

Eddie Flaisler: So delaying doesn't reduce the eventual benefit. It just defers it. A good example is to introduce automated invoice processing to save X dollars a year on this task.

Morgan VanDerLeest: Two, long life cycle Pete affected by delay. So the benefit is long lived, but has a first mover advantage or time to market importance. Delaying the start reduces your position in the market, incrementally eroding your long term benefit. So this is a really interesting one [00:47:00] because it's surprising how much work that isn't just delivering a new product or concept actually falls in the bucket of peak affected. Eddie, don't you have a Box example of this?

Eddie Flaisler: That's right. That's right. When I was in Box, I was given the scope of insights and reporting, and everyone seemed really invested in improving that for our enterprise customers.

Eddie Flaisler: I was very confused, not to say cynical at first. I was like, dude, it's a report. We're not building the future here. I was wrong. Reporting dashboards provide usage transparency and not only help build trust with the customer, but also help our team make the point that it's time to upsell by showing the usage.

Eddie Flaisler: If we had not released this on time before other competitors went to market, we would have probably lost customers.

Morgan VanDerLeest: Okay. So we did long life cycle, peak affected and peak unaffected. You can probably guess what's next short life cycle, peak affected, like a seasonal marketing feature, which generates all its benefit during a 10 week holiday window. If [00:48:00] it's late by a week, you lose one 10th of that total potential revenue.

Eddie Flaisler: that's right and the last one is external deadline. That's really easy to think about, right? A customer you want to retain or gain needs x by date y. Your last responsible moment to start working on x to get it done by y is date z. Anytime before z you get the full benefit.

Eddie Flaisler: You miss z it goes down to zero.

Morgan VanDerLeest: That's a great point. I think an external deadline is a perfect example of getting more out of what we have right now versus trying to innovate and discover the future. We know what we need to do and we need to execute on that. That's not a bad thing. It's just a different setting on this innovation dial that we've been talking about.

Eddie Flaisler: Absolutely.

Morgan VanDerLeest: Okay, so now we have the benefit type and the urgency profile. What's next?

Eddie Flaisler: Okay, so now it's time to do most of the homework. The next two columns are the benefit amount in dollars from getting the value out and the [00:49:00] projected duration of the work stream.

Morgan VanDerLeest: Hang on. Wait a minute. You sold this as only guessing one thing. Both of those things are not easy to assess exactly.

Eddie Flaisler: Yes and no, because when we talk dollar amount. It's always about the number we hope to get out of the thing. Life happens, but we always have target numbers, right? So, This would be true even without doing cost of delay. These numbers that we initially attach to the work are what goes here.

Eddie Flaisler: Regarding the effort estimate, you're totally right, and we'll talk about dealing with that at the end.

Morgan VanDerLeest: Okay. Fair enough. Makes sense. So we got these two down. We have all the inputs, right? Benefit type, urgency profile, total benefit amount, and work stream duration. Is it math time?

Eddie Flaisler: It is. So the last two columns are what will ultimately dictate the order of the work, COD per week and final priority. Most of the math is done in COD per week. Then you take what you calculated there and divide it by the work stream duration. You do that so you get to an apples to [00:50:00] apples situation.

Eddie Flaisler: That is your final priority.

Morgan VanDerLeest: All right. I think we shared more than enough context for one episode. We're going to skip the actual calculation, the weekly cost of delay. Suffice it to say that across all urgency profiles, it's a function of the total benefit and the time window associated with the profile. That's all your favorite AI chat bot is a great friend from here on out. Now we identified our value streams and we're able to prioritize them, what's left to do?

Eddie Flaisler: The final touch. So as we mentioned, the main problem with COD is the uncertainty of workstream duration. You rarely know how long stuff is actually going to take. So for your estimate to be good, you need to account for the various options of the duration. Maybe it'll take five weeks, maybe eight, maybe 11.

Eddie Flaisler: The problem is that if I were to ask engineering managers or even professional data analysts to do this simulation by hand, they would resign immediately. Cost of delay analysis is enough work as it is, and [00:51:00] I don't need to add more grunt work. So what's nice about the Monte Carlo method is that you give it your formula for calculating the weekly cost of delay, and you also tell it something like, my team told me this thing would take best case 5 weeks to build, worst case 11, and probably 8, so you kind of give it a distribution of potential durations, and that's it.

Eddie Flaisler: It calculates for you the different costs of delay with the respective probability. You can choose which value you want to go to the prioritization exercise with based on the probability you're comfortable with.

Eddie Flaisler: So if some value is with 80 percent probability and another value is with 90%, you can go with the 90 percent one. The pseudocode for this is everywhere online, really. And I never say this lightly, but it's very straightforward to implement this in something like Python. And it's so worth

Morgan VanDerLeest: It's interesting talking through a lot of the kind of mathematics and probability here, because like I mentioned that, "How to Decide" book by Annie Duke. A good chunk of that is [00:52:00] probability trees and the likelihood of certain things happening. And that by really adding some of this mathematical touch to it, this is a much better way to be able to go to your engineering leadership or company leadership and saying, Hey, this is what we're doing and why and how we're breaking down our priorities.

Morgan VanDerLeest: And it's a much more tangible way to show these things. It's not just like, ah, we think this x and y or whatnot. It's here are the numbers. You can argue with the numbers and that's fine. But in general, I've found that if you have like pretty good conviction going into something and have some reasoning and some variation for like what can go wrong, what could go well, a lot of times it's just like, Your leadership is really going to appreciate that. They're going to say like, cool, we hired you to be this like smart and compelling person to go and do the things, go do the things, show them why you can do it, make sure that you, what you're doing actually delivers on what you're talking about. You don't want to be so far off in your, your values and your estimates.

Morgan VanDerLeest: That's another thing. Revisit some of these so that you can make sure you're not wildly off. But if you do that. This is going to go a long way with sharing, [00:53:00] like how you think about these decisions, how you go about decision making in general, and they bring in that tangible aspect to how you go about like proving the value and the worth that you're bringing to your organization.

Eddie Flaisler: And I think what you just said is a very important pillar of managing up, which is part of the work of every manager, not to say every employee, because your leadership team may have more or less bandwidth to dig into the actual math. But what's for certain is that you will come to the conversation with a lot more conviction knowing you did your homework.

Eddie Flaisler: So we covered a lot of ground today. We first identified when it is more appropriate to focus on innovation instead of blindly choosing it. Then we discussed the role and opportunity engineering leadership has in supporting innovation. Then we talked about the cultural aspects of building an adaptable engineering organization. And then we got into the mechanics of scientific prioritization. So you end up striking the right balance between building for today and building [00:54:00] for tomorrow.

Eddie Flaisler: I hope our VP listener will find this helpful as will others.

Morgan VanDerLeest: Yes, I think they will. And to the listeners, if you enjoyed this, don't forget to share and subscribe on your podcast player of choice. We'd love to hear your feedback. Did anything resonate with you? And of course, more importantly, did we get anything completely wrong? Let us know, share your thoughts on today's conversation to people driven development, that's one word, peopledrivendevelopment@gmail.com, or you can find us on X/Twitter @PDDpod. Bye everyone.

Eddie Flaisler: Ciao.

​