The Changelog: Software Development, Open Source - Product development structures as systems (Interview)

Episode Date: September 23, 2022

This week we're talking about product development structures as systems with Lucas da Costa. The last time we had Lucas on the show he was living the text-mode only life, and now we're more than 3 years later, Lucas has doubled down on all things text mode. Today's conversation with Lucas maps several ideas he's shared recently on his blog. We talk about deadlines being pointless, trajectory vs roadmap and the downfall of long-term planning, the practices of daily stand-ups and what to do instead, measuring queues not cycle time, and probably the most controversial of them all — actually talking to your customers. Have you heard? It's this newly disruptive Agile framework that seems to be working well.

This week on The Change Law, we're talking about product development structures as systems with Lucas DeCosta. The last time we had Lucas on the show, he was living the text mode only life. And now more than three years later, Lucas has doubled down on all things text mode. Today's conversation with Lucas maps several ideas he shared recently on his blog. We talk about deadlines being pointless, trajectory versus roadmap, and the downfall of long-term planning, the practices of daily stand-ups and what to do instead, measuring queues, not cycle time, and probably the most controversial of them all, actually talking to your customers.

Have you heard? This is a pretty good idea. By the way, yes, there is a bonus seven minutes at the end of today's show for Plus Plus subscribers. If you're not a Plus Plus subscriber, learn more at changelog.com slash plus plus. A massive thank you to our partners Fastly and Fly. Our friends at Fastly make sure our pods are fast to download globally because, hey, Fastly is fast globally. Learn more at Fastly.com. And Fly lets you deploy your app and your database closer to users all over the world. The best part, no ops required. Check them

out at fly.io. This episode is brought to you by our friends at Sentry and their upcoming developer experience conference called DEX. Sort the madness. This is a hybrid event you can attend in San Francisco or virtually on September 28th. They have an amazing speaker lineup. And I'm here with Sarah Guffles, head of DevRel at Sentry.

Sarah, what's the story with this conference? Well, coding is hard. We at Sentry know this. We integrate with everything that we possibly can to make that process easier for developers, to make fixing errors and performance issues actionable as quickly as possible. And we can't fix this. We can't fix the fact that coding is hard. We can't fix the fact that our ecosystem continues to grow and get ever more complex. So we created Dex.

Dex by Century stands for developer experience. And the goal here is to ignite this conversation, this community around the fact that coding is hard and that we need to come together as an entire industry to solve for the people problems, for the tools problems, for the process problems, whatever the problems are. We need to come together and share various solutions

and approaches to making that developer experience better. And that's why this year we have invited speakers only. We actually didn't have a CFP. We have Gishirmo, the CEO of Vercel. We've got April, who leads GitHub Codespaces. Jewel, who's been an engineering leader at Reddit for over five years. Divya, who is an incredible engineer and leader at

Fly.io, and so many more people that have just a vast amount of experience leading through chaos, leading through these moments of, oh my God, I just took down YouTube, or oh my God, there's this huge outage on Dropbox. And they have a lot of experience, knowledge, and suggestions for how we can get started on improving our developer experience. Okay, virtually or in person, either works. Save your seat now using this trusted Bitly link. That's bit.ly slash dex2022. That's bit.ly slash dex2022.

The link is in the show notes. So look as you're wearing glasses you said these glasses are your brand no one sees you though so this is an audio podcast first but we do have clips so listeners check twitter check youtube for clips but look as you're wearing glasses you said that your brand what's the story yeah so absolutely so um so there's there's not a lot of story about it to be honest you know I just kind of like the you know

Kurt Gendel vibes that they give me you know the slightly you know weird look that's what I'm going for Okay

so like Superman he's Clark Kent with glasses and then he takes them off and he puts the cape on he's so is it the opposite where you put the glasses on

you feel better? Yeah because you put the glasses on for the show yeah now you're superman you're super de costo whichever you want to choose yeah all the info is stored here you know uh quite a few terabytes of data yeah are those google what do they call them glass holes they're so dead now i can't remember the name oh glass holes yes is that google glass do you have your ar goggles going unfortunately not but i definitely get one of those in fact i do have a like some vr goggles here that i bought to try out like some of those you know um oh did you immersive uh workspaces um it doesn't work well by the way i was gonna say they're they're not in use though they're sitting in a box somewhere yeah the

resolution is not not that good you know so if. So if you're trying to do multiple screens and coding and all that kind of stuff, not that great. Yeah, wouldn't recommend. So we haven't had you on the show in a while, but I remember having a great time talking to you, I think it was like three or four years ago, all about text mode.

You're living your life in text, no GUIs. Are you still living the text mode life, or have you resigned yourself to a GUI here or there? No, absolutely. I doubled down on it. So yeah, I'm using, you know, even more weird shortcuts and more command line tools than I was before. So, I mean, like I do have to use GUIs every now and then, you know, because like Google Chrome and browser apps, but if I can use a terminal, I'll use a terminal. What does that say about the advice we might talk about today then?

I mean, is that, since you're obscure on that front, are you obscure in this advice? What exactly do you mean? Well, you've got some pretty hard opinions about productivity for teams and systems and you know, being effective, you know, things like that. So I figured if you're obscure in text mode,

maybe even double downing and extreming, you know. Yeah, absolutely. I'm very good at having strong opinions. They're held loosely though. Okay, good. That's good. Yeah. Well, I have to say I kind of pigeonholed you

into like a command line text mode, like hardcore programmer type. This is the way I thought of you. And I didn't pay attention for a little while. And then I started reading your more recent blog post. I'm like, dang, Lucas goes deep on engineering and software development and all these things that, I mean, like I said on Twitter to you the other day, you're really killing it with your writings.

Lately, I'm just curious, where is this coming from? I know you're an engineer at Elastic, but maybe give us a little bit of the lay of the land of your life, how you're drawing these strong opinions from. Yeah, so essentially I've been doing software engineering for a very long time. I am a software engineer currently. I've been a software engineer for many, many years. But in my previous place, I got to a more management-related role. So I was starting to have to think about how do I organize people? How do I make these people productive?

And how do I make engineers work well with photo departments? So as an engineer, I always thought of things as systems. You know, I always like to look at things and find, you know, the dynamics, discover what are the dynamics by which, you know, those things run. And I was lucky enough to have a very good engineer work with me who had kind of the same mindset and who was also in a similar position before. And he started recommending me all this content about, you know, agile metrics and actually how to see product development as a system. And then I started getting into it. I started reading a lot of Donald Heidner.

So if anyone here is interested in that, you know, Donald Heidner is, you know, by far, I think that the best person to go for this kind of content. Also Daniel Vacanti and started reading all that and started seeing things as a system. As I used to look at code, I started to look at teams. So that's the story. Well, like I said, your blog has been on fire of late. I've enjoyed tons of the stuff you write about,

your stuff on stand-ups, your most recent one, which I think caught fire as well around the world of programmers. Useful engineering metrics and why velocity is not one of them. I have been a longtime skeptic of estimates of velocity of points of a lot of the agile practices. And I think I was most recently on go time talking about velocity with Matt Reier and Natalie Pisonovich if people want more on this topic. But Lucas's thoughts are much more reasoned and explained, and I just kind of rant and rave about certain things. So kick us into this post.

Of course, we're not going to have time to cover all the stuff you've been writing lately. If you like good engineering blogs, load up your RSS reader, throw Lucas's in there, and enjoy as he continues to publish. But this one in particular lays out really not just why velocity is not useful but you kinda describe how we're all thinking about engineering and the process a little bit wrong and so therefore our charts are kinda wrong and

our metrics are kinda wrong and if we just change the way we think about it you can start to have some useful charts and graphs, which even define what useful means. So I'm doing a poor man's edition of what you wrote. Why don't you give us the strong man's edition of what you're thinking about with useful metrics and how we should think about these things? Yeah, absolutely. So essentially, I don't like velocity because basically Scrum is a way of insulating things and limiting the kind of like working progress. That's what Scrum is kind of about, right?

When you have these two experiments, you're limiting how much you're going to do in that time and it kind of like makes things easier to manage, but you can achieve the same effects if you're just doing Kanban. And that's kind of like the premise of this blog. So what I do in this blog is basically model an engineering team as a queuing system. So if you imagine the engineering teams in the center processing tasks, you know, tests are coming in on the left and they're coming out on the right. Essentially what happens is that if tasks come in more quickly than they come out, they start to queue. And when things start to queue,

you have more and more lead time and things take increasingly longer to be done. So one of the common mistakes managers do is to start more things when they see that things won't finish because they think, oh, we're not finishing enough, so let's start more things earlier, which then makes everything take longer on average. So what I do in those blog posts is basically model the system as the queue that I mentioned. And then if you plot on a graph where the x-axis is time and the y-axis is basically the quantity of tasks that you're either getting done or that are entering the system, you can see that the difference starts to increase the larger the difference between the rate of things coming in

and the rate of things coming out. So the greater that difference, the longer the queue is going to be and the longer the approximate average cycle time of things is going to be. So once you start looking at those, when you start looking at throughput, which is the rate things come out, and also the rate of things come in and you match those, then you're always going to have the same distance between the two bands and you're going to have more uniform cycle times because you're not going to allow queues to form too quickly. And when queues form, sure, then you can rely on the troops and get everyone to actually get the time down because otherwise that difference is going to accumulate and queues are going to get longer and longer and longer.

And then the longer the queues get, the more terrible cycle times get and you get even less predictable because if you imagine that things are queuing up, and then everything takes increasingly longer, you're not predictable because everything's going to take longer and longer. Whilst if the rates match, cycle times tend to be uniform. As long as you're finishing what you start, that's a very important assumption. Finishing what you start is important. Unfortunately, it doesn't always work that way adam did you track everything he said there because i was with him like 80 but i'm wondering about 70 let's say 72 and a half percent maybe 72.7 to be precise okay maybe maybe if i give a concrete example that would help that probably would help you so the magical thing

about kanban you know people usually think that the magical thing about Kanban is the Kanban board and you put the post-its there. That's the magical thing. Right. But that's not the magical thing about Kanban. It's very good. You know, it's great to visualize processes. It is magical. But the magical thing about Kanban is that if you imagine a factory, you know, that's producing cars, right? You're first making the wheels and then you're making, you know, the chassis and then you're making, I don't know, like something else. Basically, what Kanban does is it rate matches all these processes so that the pieces that are coming out of one place only come in on the other place when that place is ready to get them.

So if you're making a lot of tires, let's say you've made a million tires in a day. If the next stage of the production process is not ready to receive that million tires, you're just going to have a huge queue so what kanban does is basically they have these like kanban cards where they can regulate you know what comes in into the next part so that each part of the process weight matches and therefore there are no queues and therefore cycle times tend to be uniform now in software engineering the queues well they're, they're invisible. They're your backlog. They're like just bytes somewhere, right? We don't see the queues. But in a factory, it's very easy to see them. So that's the magical thing. And that's kind of like the whole premise of the

process, avoiding these queues to form and rate matching, seeing each part of the process as a queue. Gotcha. That's what it's about. Yeah yeah so one of the things you say is that you see product development structures as systems you said that earlier then you also say not as an art or a series of guesses and where i struggle with that statement is that in an assembly line of car manufacturers you know exactly what it is to create 100 tires and 100 rims. And you know that the rims have to come before the tires and et cetera, like all that is known. And so you can queue things up and you can work on them and then you can have your throughput and you can very nicely fit that thing into a factory. My experience with software is that it's not really a factory, is that it's more like

you're building a custom home. And maybe you change your mind halfway and you realize like, actually, there's a lumber shortage. And so like, there's so many unknowns, and so many interdependencies between the tasks, that it's difficult for me to visualize it in a simple things coming in, things going out. And you've been probably writing software as long as I have, and you're nodding along with me. So these are things you've considered. Can you speak to that, the complexity of the tasks and the interdependencies and the fact that you might change what you're building as you're building it?

Yeah, absolutely. That's a fantastic question. So I've even written about that in a blog post about uncertainty. So you do have unknowns. Now, the important thing is that you're going to make the best possible choice knowing what the unknowns are. So imagine, for example, that you're going to bet in a fight, right? You're betting on, I don't know, Logan Paul versus Floyd Mayweather, you know, whatever it is, right? We know that Floyd Mayweather

is more likely to win and that Logan Paul is less likely to win. That's what the odds are going to tell you, right? That's what the house odds are going to be. Right. Now, the bookmaker's odds. But if your model of reality is better than the bookmaker's, that's when you make money. So maybe the bookmaker thinks, you know, maybe Logan is 10% likely to win, but you think he's 30% more likely to win, right? That difference in the bookmaker's odds and your odds, right? The difference between what you think reality is and what the bookmaker thinks reality is,

that's when you make money. Now, it doesn't mean you're going to make the perfect choice, but it means that if you were to make that choice infinite times, would the payoff, you know, be good? So that's what you're trying to do with product development. Now, the other interesting thing about product development is that's what you're trying to do with product development. Now, the other interesting thing about product development is that you don't have to make a single large bet. You can divide your bets in multiple small bets, which is the interesting thing you've talked about, you know, the mapping dependencies and everything else. So when you're making a bet in a fight or in a horse race or whatever it is, you need to put the whole bet

down. Or like in a lottery, let's say, that's the example that Heinertsen uses a lot, the lottery. So if I ask you to buy a three-digit lottery ticket that costs $30 and you pay all the $30 at once, well, you have one in a thousand chances of getting it right. But if I offer you to buy each digit for $10, well, if you get the first digit right, you're not gonna buy the second.

So you can truncate bad bets earlier and and you're going to save some money, and you still have the same chance of winning in the long run. And that's, again, why I say that scrum is kind of like just one way of doing it, because you're insulating yourself. You're limiting yourself. You're not making those big bets. You're working in sprints. Right.

Some people, they end up doing waterfall disguised as scrum. There's a lot of insane here. The real Scrum is not supposed to be like that. So you are going to be making decisions with incomplete information. But the important thing is that you know what the expected value of the batch you're making is. Because in product development, value comes from uncertainty. As you mentioned, distribution is free. So there's a linear function of value delivered as you make more cars.

Right. When you make product, distribution is basically free, right? You're just pressing a button, it's shipping, you know. That's the magic part. Exactly. That's the magic part. Now, there's another vector of value that you get when you're doing product development. So in cars, the value is linear.

But when you're doing product development, So in course, the value is linear. But when you're doing product development, you can increase the value of all the new products that you're going to ship, because you're building the recipe for the product, not the product. So you actually end up with a new vector of value that you can deliver not only to the customers that you're going to acquire later, but also to the customer that you have already acquired,

which is the whole magic of software as a service. Yeah. If you're Microsoft selling Windows before, well, yeah, to the customer that you have already acquired, which is the whole magic of software as a service. If you were Microsoft selling Windows before, well, yeah, you cannot improve the previous version of Windows. But now with SaaS, you can just ship improvements to the previous version, charge more from everyone. That's where the magic is. Existing customers get to layer on new and better improvements as they use it over time.

And new customers get to enjoy a great product today. And then they begin the cycle again and again. Absolutely, absolutely. And there's multiple ways of breaking down your bets. You can do some A-B testing. You can ship things to a smaller percentage of users. You can ship kind of incomplete things to small percentages of your users, see how that performs. There's multiple ways of breaking down

uncertainty. So you're always going to have uncertainty because that's where value comes from. But the important thing is not that you eliminate uncertainty because then you eliminate value, then you're working on an assembly line, of course. The important thing is that you minimize the economic impact of uncertainty without hindering the benefits. Because that's where value are. Because when you make bets that are unlikely and they turn out to be correct, that's when you make money. That's when the fight example comes in again. When your models of reality are correct, and the rest of the world's models are slightly different from yours. That's where i

get those sayings like fail early fail often right where it's like okay i want to make a bunch of small bets and i want to validate or invalidate those bets as fast as i possibly can so we we iterate and we focus on our feedback loops all that makes. And I think that speaks to the uncertainty part. What about the interdependency part? So we're back to now our queue system and we have requests coming in. What do you call that? Arrival rate. We have the rate of arrival of let's just call them features. And then you have the departure rate. Is that what you call it? The, the throughput, like when it's, and the cycle time is the time it takes to get through that on average, right? So let's say I got three tasks coming in, but task B requires task C to be done before it.

And that's about as simple as you can get with a dependency, right? Like, well, A is fine. We'll work on A. B we can start right now, but C requires B. So CQs. Does your charts that come out of this concept, the cumulative graph, what's it called?

The accumulation? Cumulative flow diagram. Yeah, does your diagrams and does your view of this system, does it account for interdependencies? Does that matter? Is that a moot point similar to uncertainty? Like you're always going to have uncertainty, you're always going to have dependencies,

but actually the times are what counts, so that would be the answer. Answering for myself, I'll stop. What do you think about this? Yeah, absolutely. So in that case, you will have to get it done after you know you will have to get c done only after you do b there's there's no way around it now that won't make a difference in the long run as long as you finish what you start so as long as you're finishing what you start because littles law which determines basically like littles law can be formulated in a bunch of ways,

but the way I'm using it in the blog post basically says that if you start more things, we're going to have longer average of cycle times, right? If throughput keeps constant, because you can't simply ask developers, oh, let's do more, and then throughput goes up magically. That's not what happens. So as you add more tasks, the average time goes up. Right. So yes, you're going to have some tasks queuing, but as long as you

finish all of them, so work never gets to zero when you're doing your job, right? You always have a queue for it. But as long as you're finishing what you start, the average cycle time in the end is not going to matter much because it's a relationship of averages. So the important thing I'd say is not that you cannot have dependencies, it's that you cannot have dependencies too far into the future. Because when you're making long-term plans, the problem is that you're assuming reality is going to be in a particular way. And reality doesn't care much about what people think it's going to be like. And that's where, you know, that's where most plans fail, you know,

because if people could just, you know, forecast, yeah, like if software was a deterministic activity, things would be very, very easy. So you cannot do that. So if you can shorten your time horizons, you can still have multiple dependencies. And I'm not saying don't have a strategy. You can have a strategy.

I'm just saying, you know, you need to be adaptable. So that's what the whole agile thing is about you know agile is not about being fast it's about being adaptable so it's not that you cannot have dependencies or anything like that it's just like the more you can shorten your planning horizons the better things will be the easier it will be for you to adapt to to new situations this is the difference between trajectory and roadmap roadmap is a plan concrete whereas trajectory is, I think we're going this direction and we may land here. Our arc may change.

We may land there, but it's where we're heading. It's a North Star. But along the way, we may zigzag to get there. Exactly. That's the difference. Exactly. That's an excellent way to put it. David Hadamard Hansen said this a while back.

This is not like new news. I'm not saying that you can't take this and coin this by any means, but like way back in 2013, there was Startup Squad, I believe, where DHH was talking about planning as guessing. And then they said it again, I think in one of their books in Rework Potentially.

And then again on their podcast in 2021, where planning is guessing. So like, this is kind of like, almost everybody knows you shouldn't plan, you should trajectory essentially. But is this systemic? Is it like a big issue? Do you think people roadmap versus trajectory?

So I agree with him. I do think you should have the direction in which you're going. And now how are you going to get there? You know, things are going to get in the way. You know, you're going to have to be creative about which strategies you're going to use to go into that direction and continue to make progress. Now, the problem is not with setting the trajectory. The problem is

when you say, like, we're going to go from point A to point B in X amount of time, because then, like, one of the dangers that you have is that you might be incentivizing the wrong thing at all costs. So like, if you, I don't know, imagine you have a sales target and your sales target is X at date Y. Someone that gets to that target on that date, no matter how much they fluctuate and how many people quit because of the attrition and how ruthless that person that wants to achieve that goal is,

that person is going to achieve that goal. That's the problem with having a long-term plan. And also, reality doesn't care that much about what you think. So that's one problem. Now, if you're measuring direction, you know, if you have a predictable sales machine, you know, if you want to use the Aaron Ross term, you know, if you have like predictable revenue and you're going up,

but maybe not at this rate, you know, maybe you're not going to achieve this deadline, you know, if you have like predictable revenue and you're going up, but maybe not at this rate, you know, maybe you're not going to achieve this deadline, you know, at that particular date, but you're going in the right direction and you can make small adjustments, you know, to increase the slope and make it go up. That's better than having, you know, an erratic machine that hits the goal. So that's what I like about setting a trajectory and having metrics that actually measure, you know, consistently how you're performing against that rather than just saying whether you've reached a particular end state or not. So people need to be very careful with their metrics. You know, that's another thing I say on that blog post, which is, if you're just looking at metrics and you're managing exclusively by then,

you know, you're going to make wrong decisions. Because I think Deming has this quote where he says that the measurements of productivity in the United States don't help increasing productivity in the United States. You need to look at the systemic causes of those problems. Metrics, they serve as an intervention point, as a trigger point. So they tell you something looks weird here. Maybe should go and look you know figure out what's weird that's how i see metrics and that's why i think it's important to get metrics that reflect a direction rather than setting a particular goal at a particular time and chasing it at all costs yeah let's do a

hypothetical here so let's say i hypoth, I'm your product manager or engineering manager. I'm above you in some sort of situation. And you're either an engineering lead or individual contributor, whatever you are. And I say, Lucas, we aren't moving fast enough. What are the choices? What are the options? What can we actually do about that? So I think the first question I'd ask you is, what does fast enough mean? What are your goals? I try to understand exactly what you mean ask you is what does fast enough mean? Like, what are your goals?

Like, I try to understand exactly what you mean by we're not going fast enough. Because sometimes we're not going fast enough can mean we're not, you know, delivering enough engineering value or we have too many bugs or we're not achieving this particular business goal. So I need to understand first, what is the goal exactly that you want to achieve? Like, what do you mean with going faster? So since we're making it up, I'll make up an answer so we can continue the conversation. So we're trying to get this new website design rolled out by the end of the quarter. And everything I'm looking at and whatever metrics I have and talking to everybody, it sounds like that's not going to happen.

So we're going to move faster. So first thing I advise is that we look at that problem from when we set that objective. From the first moment we start that project, I will start looking at what our metrics are. Not only our metrics, but getting qualitative assessments on how we're performing against that. Not only when we see we're not going fast enough,

but I will monitor us throughout the whole process so that I can see as early as possible when something goes wrong. I think that's the first thing. Now, let's imagine, as you mentioned, that things have gone wrong at some point. So we're in the middle of the project, something has gone wrong.

So first, I try to think, make a qualitative assessment and look at my cumulative flow diagrams to see whether my assessment makes sense with the metrics I'm seeing. You know, maybe you're seeing a huge increase in tasks in the testing stage, right? Maybe that's the problem. Maybe things are queuing up in test. Maybe things are queuing up in deployment. And then if that's the case, imagine things are queuing up in deployment. You see a huge increase in the size of that bench. Well, then it means you're accumulating lots of tasks to do a deployment all at once, right? Because that's too painful.

You're letting things accumulate, so you can do a large batch transfer to production. Maybe that's a problem. And then when you start adding up lots of things, well, you have a larger delta for errors. So that's one way in which the system can be broken. Now, there are plenty of ways in different parts of the system that things can be broken. So I'd look at the cumulative flow diagram to see the size of the beds, see if anything

is skewing up, to see if there's any particular parts of the process that are painful, and try to get some more predictability, try to make things more uniform, so that maybe we'll see, well, we're not going to be able to hit the deadline with all these features that you initially said. So we need to make a compromise, right? Because one of the things that people get wrong, I think, is that they can simply turn the dial

and things will go faster. But every system will only produce what it can produce. If you just tell people to work harder and do more it's not going to make any difference like no one cheers for their cpu to process numbers faster you know systems produce what they can produce regardless of whether they have a goal it's kind of like that scene from uh return of the jedi have you seen that when darth vader comes up and he's talking about getting the death star back on schedule. Have you seen that one? No, I haven't seen that one. No, I don't remember at least. Yeah.

And he's like, he's reprimanding a general. He's like, I'm here to get you back on schedule because the Death Star is not being done fast enough, according to the Emperor. And I think the guy says something like, we're going to redouble all our efforts. And Darth Vader is like happy with that response. It's like, you can't just redouble all your efforts, right? I guess like we could work, we could all work twice as hard. I guess sometimes people do try that, right?

Yeah. He was saying that before, like you have attrition because of the pressure. And that's almost what you did too with your questions. Like, hey, you know, we didn't hear it, but it could have came off as Lucas, what's going on here? Why are you taking so long? And then you put the pressure on Lucas. Lucas goes back and puts the pressure on everybody else.

The next thing you know, you got two people who are ready to quit already for sure going to quit now because now you put the pressure on and you got, that's the, you know, you can't simply turn a dial unless that dial is well known. And I mean, you can say, well, we're going to hire more people on this project. Sometimes that works. Sometimes it doesn't like the old mythical man month, right? Like more people don't necessarily increase velocity. The other thing is, which was where you're getting Lucas was we could change the scope, right? We could reduce scope. Exactly. Or we examine what we all assumed was a good deadline or a good cycle. I'm not sure which word you're using Lucas, but like something we all agreed on is what you were saying before,

like, what do we agree on? And where are we at from that? Is, are things queuing? Are things getting backed up? You know, where, where's the pain at essentially so that you all can come to the same table and say, okay, this will be agreed on that would happen with an X. And what, why is that not being achieved? Yeah. And you can, the one important thing is that you cannot control the result, but you can control the process. Right. we can do the most valuable things first so that we can have a predictable rate of delivery so that if anything goes wrong, we know early and then we can negotiate scope and then we can get the best business results. And that's my problem with long-term plans and why I say that long-term plans don't work

in that other blog post. Yeah. So when we come to the point where we have the meeting and we all decide we're not going to hit our deadline or we need to move faster or something, something has to change, right? We've now realized either subjectively or experientially or maybe through some sort of metrics that we are behind what we thought we would be. Reality didn't agree with our plan. It's too late for any of that, right? Like we've, the correct thing would have to go back in the past and fix what the problem was back then,

but you can't do that. So starting right now, how do we change the process to address this problem and move forward from here? And what you're saying goes back to the many bets thing, right? It's like, well, the big plan, like why didn't we notice this for six weeks or whatever it was?

Well, we weren't checking our accumulation charts enough to realize that actually this thing was queuing over here and now we're addressing it, but we could have addressed it three weeks ago and solve the problem. Well, let's just stop right here. Some cost fallacy, fix it right now, change our projections or change our scope or change the number of people that are working on it or pay people more to work more on it. Like those are kind of the levers you have. But what you're saying ultimately is the system should be designed in such a way that these things are noticed and adjusted for small course corrections along the way versus that

big, oh crap moment when you realize you're going to miss your deadline. Yeah, exactly. Exactly. Like you cannot decide, well, I'm going to go to the gym today and, you know and in a year I'll be, I don't know, like I'll look this way. Right. But you can control yourself so that you do the things that, whatever the plan that you have is every single day so that maybe you will not get to that exact place

at the end of the period, but you're going to do it in the best way possible and you're going to adjust along the way. That's what i'm saying maybe like and also that's there's there's different types of projects so if you believe if you're building a product well maybe you don't need to set particular goals you know in stone right you can make small improvements now if you're working as an agency it might be a little more difficult for you to make your clients agree to not have a particular deadline, but to work in a particular way, which, you know, some agencies do, which is, you know, and that's better both for whoever's like outsourcing the work and for whoever's receiving the work, because then, you know, they can agree on what's more

valuable for customers and, you know, they get a longer engagement, the company gets more value, but, you know, there's different circumstances. It's hard to say there's a silver bullet. Hey, friends, this episode is brought to you by my friends and potentially your friends, too, at Fire Hydrant. And I'm here with Robert Ross, founder and CEO of Fire Hydrant. And Robert, there are several options out there for incident management. But what is it that makes Fire Hydrant different? The reason that we think that FireHydrant is on to something is because we're meeting companies really where they are. We face the

same problems that every company in the industry that is building and releasing software is also facing. So we want people to be able to sign up for FireHydrant and immediately be able to kick off an incident using the best practices that we've built and we've experienced and have gathered through the other amazing customers that use our tool. It really is a very quick time to value. And we want people to have a long jump from where they are to where they want to be in incident management. Well, we do have good news. Small teams up to 10 people can get started for free with all Fire Hydrant features included.

There's no credit card required to sign up. They are making it too easy to get started. So check them out at fire hydrant dot com. Again, fire hydrant dot com. you mentioned in that same post alternatives essentially to the long-term plans and one you said was planned more carefully which which seems problematic. And then the other one was have a larger margin for error, essentially. And as you describe how you can plan more carefully, you seem to unravel why it actually doesn't make any sense to plan more carefully. Because costs either go up because you spend more time planning and you were actually wrong anyways. But the other seems to be the alternative is have a larger margin for it is either those right.

Are they both wrong? I'd say I'd say both. Like, so I'm not sure if I like the word wrong. I'd say they're suboptimal and the amount by which they're suboptimal for rice. Yeah. So, you know, I'm not saying you should not plan at all. I'm just saying that over planning is better.

That's what most people do. You know, usually you need less planning than you think in terms of like setting particular goals in stone at a particular date, because you're just going to spend more time trying to bend reality and try to think of all the possible edge cases. And something is going to go wrong. Like you cannot predict all the possible outcomes that reality can give you. For you to do that, imagine the decision tree you'd have to make

to model reality properly. It could be even infinite if you're going to do it the ways of physics. I don't know. But that's why the long-term plans don't work. That's why planning more carefully usually doesn't work. So I'm not saying you should not plan.

Planning has its place. It's just don't over plan. And making the plan more careful doesn't prevent delays. That's one thing. Isn't this where sprints and scrum, I think you may not be a fan of scrum, if I can read your words correctly, but isn't that where sprints came into play

where you can say, well, they thought, well, sprints meant fast. Well, it's actually more a measure of time. And you say, you know, essentially make the plan shorter so that you can find out if you're wrong faster. Kind of back to what Jared said before, just fail faster. Same kind of mentality. Exactly. But like the important thing is that you don't need Scrum for that. So Scrum is kind of like I see it's kind of like a management training wheels because it gives you good practices out of the box. You know, just follow the good practices and it works.

But if you understand the principles of why it works, you can make Kanban work in the same way. You know, as long as you don't create a longer queue and you're always revising what you're going to put into the queue, maybe you can have even faster feedback. And you don't need sprints to have meetings at a particular cadence. You can work without Sprints and you can still do retrospectives every X weeks or... But what do you call them then? If you don't call them Sprints, what do you call them? Yeah, it's harder to sell workshops. Right, exactly. I like that. Yeah, we'll get to that too. I love that blog post you have later on about that. You have to have a name for something, right? You have to call it something.

And sprints seems to, even if you don't practice Scrum, you're borrowing the names, the terminology. Even if not the full framework, you're borrowing some parts of it. And you're almost Frankenstein thing. You almost are Dr. Frankenstein making the monster. Next thing you know, it's Scrum Kanban, whatever else there is, like something programming, extreme programming, like all these different ones.

Next thing you know, you have a monster in your hands. Yeah, absolutely. And by the way, I'm not saying Scrum is bad or anything. The book is brilliant. The principles are sound. I'm just saying that if you understand the principles, you don't need to do Scrum by the book, which is by the way, what most people do anyway. You know, it's very rare for you to find

someone that does Scrum exactly as it's written in the original book. But for you to adapt Scrum, it's, you know, you must understand the principles so that you do the correct adjustments. Yeah, that's what I'm saying. I think it's interesting that the term sprint has been somewhat maligned amongst people that I've spoken with because of what you said, Adam, is like, why are we always in a hurry all the time? There is a sense of urgency in the word sprint, but the original point is the small iteration time. It's like we're not going to spend three months on a thing.

We're going to actually regroup after two weeks or one week. But I think that can be problematic when what you think about it is like we're sprinting at all times to everywhere and there's no sort of like stop and catch your breath. There's no time for refactoring, for testing, for all these other things that are

like part of the software development life cycle. And that stuff has creeped into the culture, I think, of software development, where it's always a sprint. And sprint doesn't merely mean we're going to go for a short period and stop. It means we're going to go as fast as we can at all times. Think of this from psychological standpoints, too. If you're always being pushed into a rush,

if your boss is always making you move fast you have no time to be deliberate you don't have you know what i mean like the the psychological standpoint of being in a rush being rushed never being on time always hurry hurry hurry psychologically you're in a state of defense not really offense right so if you're even the terminology is sort of like bad from psychological standpoint yeah well think about it with tdd i mean i've had this where i've been in a rush and i do i practice uh what hello wayne calls soft tdd which is not like the real stringent uh by the books tdd i adapted a little bit but if i'm being honest you know, the TDD loop is red, green, refactor. And if I'm flowing and I'm moving, I'm trying to get something done.

If I'm honest, it's like I'm more like red, green, red, green, red, green. And the refactor just doesn't happen because I'm in a hurry. And that's like, you're doing it wrong, man. But we tend to do that, especially when we have external pressures to make us move faster. We're trying to redouble all our efforts. Or you don't like the refactor. Forget that, man. I'll pay the debt later.

I love refactoring, but I never have time to do it. I got to move on to the next thing. It works. Yeah. But there's a confession for you. Lucas, are you a TDD guy? Yeah, yeah. So I've written a whole book about testing.

And I've written quite a few about testing and I've, I've written kind of quite a few, uh, libraries, uh, related to testing as well. Did a lot of contributions to Chai and Jest and, uh, and Cy, and, uh, SignOn as well. Um, so. Do you ever find yourself skipping the refactor step? So it depends, uh, sometimes. Um, but like, it really depends on what I'm coding, but I, I, I don't also follow it exactly by the book, you know? And I I'd I don't also follow it exactly by the book.

And I'd say if you're following it exactly by the book, actually, it's all what most people think. If you actually go and see what Kent Beck initially said... You got to fail that test. Yeah, but if you go and look at what Kent Beck initially said, he just said, yeah, your test size matches how confident you feel about your code. So you don't necessarily need to write a very small test and always go through the whole loop in all these small iterations every time.

You can adjust it to how confident you feel. So that's, in a way, TDD by the book, if you consider Kent Beck's original book to be the book. Right. I guess TDD by the new book, wherein every step is important and you must be as stringent as possible or you're going to design it poorly. I know there's plenty of people that feel that way. I tend to be a little bit looser with it.

But maybe you just write your code right the first time. Who needs to refactor? Because I just write it right the first time, right? Yeah. One other thing that I wanted to comment on, by the way, was your observation at the moon on always being in a rush and always being busy. So there's also another way of putting it

in this queuing system that we're talking about. Because if you imagine that the processing system in the middle is going to be very busy at all times, it's going to be always at 100% capacity. If that's the case, when something comes in, it queues.

And then things start to pile up and then you have longer cycle times. So actually, what you mentioned about being busy all the time is also counterproductive from a concrete standpoint, from a mathematical standpoint, right? Because if your system is at 100% capacity, it means everything that comes in queues, because the system is completely busy. So operating your system at maximum capacity is exactly what causes queues to form. And that's also some people say that that's why Google has the 20% time

because the optimal utilization rate that you should have is 80%. So if you have 20% time, all of a sudden you have 80% utilization rate. So you have some margin there to deal with urgent things coming up and you don you have 80% utilization rate. So you have some margin there to deal with urgent things coming up and you don't have as much queuing. So there's all that as well involved in, you know, not making people busy all the time. Besides all the other aspects of like creativity

and drawing work and everything else, there's also a concrete benefit to not making people busy all the time. Jared just shared his, He just created a queue himself. He was like, I'm too busy to refactor. Red, green, skip, skip the R. And he just said, he just admitted he's creating a queue right there because he's too busy. He's overutilized. He needs to move on to something else that's-

Refactor later. Yeah. So there's a queue there for refactoring. At some point there's debt that he pays. Or somebody else pays the price. Or it never gets paid and stuff dies. Yeah, exactly. So Lucas, you were talking about the two strategies. I guess we got you on the first one, which is the plan more upfront. We never got to the second one. You're going to respond

to Adam with regards to the relax your constraints or relax your expectations. How do you phrase it? Give yourself more margin for error. Margin for error, that's what I'm thinking of. OK, yeah. So essentially, when you're giving a larger smidge, when you're adding just margin for error, you're exchanging the possibility of being late for the certainty of being late, just

so that you have this small buffer that you can You're exchanging the possibility of being late for the certainty of being late, just so that you have this small buffer that you can write work to. Now, in terms of optics, if you're an agency and if you need to agree to a particular date, or if you need to commit to a date, sure. If you do need to commit to a date,

well, you need to pick a date and you're not going to pick the date that you're more likely to fail. Yeah, what's your upside? Right? Yeah, exactly. Exactly. Exactly. But in that case, you need to acknowledge that you're going to exchange

the possibility of being late for the certainty of being late because you did add the buffer. Now, one interesting way to see this, which I cover in another blog post, is basically trying to use Monte Carlo simulations to make these forecasts. So instead of you just looking at the task and saying, oh, I think this is two story points. Oh, no, I think this one is three story points worth.

And then you get into this endless discussion, and then someone says, oh, no, this number is not valid, because it needs to be on the Fibonacci scale. Why? No one knows why. It needs to be the Fibonacci scale. Right. No one knows why. It needs to be the Fibonacci scale. Right. But.

Because the book says so. Yeah, because the book says so. Now, some people say, oh, because complexity is not linear or the. No. We're not good at estimating. Let's just acknowledge that. It's just the way things are.

So that's one way to estimate things. Now, if you're using a Monte Carlo simulation, you can just get your true perch. You know, you can see, like, how many tasks you delivered on each day, and you can simulate over a particular period of days, and you can see the outcomes you get in all the simulations. So you can run, like, I don't know, 100,000 simulations,

however many simulations you want. Computers are pretty fast these days. So you run all the simulations, and you see, oh, in 95% of the simulations, I ended on or before this date. So you can kind of say I'm 95% confident that I'm going to finish until this date and then you can define what your buffer is, depending on how much confidence you want to add. Now, it's very difficult for you to say you're going to have 100% confidence even

if you pick the last possible date that your simulation gave you, because, well, reality doesn't work that way. But what you're doing when you simulate your team delivering that on a Monte Carlo simulation is basically, instead of just actually delivering once, you're simulating, well, if the past looks like this, and I think the future is going to look like the past. Now, in 100,000 situations in which I'm trying to deliver these things, what are the possible outcomes that I get? And then you use that to make your estimation. So that's one way of doing it. But if you don't have to commit to a particular date, don't. Just break down your experiments, you know, because there's no point in committing to a particular date if you're still,

you know, experimenting things and seeing what works and what does not, because then if you do that you're more adaptable, right? You can change along the way, and maybe that's not the exact place that you wanted to get to by that date maybe something else more important so that's why it's important to know how to break down experiments and be agile in the true sense of the word

In regards to setting a time frame though, there's a law. Since we love laws around here, it's called Parkinson's Law. It's the old adage that work expands to fill the time allotted for its completion. So basically, if you set a time limit, you're almost destined to use that time. Exactly. You'll probably procrastinate to the last day, finish it at the 12th hour, 11th hour, whatever, because that's the amount of time you allotted for it.

But isn't that also why deadlines are useful, though, too? Because we've got to draw a line in the sand. They are useful. Arbitrary deadlines are useful. You've just got to be able to remember that they're arbitrary and pick a new one if worse comes to worse. But hitting something definitely makes you work, I guess, more effectively to a certain extent

or with more urgency? Well, there's an end in sight. Like there's something that's going to happen. Well, the reason why I think it makes sense to say that is because it kind of comes back to you. So you're preaching systems and creating products has to go through a system. It is a system, right? But at the same time, we have to be human, right? So your team, I can't expect you to be a machine, Lucas, But at the same time, we have to be human, right? So your team,

I can't expect you to be a machine, Lucas, even though you're an engineer, you can program a machine, but you are not a machine yourself. So I have to, if I'm your manager, let's say I'm taking Jared's role here, I'm his boss or something like that. I can't expect the two of you to just somehow meet these crazy things. We have to look at the details and be able to be, you know, flexible and resilient in change because the system can predict certain things, but we also have to be flexible enough to be human to say, well, we have systems that are reliable in place, but if we can't plan more carefully and the time we set for ourselves, if both of those backfire we have to be

human and say well something changed here and it's not your fault my fault or their fault it's just that's how it is creating unknown systems while we're driving the car essentially you know so we have to be human in this process exactly exactly i i do like to say that you know there's no coding solution to bad culture. There's some things you cannot solve with tools, you need to solve with culture and with a particular way of working. I totally agree with that. Now, with regards to what you said about deadlines,

I don't like seeing things as deadlines. I like seeing things as preemption points. So when your operating system starts running a program, it doesn't know when the program is going to end, right? That's the whole, if you do, you're going to get a Nobel Prize. You're going to solve the, I don't know how to pronounce it, problem, the halting problem. But the computer simply doesn't know if the program is going to finish running. So it just knows that it's going to run

that program for a particular amount of time, and then it has a preemption point. So it's going to interrupt that program, and it's going to start running other things. And you can do the same in your development process. You can start a task. If the test takes too long, well, you have a preemption point.

You have this, I don't know, maybe you set a limit in JIRA, which makes a preemption point. You have this, I don't know, maybe you set a limit in JIRA, which makes a task go red once it reaches, I don't know, five days in progress or something. And then at that point, you have a preemption point where you say, why is this taking longer? Is there anything that we can do to deliver now? Do we need to cut scope? Are we trying to solve something that was not originally scoped? Did someone misunderstood something here? So you don't need deadlines to have preemption points. And having those preemption points is the important thing.

That's how I see it. What's the difference, though? So the difference is the deadline, it needs to be finished at that point. Well, it's in the language. Dead. Dead is in there, right? Deadline versus preempt, which is to prevent. Right. So it's probably just in the language itself.

Yeah. So preemption allows you to control things along the way because you cannot determine. So the problem with the deadline is that you cannot simply just like get all the way here. And then you say, oh, we didn't reach the deadline. And then what do you do? There's nothing you can do. You didn't hit the deadline. You change it. That's why I said you have to realize that it's arbitrary if it's an arbitrary deadline. Yeah. Yeah, exactly, exactly, exactly. You need to realize, yeah, and in fact,

all deadlines, they are arbitrary in a way. Yeah, but that can be, my point was that that can be useful in the case that you need something to motivate you to finish a thing because of Parkinson's law, as Adam stated, is we can just continue to toil away and become engineering astronauts or architecture astronauts

or whatever it is. Without a deadline, we're never going to ship a thing. I just know that personally. I just never do it. So I have a nice deadline. We do this Kaizen episode of Ship It every 10 episodes,

and we try to work on things around changelog, make them better, the platform, the systems, et cetera. And I know that every two and a half months, we're going to go on a podcast and talk about what I accomplished. And so when that sucker is coming up, like we're shipping stuff, you know what I'm saying? Like that's arbitrary. Like we made that up. It means nothing. I could go on that show and say, didn't ship anything this time and nobody would care. But it's very useful as a motivating factor for me to finish some stuff that was my point is sometimes arbitrary deadlines are very useful things now you have to realize they're arbitrary and so maybe that's why you prefer to call

something else but we did because we just won't finish stuff half the time you know like if you're like finish it whenever it's ready like it's a posture thing right isn't it a posture thing you have a different posture to a deadline yeah as you have to a preemption point. And in your case, Jared, I can totally see the usefulness in the systems point where there's many people, not just you. Preemption points might be more like, did we ship it? Why didn't we ship it? How can we ship it? Do we need to move things? You know, it's a posture. Yeah. I don't believe we should just have one deadline six months from now and then check after six months. I believe in the iteration process and stopping and retrospecting. We had a thing called deadline and pray. You put a deadline out there and just pray you shipped it, okay? Deadline and pray. Yeah, exactly. That's hilarious. Preemption is, I like that. Preemption point is pretty, I think it's a good thing. But I also like deadlines too. As long as you don't get fired for missing one, right?

The psychological effect, it is the same. Maybe deadlines is an easier name to understand. More people get it straight away, so maybe it's better. I'm 40 years old. I haven't heard of a preemption point until today. So deadlines, I think more people are going to connect with that. Although I'm always open to learning new things. So that's interesting. Well, there is some pressure with deadlines too. It's like, you know what? I got to get this thing done.

Yeah. At what point then do we talk to users? Like we're just in ourselves right here, right? We're in our own teams. Like, did we ship? Why didn't we ship? Can we be more careful? Can we give us more margin? Can we shift the name from deadline to preemption

point to just soften a little bit? You know, can we be a little psychological? But at what point do we actually talk to customers and get their feedback to iterate and essentially see if our assumptions were correct and to fix their problem? So I'd say users are always the best source of feedback. Now, it doesn't mean they're going to tell you exactly what's right or what's wrong. That's for you to figure out. But it's your job to go and talk to them to get some feedback. So it's not your job to go and crowdsource solutions, but it's your job to go and see

what the problems are so that you can design the best solutions. Because if people could design solutions themselves, they would do it. So whenever you need feedback, instead of just confabulating in a room with 10 other developers and discussing what would be better. Well, if it's like a small enough piece of work, why don't you just ship all of them and do some maybe testing? Or why don't you just ship the easiest possible option and see if people use it? Because I've seen it quite a few times where you've built a feature, you shipped it, there was a lot of pressure to deliver that feature, and you're now thinking, everything went great, the feature is out, people will love it. And then that feature breaks. But you only realize the feature was

broken a few months later. Well, in main, no one told you the feature is broken, no one was actually using it, no one even noticed the feature was broken. So instead of confabulating and trying to just guess what users like, maybe go and get a feedback early and that's part of what we were talking about making the smaller bets, buying the cheap tickets you know one at a time so whenever you need to break down your plan and get that small quick feedback you know go and talk to users i like the way you presented initially which was you had uh this big this big deal soon you'll be calling it a 500 page book with diagrams you're gonna convince

people it's a framework we're trying. Then you're going to sell them a workshop for 50 grand, which will do a fireside chat with the CEO or something like that. And then you'll, I just like the way you presented the whole entire idea. It was pretty cool. When it's just really just a TTYC. Yeah, I'm still up for the $50,000 workshop. Still up for that?

You're for hire. Yeah. If you pay $50,000 for me to go and do a workshop of a one page blog post, we may be able to chat. The thing is though, Lucas, you don't understand how often that is the exact issue.

I know of a case recently, good friend of mine, situations in defunct, and iterate, iterate, release, new product, pivot, all these good things, all those keywords. Are you talking to your users? No, no, no.

What? How are you not talking to users? How are you burning cash? How are you losing in the game? How are you so close to the red line and you're not talking to customers or anybody who's even using the thing, let alone a customer. How are you iterating?

How are you pivoting? How are you putting out new stuff if you've never talked to anybody? Let me psychoanalyze real quick. Not your particular friend, but in general. Please do. I think we're afraid of what they're going to say. Yes, 100%. Yeah, I mean, we want to be right. We want to assume we know exactly what needs to be shipped, or we want what we want in the world, not what they want in the world.

Right. That's probably the cases, but I suspect your assumption is probably more correct, which is fear. We don't want to hear that we're wrong. We don't want to hear that what we're making is not right, not solving their problems, because that's just too hard. Especially when you got a big bet on the table. That's why smaller bets, or at least a good reason to go to smaller bets. Yeah. I mean, I think you fear talking to your people because, well, all the work you put out there was in vain. The work you are putting out there is in vain. Yeah, hurts. But what hurts more to Capit is failure, complete failure. That hurts way worse because now you have no opportunity to serve the customer because now the relationship is gone. The company is dead. There's no trust in the market. There's no trust in the product and you've lost your chance to win. So talk to your customers. A stern warning from Adam Stack.

Lucas, as an addendum to this post, you're talking about velocity, how it's not a good metric. I love at the end, you actually define what makes a good metric. One of these I've keyed in on a long time because a lot of times, even Adam and I,

we look at certain metrics or we're like, here's a chart. Should we track this? Should we track that? And one thing we always ask each other is, is this actually going to change? Is this knowledge going to be actionable? Are we going to change our activities based on the chart?

Or is it simply to feel good or be curious or whatever? Stare at a dashboard. And I love these three characteristics you list out. That one in particular, number two, it's actionable. The first one you say is it's not a target, which we have talked about Goodhart's Law many times on the podcast. It seems like it's so relevant to so many things. But the idea there is if you're tracking velocity,

like we got eight points done last week, and your boss likes that number eight, but they don't like the number seven, well, you're going to find a way of making that number be eight the following week or whatever it is, like we just game these systems. So those metrics, velocity, if it is just based on a number, not very useful in that way. And then the last one, you say it has a clear relationship to other metrics with characteristics one and two. Can you explain that one in better detail? So we have one, it's not a target because then it gets gamed. Two, it's actionable, meaning you can look at it and actually change something. And then the third one, can you explain that one?

Yeah. So essentially, if you have a single metric for a system, there's many other ways for you to improve that metric by making other metrics worse's many other ways for you to improve that metric by making other metrics worse. So you need to establish some boundaries, some quality metrics to get there. And the important thing is that you know what the relationships are between your metrics so that for you to get to this place, you know what leverage you can pull to get to this place and how getting to this place is going to affect your other metrics. So for example, you know, if you're going to start more things, well, if you're going to start more things, if you're going to finish early, well, if I increase the

arrival rate, what happens to the other metrics? What happens to my system? How are people going to work? Is that actually going to get me there? And if it is, what are the consequences? What other levers can I pull to get to this way? So that's what I mean, because when you see things as systems, you need to be aware of the second and third and however many others effects that you have. So you need to know what is going to change as you pull the different levers. Semi-tangent from this, but a good sidecar. Remember Woody Zool, Jared?

I do, yes. He mentioned Russell Ackoff and something that he was famous for quoting, which was because managers can't figure out how to measure what they want, they start wanting what they can measure. Right. So it's like you could be the manager, whether you're the business owner, stakeholder, PM, engineering lead, whatever. You kind of have to feel like if you don't know what to measure, you measure what you can.

And in this case here, what you can measure, what you begin to measure, whether it's right or wrong. Yep. What gets measured gets managed. I think it's Peter Drucker who said this, but I'm not sure. Yeah. Yeah, for sure. And you can only grow what you measure too. I mean, so these are all good reasons.

On the flip side, there's a positive thing. Like there's another adage that says, you don't grow or change what you don't measure. So if you don't pay attention to it, then you can't influence change because you're just not tracking its history, its trajectory. There's positives to measuring. And there are things that you may not be able to see

in numbers, you know, and that's why it's so important for managers to understand the actual work that is being done and be able to do qualitative assessments. And Deming talks a lot about that in his book, Out of the Crisis, as well, about how, like, managers should be able to understand what work their people are doing on the factory floor so that they can do a qualitative assessment of what's going wrong here. So imagine, for example, the deployment example I gave earlier, right?

Where the deployment process is painful and it's accumulating lots of things. Well, if you're a manager who's never done any software engineering, you're going to look at that bin and you're going to see, oh, deployments are slow. What do we do?

Why is that? You have no idea. So you need to be able to understand so you can make a qualitative assessment. And of course, you can rely on your people to give you opinions. So metrics will not do the management work for you. They may serve as an alert.

They may give you interesting insights. But if you manage exclusively by metrics, you're going to miss a lot of information. This episode is brought to you by Sourcegraph. Sourcegraph is universal code search that lets you move fast, even in big code bases. Here's CTO and co-founder Byung-Loo explaining how Sourcegraph helps you to get into that ideal state of flow in coding. The ideal state of software development is really being in that state of flow. It's that state where all the relevant context information that you need to build whatever feature or bug that you're focused on building or fixing at the moment. That's all readily available.

Now, the question is, how do you get into that state where, you know, you don't know anything about the code necessarily that you're going to modify? That's where Sourcegraph comes in. And so what you do with Sourcegraph is you jump into Sourcegraph. It provides a single portal into that universe of code. You search for the string literal, the pattern, whatever it is you're into Sourcegraph. It provides a single portal into that universe of code. You search for the string literal, the pattern, whatever it is you're looking for. You dive right into the specific part of code

that you want to understand. And then you have all these code navigation capabilities, jump to definition, find references that work across repository boundaries that work without having to clone the code to your local machine

and set up and mess around with editor config and all that. Everything is just designed to be seamless and to aid in that task of, you know, code spelunking or source diving. And once you've acquired that understanding, then you can hop back in your editor, dive right back into that flow state of, hey, all the information I need is readily accessible. Let me just focus on writing the code that influence the feature or fixes the bug that I'm working on. All right. Learn more at Sourcegraph.com and also check out their bi-monthly virtual series called DevTool Time covering all things DevTools at Sourcegraph.com slash DevTool Time. so a metric that you vouch for is the cumulative flow diagram we've been talking about it with

regards to things in things out how long they're in the cycle what's accumulating what is not have you put this into practice in your daily work and seen benefits from this regards to things in, things out, how long they're in the cycle, what's accumulating, what is not. Have you put this into practice in your daily work and seen benefits from this particular metric? Yeah, I've done this before. And basically, so besides the cumulative flow diagrams, I think there's other things you should look at. So that's the main visualization, because that's the easiest way to see your process from end to end. So that way, it's very easy to see what bands are growing and what bands are shrinking. So yeah, that is a very useful visualization. Now, it's not the only visualization.

That's one important thing to highlight. There's other important things that I've used much more than the cumulative flow diagram, which are, for example, scatter plots with the cycle times of different issues. I found that much more useful in the past, to be honest. So if you look at a scatter plot with the different cycle times and you see that something is going up and up and it's highlighted on the top, like in the 95th percentile, well, if something is on that high of a percentile, it means there's something different on it. It's something that's making it take longer than 95% of the issue. So that's when you get a preemption point and then you go there

and you ask, what's wrong with this issue? What do we do to deliver it faster? So that's also a very useful visualization. Now, besides that, there's also flow time. So what percentage of time is something blocked? So if something is flowing 90% of the time, so if it's not blocked, then you have good flow. If you have 50%, if it's not actively being worked on 50% of the time, you're having a lot of context switching. You may have more things in your process than you can handle. So it's also important to look at that. So there's all these things you can look at

and looking at them as a whole is the best way of doing things, I think. So once you look at those things, you can come to a perspective and you can say, besides the quality of assessment that you're going to make, you can say, oh, I've seen that in the past however many weeks, things have been accumulating at this point, or I've seen that things are getting blocked a lot. And I've seen that we've got many tasks that are deviating from what we had before so these are all ways of using these and you're always going to have to make a qualitative assessment in one way but um if you have these it's easier to guide a discussion as a follow-up are there any tools or software suites or ways of making these particular charts easy to use or available without too much effort?

Yeah, so I think there are a few products that do this out there. The one I've used before is Actionable Geometrics by Vacanti, which I've used specially because I've bought his book, which is excellent, by the way. I don't know if Daniel's ever going to hear this, but it's an absolutely brilliant book. And I do think it's his company. I'm not sure. But anyway, I've used that before and it was very useful. I do think that pieces of software other than Jira, if I'm not mistaken, do have some of those as well.

But the one I've used before is called Actionable Agile Metrics. It's a Jira plugin. I think it's also available for a few other task management pieces of software. You called Actionable Agile Metrics. It's a Jira plugin. I think it's also available for a few other task management pieces of software. You said Actionable Agile Metrics? Yes, exactly. Is that a book as well? Yes, there is a book,

which is really good. It's a book with a plugin. It's a plugin with a book. Yeah, so, well, they've done a very good job of educating their users so that they can get value of this complex, in a way, product that they're selling.

Yeah. So the book is really great. I really, really enjoyed the book. There's plenty of talks by Vacanti on YouTube and on Vimeo. They're absolutely great. And also, if you're looking for resources, besides the book and besides the plugin, there is also Don Heinze's book called

Principles of Product Development Flow, which is probably my favorite book of all time in terms of product development. It was one of the most transformative books I've ever read in my career. It's a dense book. You'll probably need to get back to it in a few times. One of the main reasons I've been writing so many blog posts is because I always go back to the book to review a few things and and always kind of get something new out of it. It's a great, great book.

And there's yet a third book by Vacanti about estimations precisely, I think it's called When Will It Be Done, which talks about how to do these forecasts using Monte Carlo simulations and things to pay attention to and all of that. So those are all excellent resources for those interested in seeing product development more as a system. Have you tried the Monte Carlo move? Have you tried estimates that way, or you just avoid estimates altogether?

So I've played around with that. I have never committed to a particular estimation that came out of a Monte Carlo simulation. I've looked at that. It's very easy for you to get some insights, but I haven't committed to a projection I've seen there. If I can avoid committing to a particular date, and if I can instead influence the process and align with the different stakeholders so that we have a cadence of meetings along

the way so that we can discuss what we're going to do next, I usually prefer to run things that way. So even if you're, I don't know, maybe someone asked you to agree on a particular date with the marketing team. Well, instead of doing that, maybe I'll ask, well, instead of me agreeing to a particular date, why don't we set up weekly or bi-weekly meetings

with the marketing team so that we can adjust as we go and we can get better results and we can sync on where we are and all that and we can always give you an update picture of where we are and everyone works together to make those small bets so you know things will not work if you just you know one part of the company makes is trying to make small bets while other parts are trying to make huge bets uh you know it's uh things need to be. I'm not saying everyone needs to work at the same cadence. It's just things, companies as well, needs to be thought of as systems.

So even the way you determine the hierarchy of the company, how you distribute resources across it, you know, all of that is a system and it needs to be really carefully thought through. Also collaboration is a system. Like you just pointed out that rather than say, here's the deadline, go off, do the thing by yourself, assuming let me collaborate with the marketing team, with the sales team, with whatever interconnected team has a concern or care about what we deliver. So that, I mean, that's going to be more fun too. They're going to work with you.

They're going to see Lucas is a real person. He's got a family. He enjoys these kinds of shoes. He's got, you know, special glasses that make him feel cool or actually is cool. And then, you know, trees out. Pretty cool. But they know who you are, right? Whereas if it's just a deadline and a timeframe and you either meet it or you don't, there's a lot to assume about you, which is just simply whether you passed or failed, not how do we iteratively get there in a story? How do we tell our company story? How did it, how did I get to understand what marketing really needs from me so that I can deliver better? And that might even motivate you more about understanding more of people's backstories and more how other teams will benefit when this

ships on time. You know what I mean? Like that's, there's a lot more to it than just simply the system itself. It's the collaboration is a good system as well. Yeah, absolutely. Absolutely.

I think people underestimate, you know, how important it is for you to actually know your peers and know how they're going to, you know, react and, you know, how to communicate effectively.

All that is, is, is paramount, you know? And we can talk a lot about systems, but if you don't have a good interpersonal relationship, those systems fall apart, for sure. What I'm saying is that is a crucial part of the system.

It's not like the system and then that too, the relationships aside from the system, that is the lifeblood of the system, the relationships that get formed. Yeah, absolutely. It's just much more harder to measure because it's not as tangible but it is it is part of the system for sure yeah right crucial part of it well lucas we have had a fascinating conversation here the only thing we haven't touched on is you tearing apart people's stand-ups i don't know if we want to make time for that if we want to just save that for a future conversation.

We definitely have to have it back on the show. You have lots of interesting insights. I love how you go into these books and you read them and you pull out the good bits and then you give them to us in your blog posts. It's just spectacular. It's like Blinkist but for not Blinkist books. Yeah, exactly.

It's good stuff. Adam, what do you think? Should we call it a show? I think it's worth it. Yeah, I mean, there probably isn't one listener out there listening to this that isn't part of a small team, whether it's a two person that has some sort of ritualistic meeting, whether they call it a stand up or not, that basically says this is what I'm working on. This is where I'm blocked. You know, and answers those questions that you typically answer at a stand-up. So I think it's like somebody, probably unanimously everybody listening to this show

is in some sort of meeting once a week or some sort of timed basis that answers questions like that. So what do you have to say? Good and bad stand-ups. Help us out here. So when it comes to stand-ups, I think that I find that people ramble a lot. So when you follow a model where you're trying to say what you've done in the previous day and what you're going to do today and all that,

people are going to inevitably start to ramble. And a lot of the information is not important for your peers, especially if you're... So if you're working a two or three people team, yeah, it's easy for everyone to pay attention to what you did yesterday and what you're going to do tomorrow. But if you're working a team that has more than three people, it's going to be very hard for you to pay attention to what you did yesterday and what you're going to do tomorrow, but if you're working in a team that has more than three people, it's going to be very hard for you to pay attention to all this small granular level of detail that everyone has.

So to avoid rambling and to avoid making meetings long and unproductive, what I'd say is just get your camera on board, go from left to right, and then look at the test they're there and ask people whether they're blocked, whether they need any answers, or if everything's okay. Because if everything's okay, people don't need to tell you what they were doing yesterday. You're probably going to review the code anyway. You don't need to know all the granular detail of what they did because stand-ups are not made for people to prove they're productive. Stand-ups are made for people to get blockers out of the way. In a way, daily stand-ups, what they do is produce daily preemptive feedback. You know when I've spoken about that interruption point on your operating system

which causes things to be stopped and something else to run or something to be, I don't know, for a process to be terminated or something like that. So that's the daily stand-up. Daily stand-up causes the system to produce synchronous feedback every single day so that you can see whether something is wrong and fix it. If something is not wrong, you don't need to fix it. There's no need to start with Technobabble or whatever it is. You just say everything's okay and you move on. Things get shorter and more productive. People don't ramble. They like their stand-ups and they actually realize that their stand-ups are created for them to get them blocked. So if the person

that usually runs this stand-up cannot participate in the stand-up, people still do the stand-up because they still find it valuable. Now, if you're just telling each other what you've done yesterday, what you're going to do tomorrow, people are probably not going to find that valuable. So they're not going to do it when the person that runs the stand up is not there. So, you know, that's how I like to see stand ups and how I think we can we can make them better. So if it's just about unblocking, then could you just come to the meeting and say, are you blocked? Yes or no? No, no, no, no, no. End meeting. You know what I mean? Or yes. Okay. Why are you blocked? Yes. Perfectly valid. Do you think you'll be blocked this week? Can you hypothetically think you'll be blocked this week?

Is there a possibility to be blocked? Yeah. Yeah. That's a good question too. So that's one of the things that you could ask as well. But if people know that that meeting is made for them to be unblocked, basically they're, you know, they're going to have that in their minds. You can incentivize and you can ask that. I think that makes a lot of sense. It's a very good question to ask. But I think also, if people know that that's a meeting for them to get unblocked, if they

have a question that will influence the way they're going to implement something, they're going to ask that question, you know, maybe they're not necessarily blocked, but they would going to implement something. They're going to ask that question. Maybe they're not necessarily blocked, but they would like a particular answer. They have uncertainty. Yeah, exactly. So yeah, they have some kind of uncertainty. Yes, yes. So that's the place for you to talk about something.

But let's say you've been writing some code and everything's going okay. And you spent yesterday writing the code. You've written a few tests. Everything's okay. You think you're going to be able to finish it today. You've got, you know, everything's still clear in this specification. There's no reason for you to be alarmed. Why would you spend a lot of time explaining the tests you've written, the lines of code you've written, all the possible implementation paths that you've tried?

Why do that? Isn't that what PRs are for? Exactly. It's like you're going to review the code anyway. So, yeah. Right. And you could do that in a code review or a PR or something like that. It's a different process. Yeah.

I almost feel like you can answer, you can determine because you will hold space in your calendar and in your mindset for a meeting. Let's say it's in the morning. Stand-ups are usually the first thing you do or one of the very first things you do. So, you'll sort of bake the initial part of your day around the possibility of this meeting. What if the day before everyone knew if there should be a meeting tomorrow and only those who are blocked or uncertain should show up. And if you feel like somebody else could help you become unblocked or more certain, call them in even if they're not blocked or they're blocked or uncertain. You know, if there's a dependency, essentially, you can determine that the day before. That way, no one's morning is jacked because of a meeting that doesn't need to happen.

And if you've got code review, well, hey, there's my PR. Yeah, absolutely. You don't need a stand up to, you know, send a message on Slack to someone and say, hey, I have a question or hey, I'm blocked. Can you help me out? You don't need to wait for the stand-up. The stand-up is one formal way of ensuring that happens. But like, you don't necessarily need that. And that's one thing that I think people don't realize. You know, in the software engineering industry, we sometimes do things just because that's the,

you know, that's the way that other people have done it for a few years. But we haven't, you know, asked ourselves whether those are things that were worth doing. It's like, what's the purpose of having a daily stand-up? The purpose of having a daily stand-up is not to have a daily stand-up. There is a purpose behind it. What's that purpose? Can you achieve that purpose some other way that makes more sense to your system?

And then we go back to Scrum. I'm not saying Scrum is bad. Scrum works. But why are you doing Scrum? Where does Scrum come from? Where are the benefits coming from? Can you get them in any other way that's better for your case? That's, I think, what people need to think more about.

Well, like anybody would use scaffolding or framework. You know this. I'm not preaching to the choir here. But they use it because they have no prior experience or very little experience in being effective. And so Scrum is the best training wheels to use. Very effective. It's a good starting place. No one got fired for trying Scrum when there was no experience, right?

Like you at least made an effort towards productivity. If you went willy-nilly and you had no idea what you're going to do, you didn't do scrum, you didn't do agile, you didn't do whatever, then you might get fired. You're like, did you not read that very popular book? Everybody's doing it. Lean this, do that. Come on, you're out of here. Have you guys heard the story of the newlyweds and the chuck roast? You've probably heard that story. I have not. Please tell it. All right. So you have some newlyweds and they are going to have a dinner and the wife cooks her family chuck roast recipe. So she takes the chuck roast out of the oven and she lops off the two ends and serves it that way.

And her husband's like, why are you lopping off the ends? They're perfectly good. You know, she's like, I don't know. That's just the family recipe. I'll ask my mom. So she goes so she goes to her mom she's like mom why did we lop off the two ends of the chuck roast as part of our recipe she's like i don't know i got that from your grandma and so she goes and asks her grandma grandma why did we lop off the two ends of the chuck roast for this recipe and she says well because the whole thing wouldn't fit in the pan my pan was too small moral of the story don't just do things because that's the way we do them. You have to know the reasoning. Well, that's why we have these conversations, is to question why, to dig deep.

And I think you have, Lucas. You've got several blog posts we'll link up in the show notes. Jared and I have either fully read them or loosely read them, as you can tell through the show. Definitely quoted a few, brought in some laws, brought in some family recipe stories and whatnot. But is there anything we didn't ask you, Lucas? Anything we can close on that you just have to say before we close out? I don't know.

I'd say question your assumptions, understand the dynamics of your systems. And yeah, I'd say that's my general advice, but I cannot think of further questions there. Question your cues, right? Look at your cues. When all else fails, are you queuing? And if you're queuing, why? I got that from your blog post. That's your words, not mine.

It's a paraphrase, of course. That's your word, not mine. Yeah, I think Donald Heinrichsen says that queues are the biggest source of waste in product development. And I think that's the quote. I think he says that the problem is in product development is rarely idle engineers. It's more often idle work products, just sitting around and queues.

Features not being enjoyed. Yeah. Or not even being shipped. Bringing the lake to customers, retaining customers, attracting customers, giving marketing, something to talk about, sell something to pitch. All these things. Yeah. Or just sitting in a GitHub repo. That's not in production.

That's not prod. Lucas, thank you so much for your wisdom, man. Thank you for sharing all this and thank you for coming back. Can't wait to have you back on again. Thank you. Awesome. Thank you very much for the invite.

It was an absolute pleasure to chat with you. Thank you so much. It's always fun, Lucas. You're welcome back anytime. So much was covered in today's show and so much more could have been covered. It was awesome having Lucas back on the show, going deep on product development systems

and structures. And if during this show, you find yourself curious at all about his thoughts on all things text mode, well, hey, here's a clip from that episode. If you had to think about what was the most important thing, you seem to be focusing a little bit on the speed because you say you feel like you're a little bit closer to the metal so to speak maybe there's an analogy with

you know driving a car enthusiasts like like a manual transmission uh regular people like an automatic transmission is the speed really key for you i don't think actually the speed is the key for me uh i think of course it's more comfortable to use a keyboard all the time. But actually, most of the time, I don't think we're writing code, right? I think most of the time we're just like reading, we're thinking. And what I really feel that makes a huge difference for me is that I don't feel like there's anything on my way when I'm transposing thoughts to code you know just it's so much faster and it's so automatic now also I can switch between like environments like

often when I pair with co-workers I can just you know like open a terminal windows and open and I'm fine without plugins, without anything. So I'm like good to go everywhere, I don't need to install anything. Also like even if I need to, configurations are a lot more portable. I think there are many more advantages rather than just being fast. I mean being fast is cool, right? I mean when I'm doing a talk and I'm doing live coding, if I open Vim, I know that the subject of the questions are going to be about Vim, like at least 50% of them. Right. And the other 50% about live coding. Yeah, it's just like, it's fun, but I don't think it's the main reason why I use Vim.

Probably what got me started, but not what keeps me going in it. You can find that at changelog.fm slash 340. That is episode 340. A big thanks once again to our partners Fastly and Fly. Also to Breakmaster Cylinder for those banging beats. And of course to you Hey++ members, don't forget you have a bonus

seven minutes after the show today, so make sure you stick around if you're not a++ subscriber. It's too easy. Head to changelog.com slash plus plus. Directly support us. Make the ads disappear and get access to bonus content on our shows. All right, hey, that's it for this week. Thank you so much for tuning in.

We'll see you on Monday. Outro Music