Crafting Code Podcast

[00:00:16] Allan Stewart: Welcome to the Crafting Code Podcast, where we discuss the importance of doing the right thing at the right time with the right tools. I'm Allan Stewart, a software architect, and lately I've been thinking what it would be like to live on a starship, and how important the color of my shirt would be to my survival.

[00:00:32] Dave Adsit: I'm Dave Adsit, a VP of engineering, and I have been thinking a lot recently about bottlenecks to value creation and how critical it is to applying effort at the right place if you're trying to improve a system.

[00:00:46] Allan Stewart: Our topic for this episode is urgency. A common business refrain that we hear sometimes is that we need to instill a sense of urgency. Yeah. Where does this line come from anyway, and what's meant by it?

[00:01:02] Dave Adsit: Well, it had to be something that some famous person once said, because I've had so many managers and leaders and CEOs and whatever use that line on me that it has to be, it lives in the zeitgeist, right? People have heard it. People like to use it. I think it typically comes from one of two places. The first one is. Someone imagined a BS deadline or roadmap, and then they decided to hold everybody else accountable to their daydream. I think the other place that it comes from is if someone in leadership observes members of a team engaged in what they believe to be excessive nonproductive behavior.

[00:01:50] Allan Stewart: This does seem to come down from leadership levels. I don't know if I've ever heard. Very many people talking about how much more urgency we need down at like a team level. But I think clearly the desired effect is that they want to see more work getting done faster or more engagement in the work or some agreement about how important the mission of the company is and that it needs to go forward and not sit still. Right. So as we've talked about this, I think one of the core. Elements that we really have to get at to understand this is defining what do we mean by urgency? And this is where you and I have immediately begun to diverge in our perceptions and like how we think about this problem. So, so Dave, what, when they say that they want to instill urgency, what, what does that word urgency mean for you?

[00:02:52] Dave Adsit: Yeah. So when I think of urgency in a business context, I. Go back to the root of urgency, which is urge, which to me, that's a physical desire towards something. And as biological organisms, we all have urges to avoid harm and to seek reward. And so for me, urgency is a motivation with some kind of a deep seated physical origin. And so things that are very motivational or things that cause a lot of urgency in us are fear or the desire to receive a strong reward like dopamine. And I realize that in the context of the dictionary, my definition is probably closer to number five or number six down the list and may not be the most common, but in a business context, I think of it as urgency is the desire to achieve or avoid something positive. Urgency creates a focus in us on delivering value. If I, if I go back a little bit to what you said about the leaders trying to instill urgency and why do they want to do that? I think a lot of times it's like urgency will create productivity and we want to produce something. And if people are slacking off or goofing off, then they're not producing the thing that we're paying them to produce. And you're right. I've never heard anybody in a, in a weekly team retrospective say our urgency was very low this week. Like that's never. That's never come up in any of the teams I've been on or managed.

[00:04:31] Allan Stewart: For me, the word urgency really calls to mind like time and pressure, right? It's often defined using words like immediate prompt, pressing, insistence, demand. And to me, I look at that as like highlighting an opportunity cost that something becomes urgent when not taking action has a consequence, usually a negative consequence that, that we don't want to incur. And so, so urgency is to me is all, all about that kind of time pressure thing. Um, partly this is because I have long kind of distinguished between urgent and important based on the Eisenhower matrix. Right. So you can create a quadrant of, uh, you know, what do you do with the things that are urgent and important? Well, you better get them done right away. What do you do with the things that are important, but not urgent? Um, those are often your architectural dreams that don't ever seem to get refactored into the code base. Um, and, and then there's also things that are non-urgent, some that aren't also aren't important. And why are you even talking about those ones? Just throw those on the ground. And so, because it's a, for me, elicits this, like almost a moment. Emotional response of, you know, time and pressure and worry, and maybe, uh, activates my, uh, defense mechanism. It makes me wonder whether we should be trying to build a sense of urgency in teams at all. Um, for me, some of it is just definitional, but I wonder is like, is it motivation that, that we want, um, some kind of a desire or focus not being distracted, actually just. Caring about the, the work, um, which also makes me wonder about intrinsic and extrinsic motivations. I find that it can be very difficult to get teams, to get excited about work and, you know, really shipping value quickly when it comes extrinsically. And they say, Hey, someone is forcing upon us this desire. Um, so, so yeah, for me, you get. A very different. Uh, visceral feeling when we define, define urgency.

[00:07:02] Dave Adsit: Yeah, I, I can, I can understand the definition that you're using. And I think that I would categorize that as kind of the typifying the negative urgency that we often see the avoidance of pain, fear, or punishment of some kind of harm. Right. And so what that got me thinking about was some of the. Some of the pull quotes from principles of product development flow. Which has been very influential for me and for you as well through our career is. Yeah. You know, there's, there's several places in there where Don talks about. Urgency as it relates to the work that we're doing. And the first one that he's talking about the effects of cues, the. He says. Sixth in a list of many things. Cues have a negative psychological effect. They undermine motivation and initiative. When we. When the next process will be ready to use. Our work product within an hour, we feel a sense of urgency. When the process has a four week queue, we feel there is little value in hurrying to finish our work. And so to me, that kind of speaks to the idea that. The urgency can be created by the queue itself, or the lack of urgency is created by the length of the queue and a shorter queue creates urgency. And that. To me speaks to the idea that there can be urgency. That is not. Fear based. It's more. Root animated by this reward system. Another. And another section, he talks about the psychological. The psychology principle of batch size. The seventh beneficial effect to small batches is their power to motivate people. Large batches, demotivate people in two ways. First. Large batches dilute responsibility. If I am responsible for delivering one module of code in the next five days, I have no place to hide. If I am responsible for delivering. One of the 100 modules that are required. For the next integration point, 100 days from now. I feel much less urgency. After all, even if I am behind schedule. There appears to be plenty of time left before the integration point. And there are many other people who are. More likely to get in trouble than I am. Right. And so I agree that that speaks to the concept of motivation, but it also speaks to. Having this large batch as a. Tool that removes. Urgency from a team. And so. To me, when I think about it, I think about it in terms of some of the concepts from. Lean and from drive. Where drive talks about. We can't actually motivate our staff to do something. Or rather, if we want to motivate them to do something, we have to first stop demotivating them. Right. So if we want to. Instill a sense of urgency. The first thing we have to do is stop creating conditions that reduce urgency. Like long queues or large batches. And, you know, I have several, several different strategies that I've used with teams. You know, we limit whip, we focus, we try to create. The, the desire to be rewarded for delivery. So. If leadership comes to me and he, and says, we need to instill a sense of urgency in your team. The first thing I'm going to do is not say that to the team. No one has ever been motivated or inspired or. Picked up a sense of urgency by being told. That that's an important value of the leadership team. The first thing I'm going to do is I'm going to go look for evidence that the team isn't actually just. Intentionally wasting time. Are they goofing off? Are they taking two hour lunches every day? Are they playing video games when they should be pair programming? You know, what are we, what are we doing? Is the team wasting time or being otherwise intentionally unproductive? So if they are, then I'm going to set expectations around work and I'm going to work on appropriate mitigations for troublemakers. And. We're going to move forward from there, but often that's not the problem. In fact, very rarely is that actually the problem? So usually the problem of the, the. Catalyst for instilling a sense of urgency is a problem of perception. Or execution. So again, I don't tell the team that they need to have urgency. What I do and set instead is try to set up systems. That help my teams fall into that pit of success and work with urgency. So we work in small batches. We work with limited work in process. We work with high focus. We measure lead time from when we commit to deliver something until when we. Can put it out into production. And then we celebrate. When the lead time goes down. We do other things like. Follow the TDD loop. Which each time we come around the TDD loop, whether we're doing single loop or double loop TDD. We. Are that much closer to delivering something of value. And we have one more little tiny dopamine hit. So I try to create incentives that. Pull people forward. To. You know, have continued. Continual reward. And use that to create a sense of urgency. I desire to have. The next dopamine hit and the TDD dopamine hit is really small, but the. I delivered a working feature. Is larger and I put it in production. It was used by customers is larger than that. And so. I like to use that. That biological urge to pull me forward and to pull the team forward towards larger and more consistent, more frequent rewards. So. And so if we can do that consistently. We can improve the system to the point where the perception changes about. The level of urgency that the team. Feels or is expressing. So along those lines, like I've already mentioned a couple of things from principles of product development flow, but there's a couple more that I think are super important. When it comes to having an urgency. One of them is the way we structure our day and our week with regard to meetings. Short, predictable, frequent meetings give us all the advantages of small batch size that we've already talked about in principles of product development flow. Also, with more frequent opportunities for coordination and feedback, we can't get too far off track. In contrast, when we hold lengthy meetings at unpredictable times and infrequent intervals, we may lose urgency very quickly. Another one is another quote that I want to read is from the hurry up and wait principle. Slow feedback produces the opposite effect and large queues create slow feedback. When queues are large, it is very hard to create urgency. Large batches and high whip create long lead times and high queue wait times, which both destroy urgency. In contrast, when queues are small, work can be processed in a strict first in first out sequence. This causes a short time between arrival and processing. So the relationship between early arrival and early service is reinforced. With this rapid consequence, it is much easier to promote an atmosphere of urgency. So all of that is to say that I think urgency is a tool that can be used for good. However, I will recognize that in most cases, most organizations do not leverage the ability to do so. the positive reinforcement side of urgency and they use all stick, no carrot.

[00:14:50] Allan Stewart: Yeah, it's interesting how strongly I agree and also simultaneously disagree. Because how you approach the team and the things that you're trying to get them to do, I agree with. And I agree with the concept behind each of the principles that you shared out of principles of product development flow. And yet, and maybe it's just that I get hung up on the word itself, which would not be the first time. I definitely have a more archaic look at what words mean. And this would not be the first time where people will say to me that, I'm using words in a very old way. But when I think about urgency, I think about, well, what happens if we don't act right? What's the consequence, right? So in that quote from principles of product development flow, it's talking about, oh, well, this thing's not due for a hundred days. And so I don't feel urgency to do it right now. And I think that that is because it's true. It's not urgent. It's literally not urgent. And that waiting those hundred days, that could be procrastination. It could also be reprioritization, right? If there's this big integration point, that is far away, and there's something else that you could do to deliver value now, that might be the right thing to be working on, right? If we're doing nothing at all, or just getting sidetracked by less important tasks, well, then that's a problem, but it's not a problem that we weren't urgent enough. It's a problem of the integration schedule. So we might look at it and say, hey, this is non-urgent. Literally, it's not urgent, because it's a hundred days away. Well, if we achieve some other goals, right? Like if we look at principles like cost of delay, we might say, hey, we could get these other things done, and it will only take us about 50 of those days. And then we can still do the other thing that we needed to do and make it on time, and everything will be okay. So the problem really only occurs if we need all 100 days, but we're not motivated to work on it, because we feel like, oh, 100 days, that's far away, and I'm not gonna get started on this big task that I'm procrastinating. So that's kind of where I come at it, and it's like, oh, well, I'm agreeing with the concepts from the book, but I just kind of feel like he's got the wrong word. Now, urgency does exist, and I think we need to recognize it, and perhaps especially in those different quadrants of urgent, and important that I mentioned before. But to me, it happens on its own. Like, in my mind, the only reason that I can think of that would be a good reason to instill a sense of urgency is if there's a short burst of work that can make a disproportionately large difference. So there are legitimate cases where urgency comes, something is actually urgent, and it might show up, for example, with a production outage, or there is a trade-off, or there's a trade show that is coming up, and we need to get something done that we can show off that will make a disproportionate good benefit for our business. But at some point, if the person's not motivated, then no amount of urgency, like trying to knock on the extrinsic motivation door is going to work. When we talked about this before our recording, you mentioned a story about a guy, who just would not stop playing Doom to address a production issue.

[00:18:45] Dave Adsit: Yes, that happened.

[00:18:47] Allan Stewart: And so I experienced the same thing with my teenage son at times. It's time for dinner. Yeah, just a minute. And then many minutes go by before he comes down, because he's busy doing something else, right? And so I can definitely see that problem, but no amount of shouting at my teenage son makes him get off Minecraft sooner. And so I look at this idea of like, let's instill urgency. And again, I'm thinking about it in ways that I have seen it done. Less about changing the system, the way that you described it, but more about approaching it from a different angle, which admittedly, you said you don't go to the teams and say, hey, be more urgent, right? You tackle it in a different way, which I think is smart, because if we try to, to add this external pressure of urgency in like a lasting way that's not time boxed, it's just like, oh, forever, I want you to always be just rabidly motivated about this work. And there's no end in sight. Then I feel like it just causes anxiety or burnout. The lasting change that I think we want is the engagement, the motivation to succeed and seeing the company succeed. And I'm not sure that adding pressure does that. And then one final thought that I've thought a lot about with this idea of urgency is the old saw, haste makes waste. And I wonder if like, if we're always urgent and we've instilled this sense of urgency, does that detract from other things that are important, but not urgent, like training or practice or refactoring to improve code? Because urgency often keeps us very busy. And then we're busy doing something else. And we might not get these other things done, or it can cause the perverse incentive of people wanting to be perceived as being urgent or busy. Even if what they're doing isn't actually very important because they see it as, oh, well, executives came in and people weren't typing enough on their keyboard. And so now whenever the boss comes by, I make sure that I'm diligently typing and wait till he goes away to finish watching my cat videos. So yeah, how often are important but not urgent items being left undone just because other things have the urgency or the pressure of the urgency is causing these perverse incentives?

[00:21:33] Dave Adsit: Yeah, the motivation, the incentives, that's the critical word right there, right? Is that there are multiple types of incentives that can be applied and are often applied in different conditions. And the easiest one to reach for is the threat of harm, which is, I think the, you know, harm is not likely to be physical harm, but it could be career harm or employment harm or some other- Or emotional harm. Emotional harm. Because you didn't want to get shouted at. Yeah, there's a lot of ways that we can misuse the concept of urgency to, to abuse people in our employ. And I think it's not surprising that that's the only one you've experienced. It's the one that is most common. And I think maybe, maybe my perception on urgency being any kind of motivation to take quick action, whether it's from a positive source or a negative source, may be the outlier in this case. But that said, there are a lot of things that we do agree on when it comes to the concept of urgency. Yes. It is not okay and not behaving professionally for people to be idle when they should be working. We both agree on that. If you're not helping the business to achieve goals or outcomes, you are being wasteful. You're not operating the way that we expect professionals to behave.

[00:23:00] Allan Stewart: Right. And I would include with that, in the past when we would talk about lean, we have said that sometimes the best thing that you can be doing is nothing. Mm-hmm. And I think to square those two concepts, it's you're helping the business to achieve its goals, right? So if you are idle, because that is the thing that you can be doing, usually it means you're idling something, right? Like you're not starting new work when the WIP limit has already been...

[00:23:29] Dave Adsit: Reached or exceeded.

[00:23:31] Allan Stewart: Yeah, exactly. That you've already hit the WIP limit. But that doesn't mean you just sit there doing nothing. And be idle. You're idle on that thing of not starting new work, but you should be finding something else constructive to do, right? Sit down and pair with somebody else. Do that pull request review that you haven't been doing that you had put off or whatever it is that helps move things forward. Or maybe even, hey, I'm doing some research or training myself up so that I'm not doing nothing, but I'm actually doing something. But it's just something that can be said, right? Set aside and it doesn't cause additional work and process.

[00:24:11] Dave Adsit: Yeah, we've joked in the past about the concept of the net negative programmer. The more work they do, the further behind you get. There are times when the most productive thing, if we're focused on completing a task, completing a project, delivering it, there are times when the most productive thing you can do is not be a distraction and let the thing get finished, right? There are times when you need a lot of hands on deck to move through. And there are times when you are reaching, usually when you're reaching the end of something, when it's like one or two people are ushering it across the finish line and the rest of us are staying out of their way. The productive thing we're doing is staying out of their way so that we can all jump in together on the next thing when we get it started. It's psychologically very challenging to sit idle when the only thing between you and feeling productive is breaking that WIP limit. But it is valuable, in many cases, to be able to do that. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. share from a manager creating a very negative sense of urgency was a sales leader who was told your team is under quota and the quarter is ending, fix it. And his solution was to walk to the end of the aisle where his team of salespeople worked, pull his desk out in front of the exit to that aisle, not blocking it, not causing a fire hazard, but definitely creating a signal that no one walks past me until we hit this quota. And he sat there with his laptop and he smiled and dialed until while his team did the same and he kept them many more hours than had been agreed upon or planned by most of the people on his team because he needed to create a sense of urgency to get this quota met. And he did it through a not so subtle threat. And I think we would all agree that that is a negative urgency. Right.

[00:26:37] Allan Stewart: Another place that we agree is around some of those concepts that were shared in principles of product development flow, right? So long queue times, large batches, those are problematic. They create effects in the system that move us further away from being able to deliver value steadily, regularly. They introduce non-value time to the equation that we want to reduce and and eliminate as much as possible.

[00:27:08] Dave Adsit: Another thing that we agree on is the consistent meeting cadences are beneficial. One very quick story here is when we worked together in the past, we were working in mountain time zone in the US and we were coordinating with a team that was in South Africa. And so if we discovered during our work day on a Tuesday, for example, that we needed to meet with the team in South Africa to discuss something, well, we would send them a message during the end of our work day. They wouldn't get it until the beginning of their work day. They wouldn't respond until the middle of our next work day. And it would take multiple days to coordinate a meeting. And eventually after doing this several times, we just decided to hold a meeting. I think it was twice a week on like Tuesday and Friday, the end of their work day, which was the beginning of our work day. And then anything that we needed to coordinate. And if we had nothing to coordinate, we would just end the meeting and they would go home and we would get started for the day. And by having that consistent meeting cadence, we saved both sides a tremendous amount of hassle in coordinating. And even when we were doing the ad hoc meeting as needed, the most we could ever meet was once a week. And so we were getting decisions and coordination points and collaboration half as frequently as when we decided to just have the meeting on a specific And then if we didn't need it, we would end it early.

[00:28:40] Allan Stewart: Another place where we agree is how critical it is for us to get fast feedback. Having fast feedback allows us to navigate very quickly. It allows us to respond to change. And I think it helps us with some of those other things that we were talking about, like long queue times and large batches. I'm reminded of a time when a team I was working on, we were responsible for building out a single when it happened when it happened when it happened when it happened when it happened when it happened when it happened when it happened when it happened when it happened meet this protocol, you have to do all the things. You can't just skip half of it. It has to work end to end. And so it took a while to build, which meant it was a larger batch. But because we hadn't been getting good feedback all along the way, we didn't have customers lined up to use it. And it turned out that that wasn't actually that important to many of the customers in the first place. And so getting that feedback early and often and understanding and validating is the thing that we're doing. Is there a better, faster way we can validate this than go off and build it

[00:30:14] Dave Adsit: is very important. Yeah, I definitely agree on that. I want fast feedback all the time because so often we are steering by looking in the rear view and that is a dangerous way to move fast. One of the other things that we've talked about in the past and is relevant here is the importance of Slack. Urgency and Slack time seem to be at odds. However, if you go study the Kingman's formula or Kingman's formulation, depending on where you read it, you'll find that there is a strong correlation between high utilization and increased wait times. And that's actually even made worse by variability in the system, right? If there's variability in the requirements, variability in heavily utilized over 80%, stuff starts to queue up. And if your work is variable, like software development work or most thought work, it's gets even worse, even faster. And so there's a non-linear and exponential relationship between how heavily you've loaded your resources. In this case, how busy people are and how likely work is to be delayed. So if we want work to, to flow through a system at a consistent or reliable basis, we need to have Slack time in the system. And it can be easily, it's easy to see that people might observe Slack as the opposite of urgency.

[00:31:47] Allan Stewart: I think that there's a interesting question around that level of engagement or level of urgency, if we, if we want to think about it that way, because another place where I think we agree is that zero and a hundred percent are both wrong. Right? The, the Kingsman formulation tells us that we can't peg it at a hundred percent and see success. But we also know that obviously if zero percent stuff is getting done, well, then we're never going to, we're never going to see the end. It's no value happens. So I think it's interesting to think what is reasonable and this is going to vary widely depending on your context and what kind of place you're working at and the kind of work that you're doing. And the kinds of customers, et cetera. But offhand, it seems like probably somewhere around 80% is pretty reasonable. And then with the 20% Slack, right? We we've seen this before the idea of the 20% Slack time. And it's, it's been touted as a good thing in various ways. And obviously it depends on how you utilize that time, because I think most of that time still needs to be work related. If we're going to say, you know, one day out of a five day work week, that is just going to be not work related at all. That's probably a problem. If we're using that time for learning, training, team building, that sort of thing, that's useful. That helps improve our process, right? Like retrospectives, you're, you're looking and you're saying, Hey, how can we make ourselves better? What experiments can we be doing now? That's not to say that. I think that. Yeah. I think there is some importance to having some time where you can just like connect as a human being with another person on your team. And I don't think that that has to destroy the urgency of things, but percentage wise, that's gotta be kind of small, right? Like if you're spending hours a week, just chatting or, or, or watching videos on, on your computer or whatever, that's not effective, right? That's not, that's not a professional way to behave. And so. So as I, as I think about that urgency and how, how we can instill the good side of urgency, if we can term it that way, it becomes very important that we, we understand that there's a certain level to which we need to rise and it's not going to go all the way to a hundred percent. We shouldn't try to force everybody to be fully engaged, get away from that negative sense of urgency where everybody has to be working all day. Go, go, go without a break, without an opportunity for rest. When we take it back to kind of the initial idea, the initial question around, you know, executives wanting to instill this sense of urgency. I think we can draw back and look at a company from a higher level of, of abstraction, right? Like at the 40,000 foot view, as it were at that layer, time is money, right? Like that's the commonality across, you know, different departments across different needs. And so I can totally understand where a leader in a business is looking and saying, Hey, every day, every hour, even every minute, we are spending large amounts of money in aggregate across the company. And what are we getting back? Right. What, what value is getting delivered to our customers that is turning? And they're recognizing that value and giving us back dollars. Right. And so I think that that's an important aspect to look at and consider when we're looking at the system as a whole, because it's very easy. And I've done this before myself get caught into this trap. And I know for developers, it can be particularly enticing for us to say, Hey, there is this complex thing that we are working on in code. And we're the only ones that can do it. Um, AI helpers. There's not withstanding. And we're, we're going through and we're just focused on those details. There's a lot of them. There's a lot of technical details that go into creating a successful product. And so it's easy for us to lose track of what's happening in the rest of the business. And in fact, yeah, we often will have much less sense of urgency because to us, we're just what. No matter what we're doing. We're collecting the paycheck. We're, we're sitting there, we're working, but for somebody else in the company, that's an investment and they're, they're waiting on the results. Just, just like, just like we feel, um, you know, when you go to buy a drink and you're waiting a long time for that barista to finish the drink or, or in my case, it's usually living in Utah. There, there are many soda places. That my kids want to go. I'm not sure what they want me to go to where we're waiting in the drive-through lane for what feels like an inordinate amount of time in order to have somebody fill some soda and put some pumps of flavoring into it. So, so yeah, remembering that that's where the executives are coming from and that's why that urgency is so important to them. Can help us to empathize with this desire to instill the urgency. Yeah.

[00:37:27] Dave Adsit: So whether we call it positive urgency or just motivation. I think it's critical that we first create socio-technical systems that do not destroy it. And that lean into the nature of us as organisms that we desire positive feedback. We desire avoiding negative feedback. We want to get things done. And if we can, if we can structure our system in such a way that it leans into those characteristics of who we are. And how we work, you know, create limited whip, small batch, lots of feedback, lots of opportunity for reinforcing good behavior. Then I think that we can get the outcomes we want, regardless of what language we use to describe it.