Crafting Code Podcast

[00:00:15] 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 about how I can use LLMs responsibly without falling for lock-in should pricing or vendors suddenly change.

[00:00:35] Dave Adsit: I'm Dave Adsit, an engineering leader, and recently, I've been thinking about different types of communities of professionals which serve different purposes.

[00:00:44] Allan Stewart: Our topic for this episode is decision delegation.

[00:00:48] Dave Adsit: So the first question that comes up is, why do we delegate decisions? Decisions. Why don't we just have the manager make all the decisions? And I think the first thing I'm going to reach for here is the book Drive, which is subtitled The Surprising Truth About What Motivates Us. And in that book, one of the things that we talk about as a key motivator, actually, what we talk about is that motivating people is hard, but demotivating them is easy. So let's start by not demotivating people, and we can prevent demotivation by giving people autonomy, mastery, and purpose. Autonomy, fairly clear. Some influence over how things go, what things are done, what decisions are made. Uh, mastery, of course, is developing your skills, and purpose is using those skills for some greater good, either for yourself or others. And so I think of it as a way to increase autonomy by allowing people to make decisions about what they do. And also a way of developing mastery. If you make all of the decisions for your children, for example, if you have a child and you make every decision for them, they don't get any practice making decisions. They never develop mastery of making decisions. I have one kid who struggles a lot with making decisions. He wants to avoid making the wrong one at all times. And so we give him all day, every day, a lot of decisions that are completely irrelevant to anything. Thing. Do you want peanut butter and jelly or peanut butter and honey on your sandwich and your lunch? It doesn't matter to me as the parent which one of those he eats, but he is developing some mastery over decision-making. Anyway, all of that is to say that I look at it as delegating decisions from leadership to ICs, individual contributors, is a way of increasing both autonomy and mastery.

[00:02:56] Allan Stewart: Giving people a chance to learn and grow is definitely an important thing. And I think that that speaks to the concept of teamwork. If it was effective and useful for one person to make all the decisions, we'd just do that. But human beings aren't wired that way. They want to have some of that autonomy and some of that mastery and be able to work together. And so, you know, maybe that's a reason why some people seem to be especially desirous to jump right into the AI age where they can just order robots around and try and get a lot of things done according to their singular vision. But I have found for me that the more often that I have let other people participate in a process, the better the outcome can be. And it depends, right? I mean, this speaks to diversity. And you can only, not all diversity is a pure good. And if you have too many diverse thoughts without alignment, then it can get chaotic really fast. But also only having one person's opinion and only one person's thought process on a thing can be very narrow and might not lead to the best outcome.

[00:04:20] Dave Adsit: Yeah, we definitely build teams around projects and products so that we can take advantage of the fact that different people have different experience and different knowledge and leverage that diversity to create better products with better outcomes. And if we only have one person making every decision, then we don't get any of that benefit. So what was the point, right? And so speaking of teams, it has been found by many people over many, many experiences and many different jobs and products and different types of working environments that the people closest to the decision are likely to have the most and best information to make that decision. This is something that if you read strategy books, they always talk about decentralizing command in military situations so that people don't get stuck following bad orders when an opportunity to do something better that is still aligned with the overall goal happens. The same happens in business. We want people who are close to the product, close to the customers to be able to make decisions that impact them. That was one of the key drivers of the Zappos. That's a shoe company, right? Right. They let all of their phone customer service agents make decisions about refunds and rebates and replacements, all those things. Right. They're like, "hey, you're the person closest to the customer. You make the decision." So it happens in a lot of places where the people, they have the most information and they have the most relevant experience to make a good decision for the business.

[00:06:09] Allan Stewart: And I think this happens a lot in software development teams, where there's a lot of complexity that goes on. And engineers tend to be right at the heart of that, right? Or at the crossroads, that intersection between all the technical complexity, what the user needs, what the product management features that they're trying to build. And so having somebody there who is in the thick of all of that detail who can make decisions. If you allow some delegation to those people, then they can make really well-informed decisions that they're more likely to take in that broader context, instead of just having the one point of view from a specialist that is only thinking about part of the problem and and doing this then avoids a lot of bottlenecks in the decision-making process, if you have to go for every little thing, right? For every shoe order, if at Zappos if they had to go and ask for permission every time that they want to do a refund or they want to do an exchange or send out a new pair of shoes or whatever it is, when somebody has to be saddled with being there, being available. And if they're not available, then work queues up and you have to wait.

[00:07:32] Dave Adsit: Yeah, that really, really slows down your decision-making. And one of the things we want in modern software development teams is for them to be able to go fast. We've built all of these things like continuous integration, continuous delivery, limited batch size, limited work in process. We build all of these things out that allow teams to go really fast. But if they have to ask the chief architect every time they're going to make a new class or a new module in the system, that's going to really slow down their ability to deliver on the promise of speed. You know, we talk, we want teams to go faster, and we, number one thing you can do to slow them down is not give them any decision-making authority.

[00:08:20] Allan Stewart: Delegation also gives you that opportunity to get input and like utilize the expertise of other people. Oftentimes, that's, that'll depend on how much you're delegating, if you're just partially delegating or whatnot. And it frees up the leader. Yeah. If the leader has to make all the decisions, then they're going to be very busy and exponentially more busy with every person that they add to the team. And so instead, if they can delegate some of the decisions away and explain, "hey, this is how we're going to make these decisions," maybe give some guidelines or a rubric or something for making decisions, then they're freed up to think about strategy or to think about new opportunities or like, like for an architect, what changes they might want to instigate across the entire system to, to make an improvement that they wouldn't have time for if they're just answering the questions about the design of every single class in the system.

[00:09:23] Dave Adsit: That's definitely true. And it becomes actually overwhelming. If you are that leader, not only are you a bottleneck and you are the limiting factor for growth of your organization, you are now dealing with all the cognitive load of trying to know everything about every part of the system and constantly be context switching so that you can make decisions for your group. And it is, it's a quick path to burnout. Yeah.

[00:09:51] Allan Stewart: Well, and I think it's not very professional either on either side. It's not professional to say, "Oh, let me as the leader, take all of these things," because you're gonna burn out and you can't, you can't do it all. But it's also not professional for, uh, the people who are doing the work, right? If, if I as a software developer am going and asking for somebody else's decision to be made on every little thing, well then, I'm kind of not responsible for anything, and it's really easy for me to just say, "oh well, it broke, you know, that was somebody else's fault because they made the choices." I was just here to be a "code monkey" and that's not a professional way to be.

[00:10:34] Dave Adsit: I've got one quick story about the company that I worked at where we had installed the Rational Unified Process. We had something like 3000 engineers working on dozens, if not hundreds, of different systems. It's hard to know exactly because a lot of our developers, probably half of them, worked on mainframe tech. And it's It's like, is that one system or is that hundreds? I don't know. How do you even break it all down? But we had a change advisory board, a CAB, that had 11 members who were all very senior executives, and they had decided that quorum for making decisions was 10. Nothing would pass the CAB if they couldn't have all, if they couldn't have 10 people meet. It turns out it was very challenging for them to find more than an hour a week for these 11 people to even meet together. And there were sometimes several weeks in a row where they just didn't have quorum. So nothing happened at the meetings. And they realized this is a huge bottleneck. So obviously what they did is put in place a pre-CAB, which was a larger group with a smaller quorum that had to pre-approve things before they could go to the CAB. So the CAB could approve them more quickly. Obviously, at this point in my career, that's not the solution I would put in place. But at the time, I was not in charge of any of those decisions. So it didn't matter what my thoughts were.

[00:12:03] Allan Stewart: Yeah, I've had some similar experiences with change advisory boards and not being able to get code shipped out because they weren't ready to make a decision or they were unilaterally freezing things. And we see in microservices, I think, one of the concepts there is directly rebelling against that, right? Like we want to have independent deployments so you can make them more often when you need to based on your own judgment for exactly these kinds of reasons so that you can get code out there and get the advantages of smaller batches.

[00:12:43] Dave Adsit: That's right. Right. And one of the other things that I want to point out around decision delegation that's critical is that no one wants to be micromanaged. No one wants their manager to come and make every decision for them all day. It feels very, I mean, to go back to the beginning, it feels very demoralizing. It is going to drive out your will to make any decisions or do anything for the business. And so, you know, no one wants that. I think it's important to point out that from my perspective and my experience, the number one reason we don't delegate is fear. We are afraid of what will happen if we let go of control just enough to let somebody else make a decision. And that goes back to poor leadership. I mean, I think that leaders that are afraid to delegate are not fit for the role that they're in. They might need to go back to a different role in an organization where they can learn to build teams they trust and develop groups that will make decisions that they are aligned with, that are aligned with the organizational goals and outcomes, so that you do not have to operate in fear. And I'm sure that there are other reasons why, but that for me is the number one reason why I've seen leaders hold on so tightly to every decision and refuse to delegate.

[00:14:06] Allan Stewart: Yeah, I've been thinking about it and I can't really think of a different underlying reason not to delegate. I mean, there's some things that I feel like because of my role, sometimes I won't delegate it just because that actually is my job and that's the thing I need to be doing. But when there are things that could be and should be delegated, and I don't, and my control freak tendencies kick in, that's often the reason.

[00:14:34] Dave Adsit: Yes, I'm afraid you're going to misname this variable. I'm afraid that you're going to create a module that I don't want in the system.

[00:14:42] Allan Stewart: I'm afraid you're going to take down production.

[00:14:44] Dave Adsit: Oh, there are some real things that people can do, right? Right. So we need to be, we need to be willing to train them and, and build up that, that skill, that mastery that allows them to operate in alignment with our purpose.

[00:14:58] Allan Stewart: There may be other things that we put up as fronts. It's like, "oh, well, no, this is the reason," but all of the fronts that I can think of in my own experience have all actually been about being afraid. Yeah. They're built on a foundation of fear.

[00:15:13] Dave Adsit: So we've kind of talked about it a little little bit, kind of hinted at it a bit, and maybe talked about it in other episodes. But let's just dive right into a framework that you and I have used repeatedly for understanding decision delegation. And that comes from Jurgen Appelo's book, Management 3.0, and it's just called the Decision Delegation Framework.

[00:15:37] Allan Stewart: Or delegation levels, I think it's called sometimes too. Delegation levels, yeah. Yeah. And these levels are all framed from the perspective of the person with positional authority. So for example, the manager or the CEO or the CTO or whatever, who either, you know, is the person who can own the decision or can choose to delegate it down. It's the person with the ultimate responsibility for that decision. Right. Right. And the first level is called tell. There are seven levels. I should probably start start with that. There's seven levels, and it's a symmetrical framework. So at the top, you've got tell, in the middle, you've got consult, and at the end, you've got delegate. And this is kind of the spectrum between, at the tell level, you're just going to tell everybody. The manager is just going to say, "this is how it is. I'm not asking for any input. I'm just laying down the law. I don't even want to have a discussion." Yeah. No discussion is intended or desired. This is just how it is. And they are making the decision, right? This is actually the opposite of delegation at that extreme level.

[00:16:52] Dave Adsit: Yeah. And so your example there might be that your CTO tells you, "we are a C# shop." And that means they don't want to talk about Java and they don't want to talk about Rust and they don't want to talk about Go because we are building everything here on C#. So the next level is sell. And sell is like tell, but a little bit softer. So in a sell, I, as the leader, the chief architect, the manager, the CTO, have made a decision. And now I'm going to go around and I'm going to talk to you about why this is the right decision for this group at this time. And so I'm going to sell you on it. I'm going to do a marketing campaign into the organization, into the team, and say, "this is it. This is why don't, I don't want to, I don't want to have a discussion about whether we're going to do this because we are going to do it, but I want you to understand the reasons why so that you can align yourself to this and try it out." This one for me becomes important when you are trying a new process, a new practice, or a new strategy in an organization that is different from things you've done before. And you say, "hey, we're going to be doing pair programming now. I know you guys haven't been doing pair programming in the past. I'm not asking for a discussion about pair programming. Let me tell you all of the reasons why pair programming is going to be effective for us and all of the things I expect you to learn and try as you adopt this new practice." And so to me, that's what sell is. It's the decision is made, but also there's a marketing campaign.

[00:18:27] Allan Stewart: I think that's important to help people understand, especially with sell. I like to think about it in terms of, like, the principles or the reasons behind a decision. So with tell, sometimes it's just arbitrary, or, and when it feels that way, sometimes people aren't very motivated, that they, they wonder, right? They're, they're questioning. Well, well, why, why are, why are we doing this thing? Why are we being told that we have to? And so sell gives that opportunity to say, "okay, look, I want you to be on board with this. I'm telling you why we're doing it. I'm just not giving you, I'm just not giving you a choice of doing it, whether that's, you know, all time or an experiment or whatever it is." And then the next level down from that, consult, is where the manager is going to specifically ask for input. The manager is retaining the decision. They're going to choose, but they want to hear what people have to say. Okay. Maybe, and there's a lot of times that where the individuals on a team will have good ideas and reasons why we should do things in a certain way or not do it a certain way. And so getting that input can be extremely valuable. But it's nice to have this level where there's clarity. And it's like, "yes, I do want the input. Tell me all about your passionate reasons, but then ultimately I'm going to choose it. I'm not, I'm not leaving this up to committee."

[00:20:04] Dave Adsit: Yeah, that's right. And it is important to have that person who is making the decision sometimes also to retain speed, because if you get into endless debate, you may never get anywhere. There's, um, There's this concept in group decision-making like Condorcet's paradox, where you might have different people who have a different preference, but their second preference is in such an order that the outcome is dependent upon the order of the voting. So even voting doesn't get you a clean answer. So there's so many problems that get solved by having one person retain decision-making authority for the group. And one of the examples that comes to mind for me here is, you know, you're getting together for an offsite and the manager might say, "hey, everybody, tell me where you want to go to dinner after we're done with our meetings for the day." And everybody gives their feedback and their input. And then the manager makes a decision, and they make a decision based on, well, one person's vegan and one person's celiac. And so I have to find a restaurant that's compatible with those. And that limits some of our choices. But, you know, like they have to make a decision that's appropriate for the group, whether it's the preferred decision of any one member of the group or not. Right. And the next, so the next level down the middle of the pyramid. The previous three were all manager makes the decision, or person with positional authority makes the ultimate decision with different levels of input. Now, the next one is agree. And this one is where we build consensus. Us. We all get together and everybody takes off their positional authority hats or whatever, and says, "we're all going to talk about this decision. We're going to make this decision as a group, and we're going to come out of the discussion or whatever with a decision that we're all at least willing to back."

[00:21:56] Allan Stewart: This one can be tricky because of the aforementioned committees and probably jokes about how Congress can't ever get anything done, the filibusters, and then the other arguments about, well, it was meant to be that way so that we wouldn't pass so many laws. But you can kind of break it up. And if you are going to delegate something down, right, if you're the person who has the positional authority, you have that responsibility, if you're going to use this agree level, I think you need to help people understand how are we going to agree or to what extent do we need to agree? Like, do we have to get everybody, like, a full quorum? Everybody has to be on board, or is a simple majority enough? Or, you know, the out of the six options, the one that has the most votes is going to win. Being clear on how that works allows, and, and what option and what options there are for experimenting, right? Like, maybe there's going to be 10 options on the, or 10 decisions we could make, and we're going to choose the best three and experiment with them and then make a final decision later, right? Like, there's a lot of different strategies here, but I think it's important for people to understand how it's going to work so that they can vote appropriately, I guess, so they can participate in that process. And then if they don't agree with, you know, this level is called agree. And if they don't agree, what can they do about that? And how can they continue to move forward and push our agenda forward without being mentally agreed with the decision?

[00:23:48] Dave Adsit: Well, and agree for me is the hardest level of decision-making because when you've decided that you're going to make this as an agree where everyone is participating in the decision, now you have to have either really good facilitation or really good moderation or some established rules to how this decision is going to be made by the group, as you've been saying. And maybe those rules are going to be told or sold or consulted versus the final decision is going to be made by the group, but I'm going to tell you guys how we're going to make the decision.

[00:24:29] Allan Stewart: Yeah. The term I was thinking of, but wasn't coming to mind, is disagree and commit. Yeah. How do you get to the point where I say, "well, you know, I don't really agree with this, but this is what the majority wants or what most people want. And I am willing to go ahead and commit to this plan of action, even though I personally am not a fan of that, that choice"?

[00:24:53] Dave Adsit: Well, and that's critical because very rarely will you have full consensus on a complex decision as a group of people. I mean, it goes back to why we got a bunch of people with different experience and different knowledge and understanding together in a team is under the expectation that they're not always going to agree about everything, and the disagreements are going to help us build something better. So the next level down and the first step away from the manager makes the decision is advise. And in this case, the team or the group or whoever, the person, the individual contributors contributors own the decision, and they ask for the advice of the chief architect or the CTO or whatever. And that person will come in and say, "okay, given the context that you've shared with me, this is what I would do. Or at least these are some things that I would consider very strongly in making this decision, but ultimately it's your choice." And that is the first level of real real delegation. It's the first step into delegation from the manager's perspective, letting your team make a decision.

[00:26:06] Allan Stewart: And I think this is a good level for helping people as they're getting started with delegating too, where you could say, "Hey, I'm not just going to thrust this decision upon you and go wash my hands of it, but I'm going to actually consult with you. I'm going to give you some ideas. I'm going to tell you about how I would go about this. I might I might even tell you my opinion on the particular issue, but I'm leaving it up to you." And so you have to be careful there that you're not, that you're giving them a real decision. You're not just, you're not just telling them, "hey, this is your decision, and you're going to hold all the blame. But if you don't choose this thing that I wanted, then you're in trouble," because that's, that's not real delegation.

[00:26:51] Dave Adsit: It goes back to my peanut butter versus honey on that, or jam versus honey on the sandwich for my son. I don't care which decision he makes. I might prefer that he chooses honey because the honey is already on the counter and the jam is all the way over there in the fridge, but I don't care what she picks. Yeah, this is, it's, it is very critical that you, as the leader, if you decide that this is an advise and you're advising the team and they're making the decision, that you do truly let go and let them do it. Sometimes you may say, "well, that'll be a learning experience," but we have to let people learn.

[00:27:30] Allan Stewart: The next level down towards full delegation is called inquire. And inquire is the level where the manager says, "this is your decision. I'm not necessarily going to coach you, consult you about or advise with you about how this is going to be. I'm giving it over. I just want to know what you decide. Let me know. But otherwise it's up to you."

[00:27:59] Dave Adsit: Yeah. This one is really important for me in a leadership role because there's a lot of decisions that I don't need to be part of. I have teams that are skilled and knowledgeable and aligned, and I don't need to be part of the decisions, but I might get asked about it. And so once you've made a decision, I would like you to tell me, please, what it was you decided. And if you do that, then if I need to talk about it in some other leadership context or whatever, I have the knowledge at hand to do my job. So this is a, this one to me is a really important one.

[00:28:35] Allan Stewart: Yeah. I've had similar experiences in architecture roles where understanding how a part of a system works lets me do better overall designs, but the team owns it. I might want to know so that I can help them, you know, discuss through some of the trade-offs or other things, but having an understanding of how another part of the system works, lets me make other kinds of decisions that, that move away from the responsibility of the team even if it's just to be able to share that information and say, "hey, I run across a team who's having a problem." And I say, "oh, well, I happen to know that the other team over there solved this kind of problem like this. Why don't you go talk to them?"

[00:29:22] Dave Adsit: Yeah. And the final level is delegate. And delegate is you go make the decision from the perspective of a manager. I'm going to say you go make the decision don't even bother telling me about it. I don't need to know. I used to always use the example of which code editor you're using. I let my teams pick. I'm like, "do you want to use JetBrains tools or do you want to use VS Code or do you want to use some other thing?" Uh, and I just like it doesn't matter to me the, the be comfortable in the code that you're in the tool that you're using so that you can write code effectively, but I don't need to know if you're some kind of of Vim guru. So I think we may be in an era now where there are some managers who are like, "I'm going to tell you, you have to use Cursor or some kind of agentic process or something." But I think for the, for the most part, delegating that is a thing that should be delegated to the developers.

[00:30:22] Allan Stewart: So that gives us the full spectrum, right? From tell where you're, you did not delegate at all, down through agree where it's kind of 50 50, right? Like, everybody's equally participating, and then at the far end of the spectrum is delegate, wherever where you've completely handed off the, uh, the responsibility of the decision. Uh, and, and having this spectrum, I found it very useful for clarity. I think you mentioned before, it's useful for people to know know where they stand on something. So an example is that technical leaders in a company might decide that they want to consult with all of the teams to get input because they're going to build a menu of approved technologies. They're retaining that decision because they know that if they run, if they let every team just go wild and use whatever technology stack that they want, that that can cause a lot of chaos. And it makes other executive strategy things more difficult, like how are we going to hire for all of these different technologies? Or if we need to shift teams around, can somebody on team A actually work on team B or are they completely different skill sets? And so then once they've made that decision about the technology menu, And because it's a consult, everybody knows that they're not picking, but their voice can be heard. And so they can give their rationale for whatever technology that they want to have on that menu. But then the technical leaders, having created the menu, can then go on to either advise, inquire, or even full-on delegation of the use of the technologies on that menu. So they can say, "hey, we've chosen these two databases and these three programming languages," let's just say. Any one of them we are okay with. If you want to use one of them, you have our blessing and we don't need to know, but you can make important decisions that way. And you can say, "oh, well, for this problem, we do need the graph database from the menu because the regular relational database is not going to be a good choice." And so you don't have to go and make a big fuss and have all this decision brouhaha trying to convince somebody, "can we use this new database?" Because you already know it's on the list, and you just go into it.

[00:33:06] Dave Adsit: Yeah. And that to me is a way that you as a leader can encourage people to make decisions that are appropriate in their context and move quickly and get things, you know, you can delegate more and do so with less fear and more safety because you've said, "hey, here's the menu that that we've selected. Or here are our architectural decision records that we've written. As long as you're in alignment with these, we're good. Here are the principles that we've laid down. Code has to be tested. Code has to go through a CICD pipeline. No manual deploy. You know, these things, these are our rules. If you're following our rules, then you have a lot more autonomy within your scope."

[00:33:54] Allan Stewart: Yeah, I think that's a very important aspect of delegation, is being clear with people. These are the boundaries. Are you making the decision or are you not making the decision? What guardrails, guidelines, resources to help you decide are there so that people know what to do? And then once they have that clarity, then they can move forward with confidence.

[00:34:19] Dave Adsit: And I will say that speaking of clarity, as a leader, as someone who has decision-making responsibility for organizations, I have found it to be very powerful to have a framework like delegation levels and use that when having discussions with teams say, "Hey, we're going to talk about database technology. This is a consult. I will be retaining the decision-making responsibility and authority, but I want to hear your input. Why should we use Postgres versus MySQL or versus MS SQL versus whatever? What are the things that you think should be on the menu and off the menu? Or I am having a discussion with you as a team about something you're building. I have strong opinions. I want you to remember that I'm only advising. You need to feel confident and comfortable to ignore my opinions if they are not relevant to the thing you're building." And so for me, I like to use this framework and train my teams on it and do practices on it, like the thing we talked about before with the databases and building a menu and things like that. I like to have those discussions and run those trainings and those practices so so that people understand the framework. And I can say, "this is a sell. I'm not open to you changing my mind. This is an advise. I am open to you doing the opposite of what I said," which allows people to move forward with more confidence because they know what I expect from them as their manager.

[00:35:56] Allan Stewart: One of the resources that Management 3.0 provides is a set of cards for doing delegation poker, so to speak. And we've used a similar thing in the past where we'll talk with a team, like the engineering group, for example, or the product engineering group, and say, "hey, we want to have some clarity on these." And in some cases, it's been interesting to see, to let people vote, right? If everybody can show their card of what they think, "Hey, here's an example problem. Should this be delegate? Like, what level of delegation should this be?" And people show up their cards. And then if they're already in alignment, then they'll pick the same cards or one that is very similar. Plus or minus one on the spectrum, right? But if some people are putting up a cell while other people are like, "no, delegate," that gives an opportunity for discussion. It helps people understand how do we come to these decisions. And so then it's not a question of, well, for every single decision, I have to figure it out. But they start to get the sense of, like, "oh, well, this class of decision, Dave always wants us to tell him about it, but he's okay with us making choices." But for this class of thing, Dave says, "no, because I'm going to have to, you know, budget for it in our AWS spend or whatever. So I need you to tell me, right? Like, you can't choose this, but you could come in and let me know if you need it because I'm retaining the spending decisions, for example."

[00:37:37] Dave Adsit: Yeah. And I, we've used this to create a lot of alignment and train that heuristic of what decisions can you make? Because it's important for people to be able to delegate. And one of the things that has to be delegated is some level of autonomy over, is this a decision I can even make? Because it doesn't help if you come to me every single time and say, "can I make this decision?" I mean, I just will just make the decision for you if you're going to bring it to me every single time to ask if it's okay. And the reality is that we do need to trust our engineers who are professionals, who are making a lot of very important decisions for our businesses. But yes, creating that alignment and training that mental heuristic of what decisions can I make with my team? What decisions do I need to go get leadership decision, leadership input on? Or is the leader going to just make the decision for me type of a thing?

[00:38:32] Allan Stewart: So there are some things to watch out for when you're doing delegation and specifically when you're using something like the delegation levels. If you're going to do something like a consult, you're a manager and you say this is a consultation decision. I'm retaining the decision, but I really want to know your input. If people feel like the boss is actually just going to ignore their input, then that could cause anger or disillusionment, right? So there needs to be a certain level of honesty in picking where you fall on the different levels. Or if you're using another framework, being clear about the intentions. Because if you ask people for their input and then you ignore it, or they feel like it must have been ignored. You know, every single member of the team, they get together afterwards and say, "actually, we all thought strongly X and nobody voted for Y, but the boss chose Y anyway," then they feel, you know, disillusioned that they're, "why did they even bother if they were just going to tell us why, why pretend?"

[00:39:44] Dave Adsit: I agree with that. You definitely I definitely don't want to create the false sense that your input matters, which is why I will, for some decisions, preface it with, "this is a sell" or "this is a tell." And that is my signal to my team that I'm not interested in having a discussion about this at this time. All of the decision, the decision has already been made, and this is not the time for reopening the debate.

[00:40:13] Allan Stewart: Which reminds me that it can also be useful in the cases where you are working that way to let people know what avenues there are. So if somebody does feel strongly about something, that they can know what's the appropriate way to go about it. Is it in our one-on-one meeting? You can raise it up. Or do you have a suggestions box or some other way of letting people interact with those things or get additional information about why, but still understanding that for now, this is a tell, or forever this is a tell, because this is just how we're doing things, right? Right. Like giving them that sense can can definitely be helpful. Then the other thing that I think about here is that once you've delegated, don't micromanage. An important part of delegation is being clear about what you want and then give people the chance to do it. And if they're going to fail, let them fail, because sometimes failure is the only really useful learning mechanism. You can tell people that they did it wrong a bunch of times, and they're like, "oh yeah, oh yeah, I forgot. I forgot to do the thing. I forgot to do the thing." Until you let them fail, and then there's a problem, and then sometimes that's the wake up call, and then they never fail it again because they got scarred by it. Um, and so going along with how you delegate, it's also important to understand the stakes that you're delegating. If the stakes are low enough that failure isn't a problem, that's ideal, especially as you're building up somebody and helping them with that autonomy, with that mastery, with their own personal growth. Well, if they feel like they're going, if that they, if they feel that a failure is going to be the end, then they're going to be very risk averse, and they might not try things. They are, they might freeze up in analysis paralysis, but if they, if they understand, it's like, "hey, look, we're not trying to fail, but if you do fail, it's going to be okay. Or, or maybe we can fail a couple of times before we get it right. And that's going to be okay." Gives people some breathing room. It helps them to actually learn and perform better.

[00:42:40] Dave Adsit: That's true. And I will say that delegation is a skill. It's a critical skill for anyone in a leadership role and for people who aspire to leadership. Being able to delegate effectively to your teams is a way that you expand your influence, expand your reach, and grow your system. If you are unable to delegate, then you will become the bottleneck. You will hold back your team. You will hold back your organization. And it will make you a very ineffective leader, whether you're a distinguished engineer or an architect or a manager, VP, CTO type title. Whatever your leadership role is, if you are able to delegate effectively, then you will be a more effective leader. And using something like the delegation levels framework can help you get better at delegating and also help train your staff on how you're going to delegate to them and how often and what types of things. And so it can all around develop stronger skills, more autonomy, more mastery, hopefully aligned with your shared purpose and allow you to create both motivation and speed inside of your organizations.