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. I'm Dave Adsit, an engineering leader,

[00:00:37] Dave Adsit: and recently I've been thinking about different types of communities of professionals

[00:00:42] Allan Stewart: which serve different purposes. 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? 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. 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. 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,

[00:02:53] Allan Stewart: increasing both autonomy and mastery. 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 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? Right. And so speaking of teams, it has been found... 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 and military situations so that people don't get stuck following bad orders when... Yeah. So... 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? 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. And I think this happens a lot in

[00:06:11] Allan Stewart: software development teams where there's a lot of complexity that goes on and engineers tend to be 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. Right. 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 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 at Zappos, if they had to go and ask for permission every time that they want to do a refund. Right. Or send out a, you know, 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, that really, really slows down your decision-making. And one of the things we want in some 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 the speed. And that's what we're doing. And that's what Any decision-making authority.

[00:08:21] 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, 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.

[00:09:50] Allan Stewart: Yeah, 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 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, 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. 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.

[00:11:31] Allan Stewart: Yeah.

[00:11:32] Dave Adsit: 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. And get the advantages of smaller batches.

[00:12:43] Dave Adsit: That's 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're not. They can learn to build teams they trust and develop groups that will make decisions that they are aligned, that they're 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. 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? So we need to be, we need to be willing to train them and build up that, that skill, that mastery that allows them to operate in alignment with our purpose.

[00:14:58] Allan Stewart: And 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 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 Apollo's book management 3.0. And it's just called the decision delegation framework. Mm-hmm. Or delegation.

[00:15:38] Allan Stewart: Levels, I think it's called sometimes. Delegation levels, 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. Tell. There are seven levels. I should probably 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 this 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, 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-sharp 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-sharp. So the next. Level is sell and sell is like tell, but a little bit softer. So in a cell, 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. And I 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 it. 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

[00:18:27] Allan Stewart: marketing campaign. 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. Maybe, and there's a lot of times that where the individuals on a team will have, good ideas of, 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. That'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

[00:20:02] Dave Adsit: leaving this up to committee. Yeah, that's right. And it is, 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 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 a different, 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 like 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. then I can find the option, but if I can't find the option, then I can't find the option, but if I can't find the option, then I can't find the option, but if I can't find the option, then I can't find the option, but if I can't find the option, then I can't find the option, but if I can't find the option, then I can't find the option, but if I can't find the option, then I can't find the option, but if I can't find the option, then I can't find the option, but if I can't find the option, then I can't find the option, but if I can't find the option, then I can't find the option, but if I can't find the option, census. 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

[00:21:54] Allan Stewart: we're all at least willing to back. This one can be tricky because of the aforementioned committees and probably jokes about how Congress can't ever get anything done. And 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, 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? Do we have to get everybody like a full quorum? Everybody has to be on board or is a simple majority enough or out of the six options, the one that has the most votes is going to win. Being clear on how that works and what options there are for experimenting. Maybe there's going to be 10 options on the way or 10, new option option option option option option option option option option option option option option option option option option option option option option 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, the, the person, the individual 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 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. You 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 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. That's right. Then 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 a 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 advice. And you're advising the team and they're making the decision. 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:31] Allan Stewart: The next level down towards full delegation is called inquire. And inquire is the, is the level where the manager says, this is your decision. I not necessarily going to coach you, consult you. I'm not going to advise you about, or, you know, 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 the 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. 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. Let's 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. Let's 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 him?

[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? 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 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 API. 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, the responsibility of the decision. And having this spectrum, I found it very useful for clarity. I think you mentioned before it's useful for people to 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. Yeah. 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, you know, 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, once they've made that decision about the technology menu and, 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, you know, 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, 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. Bruh, ha ha. 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. Yeah. 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 we've made that we've selected. Or here are our architect 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 CI CD 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 make. 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:20] 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 my sequel or versus MS sequel 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 be 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 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. If everybody can show their card of what they think. Hey, here's an example problem. Should this be delegated? 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 sell. 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 just. 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, 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, 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 the 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, I'll 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, your input. If people feel like the boss is actually just going to ignore their input, then that could cause anger or disappointment. Disillusionment, right? So there needs to be a certain level of honesty in picking where you fall on the, on the different levels, or if you're using another framework, you know, being clear about the intentions. Cause 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 at this. And nobody voted for why, but the boss chose why anyway, then they feel, you know, disillusioned that they're w 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 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 cell or this is a tell, and that is my signal to my team that I'm not. 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, what avenues there are. So if somebody does feel strongly about something that they can, they can know what's the appropriate way to go about it. Is it in our one-on-one meeting? You can, you can raise it up or do you have, you know, a suggestions box or some other way of, 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. Like giving them that sense can, can definitely be helpful. Then the other thing that I think about here is that once you have. Delegated don't micromanage. Right. It, 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, 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, and then sometimes that's, that's the wake up call and then they never fail it again because it got scarred by it. 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. 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 that 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 can. 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.