In today's episode, we are in conversation with Spencer Norman and we talk about Delegation; what it is and what tips and tricks there are to master it.

Guest: Spencer Norman https://spencernorman.com/

Show Notes:

Spencer's Twitter: twitter.com/spencernorman
Spencer's Linkedin: linkedin.com/in/thespencernorman/

The RACI Model : https://monday.com/blog/project-management/raci-model/Comfort, Stretch Panic Model: https://www.crowe-associates.co.uk/coaching-tools/comfort-stretch-panic-coaching-tool
Eisenhower Matrix: https://asana.com/resources/eisenhower-matrix

Transcript auto-generated by Descript.

5-

Aaron Rackley: [00:00:00] Hi everyone. My name's Aaron and welcome to this episode of the Tech Leadership Decoded podcast. The podcast where through conversations we unraveled intricacies of leadership in the tech industry and provide insights on how to become a top performing leader. Today we're in a great conversation with Spencer Norman answering the question, what is delegation and how do I master it?

I hope you enjoyed this conversation as much as we did recording it. And if you'd like this conversation, please do remember to subscribe to this podcast on your favorite player and stay tuned for upcoming episodes. And if you're a tech leader and would like to come and have a conversation with me about a subject you're passionate about, please email me via contact@techleadershipdecoded.com.

And with that, let's get straight into today's conversation.

Okay, Spencer, and thank you for joining me today. Um, and we're going to have hopefully a very super fun topic of discussion, which is delegation. So the question I will be [00:01:00] asking today, and hopefully you'll be answering, is what is delegation and how do I master it Now before we get. Into that conversation.

Why don't you just quickly introduce yourself and just let us know your career and basically why you're interested in delegation in general. Wonderful.

Spencer Norman: Well, so nice to chat with you today, Aaron. Uh, my name is Spencer. Uh, I'm a engineering leader at Privy, uh, privy. We build software for, uh, e-commerce retailers and businesses to, to market effectively to their, their audiences.

We focus mostly on, uh, small to medium sized businesses, and we build tools that. Allow them to, to grow their lists, to, uh, market via email and sms. And I've been in e-commerce in some fashion for the, the better part of my career. Uh, prior to being here, I was with, uh, a company called MailChimp. [00:02:00] Uh, which was acquired by Intuit.

Uh, I got to MailChimp, uh, via an acquisition of an open source e-commerce platform software. So we built e-commerce software, uh, with node js. Uh, we built a, a fairly large open source project that, that MailChimp ultimately bought and turned into a, a product that is now called MailChimp Open Commerce.

Okay. Uh, we had contributors and, and users all over the world of that software. Um, And prior to that I worked in a, a startup that rented outdoor gear and, and shipped it all over the, the country. Uh, I'm based in the, the US and Colorado. Um, and we would rent mostly ski and, and snowboard gear and we would deliver it directly to customers rooms.

And one of the challenges we had there was around the rental model where anything that we sent out had to come back. Mm-hmm. And we had to wash it and we had to get it ready. And there was a decent amount of. Kinda logistics and [00:03:00] planning, uh, software that we had to build to make sure that the inventory we were projecting for the late ski season was actually, you know, going to be available, uh, after it had been used a few times.

So, been in e-commerce for a while. I've been in software leadership for, for a while. Um, and I think delegation is an important topic to me because it's, uh, as one of my former managers would, would tell me. Uh, it's really how you scale yourself, um, going from what can I do individually to, to help the company or to, you know, solve a problem to, you know, how can I solve a problem that's bigger than something that I can handle all by myself?

And I think mm-hmm. The, one of the answers to that INV involves learning how to in, you know, incorporate other people into that solution. And I think delegation is a really key part of that.

Aaron Rackley: Yeah. So let's start off with, um, a basic definition of how you are defining delegation in the context of [00:04:00] leadership.

Spencer Norman: Yeah, so I think I, I, I see delegation as. Uh, something that is multifaceted, but there's kind of two different A approaches that I'm gonna look at when delegating. Mm-hmm. So one is, as a leader, you're gonna hire people who are better than you at something, and I think that's just a really important part of leadership.

Uh, you should not be the best at everything on your team. There may be certain tasks or skills that you have that you have not hired somebody else to take over, but you know, by the time you get to a certain size or a certain size team, Uh, you've hopefully hired people who are specialists in certain areas, and so you may delegate certain types of decisions or certain types of tasks where you have somebody on your team that you've specifically hired to be really great at that particular, uh, type of work.

So, you know, I would call this, uh, type one delegation is, is what I've referred as, and it's because you're, you're [00:05:00] delegating it because you are not the best person on your team to do it. I think there's another. Layer of delegation that is more about growing your team. I've called this type two delegation, uh, and I think it's when you have something that, that you need to have done, but the, the criticality of that task is not so high.

That it must be done perfectly or it must be done right the first time. And you can use these types of tasks, uh, to help people who are either newer to leadership or newer to a certain skillset, start to develop that skill. Um, so you know, this is, you're delegating because it's an opportunity to learn for somebody else.

Aaron Rackley: What do you think? The most common kind of misconceptions do you think that people have around delegation?

Spencer Norman: Yeah, it's a great question. So, uh, I guess the first place that my mind goes is toward, uh, just kind of like what [00:06:00] is the context that somebody needs? And I, I think let's, let's both focus very specifically on.

Delegating decisions mm-hmm. Rather than maybe tasks. So yeah, we're, we're not talking about can you send somebody to go get the coffee? We're talking about can you delegate the decision making authority for something that ultimately may matter. Mm-hmm. Um, and I think that, you know, what con I think about what context does somebody need to have in order to make that decision?

And I think there's, there's two ways. One of my old bosses, Sarah Hicks, who was, uh, the CEO at Reaction Commerce and the leader at at MailChimp for a while. She taught me that we can either push information to the people who have decision making authority, so you can try to aggregate everything that everybody in the company knows, and you can try to push that information up to whoever the boss is who ultimately, you know, has the the authority to decide something.

Or you can try to do the inverse of that and you can try to take that decision making authority and push that to the people who have the [00:07:00] information. And, you know, I think about both of those is you're gonna have information flowing both ways. You can't ever take all of the information, you know, and it's not always going to be exclusively in the domain of a single person or a single department.

But if, if we try to push the decision making authority to the people with information, which I really do think is a, is a core part of delegation. One of the other things that I think we have a responsibility as leaders to do. Is to push the context that we believe is important for that decision. Now, maybe it's, you know, company priorities.

Maybe it is, uh, you know, kind of the, the ultimate timeline that we want for that particular task. Maybe it's, uh, a list of other people, other stakeholders that need to be involved in that decision. But I think one of the things that goes wrong about delegation fairly frequently is that we ask somebody to, to decide something.

Mm-hmm. We don't necessarily give them the context that they need, that we have to make that decision [00:08:00] effectively. So we say, Hey, can you, can you make a decision about, I don't know what cloud provider we should use? Mm-hmm. And then when they decide on, I don't know, GCP or, or some specific technology, They come up with that decision and they come to us and we're like, oh, maybe not that decision.

We, we actually wanted you to make a different decision. And as soon as we start second guessing the decision that they've made, I think it, it usually means two things. One, they're not gonna feel as confident or as comfortable to make decisions. Mm-hmm. In the future. We've already kind of taken that power or that, that authority from them.

And two, it probably means we didn't actually do a good job of communicating the context or, you know, what was important if they made a different decision than than we thought they, we, we should have made. Uh, did you actually delegate that decision and did you, you know, share the, the information that, that you felt was important?

Aaron Rackley: You know, I agree. Um, I see this quite often because I do a lot of, um, kind of like solution designs for clients and stuff, and [00:09:00] sometimes, like you say, I can forget to give that, um, context to software engineers. If I say, can you go and find me a CMS system for this client? But I might not have given them the necessarily information of like the budget for example, for that project.

Cuz there's a lot of CMSs out there and they variety, um, price. Okay. And licenses as well. Like some places don't, they like to host their own, they don't want to be hosted as well. Right. And I think that's definitely an interesting, um, Have interesting thought there. Um, so thinking about that then, what do you think are some good strategies or best practices for basically effectively delegating these tasks?

Spencer Norman: Yeah, so I, I think one of the things that is maybe most critical here, uh, and I've actually talked a little bit about this at. Uh, a conference called Lead Dev where I, I dug in specifically on this. I think it's really important to be clear [00:10:00] about what you're delegating. Mm-hmm. Uh, and in, in some cases. And then, and really how much autonomy, I guess is the other piece.

How much autonomy do you want to give? Um, I think another, I guess going back to your misconceptions question, but another misconception that people can have is when you delegate. Maybe they think they're just supposed to go off in a hole and they're gonna come back. Mm-hmm. You know, in a week or in two weeks or in a month with a fully thought out decision.

And, you know, you're delegating it because you don't wanna be bothered with the decision. Yeah. And that may be true in some cases, but I think frequently you're trying to say is, Hey, can you go do some research on this? Or can you, can you collaborate with me on a decision? And if, if what you want is for somebody to check in with you, if you want to ultimately, Uh, I think about the kind of consulted, informed, uh, kinda responsible, consulted, informed model, right?

So if, if you still want to maintain, uh, some ability to, in [00:11:00] influence this decision, make that very clear. You know, if you want somebody to inform you after they've made a decision, that's a, that's a different. Approach here as well. So I, I do think being really clear about what decisions or what information gathering or what, uh, tasks you're intending to delegate, uh, and what you would really still do want to be consulted about is pretty important.

Uh, and then I guess another thing that stands out to me here, and this is just kind of stream of consciousness thinking, but delegation really doesn't absolve responsibility. So as the leader, you're still responsible for making the right decision. Yeah. And when you ask somebody on your team or somebody in a different department to take on a certain part of that, that does not absolve you.

If that goes poorly, that does not absolve you of the responsibility of making that decision. You still have to own that, and you have to own that. You know, in, in, in some ways your decisions to delegate parts of that will impact the outcome. And I think [00:12:00] in the ideal case, and for a great leader, it's gonna impact the outcome well because you've built a team that is capable of, you know, filling your gaps and taking on things that you are not necessarily great at.

But there's certainly a, a negative flip side to that, where if you delegate things to people who aren't ready for them, or if you give away too much of the project, you can end up with. Uh, you know, a, a poor decision on your hands that, that you have to be, uh, still responsible for.

Aaron Rackley: Yeah, no. Um, just, uh, you quickly threw in there the, um, I think it's like the racing method, didn't you, that, uh, do for people that obviously might not know.

Do you, could you quickly explain what that is just for two

Spencer Norman: seconds? Yeah, so I guess the, there's a ton of different versions of this framework, uh, but there's, you know, a number of, of frameworks for, I guess the, the RCI is kind of the, the typical term. But it's stands for responsible, accountable, consulted, and informed.

And it's, uh, typically [00:13:00] displayed as a matrix of, of people and their role in either a decision or a project or, or something else. And I think of, you know, the, let's say the accountable party as, as the one who will ultimately answer upwards to somebody for either, you know, the decision or the project. You then have a responsible party.

And sometimes these roles will overlap. You know, I think especially at smaller companies, you may have the accountable person who is also responsible, uh, for the, the decision making. You have a, you know, somebody who is in a responsibility seat, who is tasked with getting this work done. And then the other two I think are really interesting in the context of delegation, and that is someone who's informed.

Uh, so the I of the RACY stands for informed. And typically what that is, is, uh, Somebody who needs to be told about the decision, but doesn't need to be involved in the, uh, process of choosing the decision. And one, once that decision has been made, you need to make [00:14:00] sure they're aware of any changes that, that, uh, it implies consulted is, is a little bit different.

It's not necessarily the person who's responsible, but they will have a stake in this. And if you make a decision without consulting them, without, uh, considering their needs or, or their. Uh, requirements in the, in the process, you're gonna end up in a spot where, you know, maybe you made a, a decision that doesn't actually meet the needs of everybody at the company or mm-hmm.

You know, you're, you're building something that doesn't capture all of the, uh, you know, different elements. Uh, so that's how I think about the raci mm-hmm. Chart. There's again, I mean there's, if you google this, some of these different versions, there's a hundred different versions of this and people who use different words, but I think in terms of delegation, As the, as the leader, one of the most important things that you can clarify for your team is, do you wanna be consulted on this decision?

Do you want them to come up with some ideas and, and kind of pitch them to you and, and convince you where you're maybe still actually making the decision or at least [00:15:00] still in involved in that? Yeah. Or do you wanna be formed? Do you want them to go off, make a decision and just let you know when it's changed?

And those are gonna be very different. Approaches to that delegation. And it's not that one of them is good and one of them is bad. It's more that there are reasons to choose, uh, each and in any given context.

Aaron Rackley: Yeah. No. Awesome. Thank you for explaining that. I thought it just ties in nicely to what you were saying.

Um, So you mentioned some good strategies, some kind of nice practices, but you also kind of alluded to kind of like some risks. So what kind of potential risks or pitfalls do you think that leaders can have when delegate into their teams? Like, what can we, where can we avoid? Well, what should we try and avoid?

Yeah,

Spencer Norman: yeah. So, I mean, we talked a little bit, I think about the, you know, avoiding, uh, lack of clarity around what it is that you're actually. Yeah, delegating. Um, I think another pitfall and, and I talked a little bit about this, [00:16:00] but is trying to delegate something without delegating any of the decision making.

So if you want somebody to, to do something, but you want them to do it your way, yeah. Are you actually delegating that? You know, I think it's important to ask yourself, like, why do you want this other person to take on that responsibility if you already have a decision in mind. Now I think there are reasons to, you know, maybe coach somebody through how to think.

About a particular problem. But if you're trying to get somebody to do all of the work, but you just want them to do it the way that you would've done that, I, to me, that's micromanagement. You know, that's really not delegation. So I think that's a, a piece, you kind of have to find this happy medium between micromanaging the, the work and totally abdicating responsibility.

Because again, you can't, you can't just. Assign something and walk away and, you know, not care about the result. Um, so I think that's a, that's a [00:17:00] piece. Um, so, and I think that comes through really providing that context, making sure that it's clear what is important about this decision, and then providing the person as much autonomy as you can.

And that's gonna be different for a more senior person in a, in a leadership role who has maybe the specialized skills to do this well than it is for somebody that you're coaching and trying to grow.

Aaron Rackley: I think that's interesting because the other thing that I think can come from delegate, uh, delegation is helping to build trust in teams and individualism is do you have any thoughts around that area?

Spencer Norman: Yeah, so I do think there's, there's, there's a lot that goes into this, right? Mm-hmm. And there's a, there's actually a, a framework that I like. Um, which is panic, stretch, comfort model. Okay. Is kind of how I've thought about this before, but when you are, when you're delegating work, I think one [00:18:00] of the, the key factors of whether that work will be successful or unsuccessful mm-hmm.

Is how comfortable is somebody at taking, taking on that work. So let's call that one. And then the other piece is how psychologically safe do they feel to fail? And when you are delegating something to somebody who does not feel safe to fail mm-hmm. They're going to take the easy path. Most of the time, they're gonna take whatever it is that, that makes them most confident to succeed, even if maybe that's not the best solution or the best outcome.

So there's a, a model that I've liked, which is, again, it's the comfort, stretch and panic zone. Mm-hmm. And the comfort zone is a, a place where, Somebody has operated before, they're very familiar with that domain or with that technology. Um, they, you know, feel highly confident they can do it. It's not something that's necessarily gonna push their boundaries or [00:19:00] stretch them at all.

The stretch zone is, is that area where somebody is, you know, Maybe capable, but maybe they don't know that they're capable of this yet. It's, it's something, you know, I think if you think about the more junior engineer or somebody stepping into system design for the first time mm-hmm. And you know, they can do it, but maybe they don't yet feel confident that they can, they can lead that.

Yeah. Um, and so that stretch zone, I think the size of that stretch zone is going to be very dependent on what happens to people if they make the wrong decision. And in a, in a very psychologically safe organization where, uh, failure is not met with animosity or punishment, yeah, you're gonna have people who can really grow into these exceedingly leadership oriented roles.

You know, maybe they fail the first time, but I think often it's just that safety to fail that allows somebody to take a chance and to prove that they are very [00:20:00] capable of doing whatever that that work is. Beyond that stretch zone is the panic zone. And I, again, I think in a psychologically safe organization, the panic zone shrinks pretty significantly.

Mm-hmm. And a place where it's not safe to fail, though often you'll have your comfort zone and then immediately outside of that comfort zone is the panic zone. Okay. And anytime you're asked to do something that you don't feel confident about, you're gonna panic because you know that the responsibility or the, the say, the consequence of failure.

Is significant. And so I think as leaders, the more we can do, uh, you know, not to make failure on the, you know, organizationally impactful side of things. Easy. We, we do want to be responsible about how we fail. Mm-hmm. But to make, you know, that possible for people to fail in a way where they're growing and learning and it's not catastrophic, we'll actually make it much easier for people to grow into new roles and to take on new responsibilities.

[00:21:00] Um, So that I, I think of that as, as a way to build trust. And when you are delegating to people, one of the things to think about is, is this something where I'm delegating it because it's in their comfort zone and I know that they can do it really well? Yeah. From the beginning? Or is this more that type two delegation where this is intended to help them grow?

It's intended to help them stretch. And in that latter case, are you gonna put somebody into their panic zone where they're probably un incapable of? Operating effectively, or is this something where you're putting them into the stretch zone and maybe you need to pair them with a mentor. Maybe you need to pair them with somebody who can help them do that well, but you still want them in the, in the driver's seat.

In

Aaron Rackley: your experience, do you think there's any indicators, uh, that leaders maybe need to delegate more or how can you tell if you're not doing it? Correctly, as we just said before, the balance, right, of getting people that are gonna do it well, people that are [00:22:00] gonna push themselves. Like how do we get that?

Mm, how do we know if we're doing it wrong? Or how do we know if we need to do more of it?

Spencer Norman: Yeah, that's, that's a great question. Uh, I think this is probably more art than science if Yeah. If I'm on it. Uh, so I don't have a, you know, I don't have a specific gradient I can give you that will, you know, allow you to put yourself in a, in a spot, at least the whole

Aaron Rackley: point of the podcast, right.

Get many people's artistic opinions.

Spencer Norman: But I do think, I guess a few heuristics I would look at. One is, are you totally stressed out and overwhelmed? Mm-hmm. Right? And, and as a leader, You know, I think there's, there's only so much you can do as an individual and the bigger your team is or the bigger the types of, you know, projects or tasks that are being delegated to you.

So unless you're, you know, the founder or ceo, Chances are that you're not the top of the chain and somebody else is delegating something to you. And that's why you have a job is because somebody has asked you to take responsibility [00:23:00] for something, you know, and the, uh, more senior you are in a, in a company or an organization, the bigger those chunks of of work or those, those projects are going to be.

So, you know, are you trying to take on too much of that? And I think the, the main heuristic I would look at is, Are you incredibly stressed out about how much work is on your plate? Mm-hmm. Uh, so if that is the case, what is it that you can take off your plate by asking somebody else to do? And in some cases, this may be something where you don't feel like you have a team member who is gonna be great at this.

And I think that's where, you know, kind of the management, uh, I'll call it a responsibility, but the, the management opportunity, let's say, to grow people on your team, just because you don't have somebody who's good at something now doesn't mean that you don't have somebody who can take this on and learn it.

You know? And if you've hired a team of, of great people, one of the things that I look for in hiring is, you know, kind of a [00:24:00] growth mindset and somebody who's coachable. And so can I teach somebody who maybe is not an expert at this, how to do this well? And in the first time you do it, it maybe doesn't remove a lot from your plate because instead of doing, now you're coaching, in some cases, I think coaching is actually, you know, more effort or, or at least different effort, but the same amount of time.

But what you do is you take that particular topic or that particular domain and you build expertise on your team about it. Um, and so I think that's, that's one of the pieces. I think the other thing, and this gets a little bit at hiring and, and team building, But how do you build a team that can fill the gaps?

Mm-hmm. You know, I think one of the things for me that will lead to stress is if I feel like there is a task that needs to get done that I personally don't have expertise to do, and I also don't trust anybody else on my team to do it. And that's scary because I know this has to get done and, [00:25:00] you know, I don't, I don't know necessarily that I can do it well.

And so that I think is, is part of that team building conversation where you, you do wanna make sure that you're aware of your own, uh, skill gaps. You're aware of the things that you're good at and the things that you're not good at. And those things that you know you're not good at, you can hire for those.

You know, there's no expectation that a leader has to be the best at everything. And I think. The best leaders are very quick to acknowledge mm-hmm. Where they're not experts. Yeah. And to make sure that they are filling their team with people who can, uh, help them with those things.

Aaron Rackley: Yeah. I think I've found the best leadership that I've worked with in the past, there's always been people that know where their shortcomings are and their, their weaknesses are, and that allow the team to.

Pick up and take that information. Right. Um, so I think that's really interesting. I think, um, one question I actually just thought of is, let's think about this from a non [00:26:00] non-leadership mindset for two seconds. So I'm part of a team and I can see that my leadership is probably doing too much and I think I can offer some help.

Do you have any. Advice on like how you'd approach that,

Spencer Norman: right? Yeah. So I will caveat this by saying that I think approaching people in leaderships or in leadership positions can be one of those things that operates differently. Yeah. For people in a privileged position. And I think for me, uh, I certainly am.

So I would say, you know, first, first is to, to make sure that the groundwork is there Yeah. To approach somebody in, in a position of power. Mm-hmm. Um, so do you have a relationship where you know, you feel comfortable? Either broaching the subject that you don't think that they are doing something well, you know, providing that feedback.

I think this project is not going as well as it could [00:27:00] go. Or, you know, something like, you know, giving them feedback that you think you might be better suited for a particular type of worker project. So I think before broaching that is, is to make sure that you feel like you have a, a relationship with them where that will Yeah.

You know, Be appreciated and, and not punished. And, and I think that is gonna be different for every person. And I can't give specific advice on Yeah. You know, any, any individual's position, but assuming that you do have that, that relationship and that groundwork. Um, I think the, the thing that I appreciate is when somebody identifies something that is, Either not going to plan or, you know, where there is a gap either in the organization or in the tech stack and brings it to me and says, Hey, I think this is a problem and I would like to personally help fix that.

Yeah. And I think the, the next layer of that is to, you know, bring a, a solution or, or some, some approach where I can actually see the [00:28:00] thought work that they've already done on that. So, you know, I think it's one thing to identify a problem. There's. People I've worked with who you know, will say, don't bring me problems, bring me solutions.

I think that can be naive. I think it's, you know, it's valuable to know where your organizational blind spots are. Yeah. I tend to not try to dissuade or I tend to encourage people to bring problems even if they don't have a solution. But I think for the more senior folks, and I think when, for me, when, when you get to be, let's say a staff engineer, one of the things that I'm looking for from my staff engineers, Is for somebody who can not only solve a problem, but they can also identify the problem.

Yeah. You know, I think of a, a great senior engineer, I think of as, as somebody who I can delegate just about anything to. Mm-hmm. You know, I see a problem or I see a business need, or I, we have a particular product that needs to get done. Senior engineer can do all of the coding, they can do all of that work.

A staff engineer needs to be able to proactively identify problems that we're gonna encounter in the future. [00:29:00] Make a business case for why that needs to be done. And you know, then in some cases they also need to be the one to execute and, and ultimately solve that. So, you know, I think kind of proactively stepping in and, and volunteering to take something on is, is a great place to start if you're wanting somebody to, you know, delegate something to you.

Um, I think having, having that conversation, um, And one-on-ones is a great place to do it if your organization has a, a good habit around one-on-ones. I know a lot of organizations that don't do a good job delegating, probably also don't have, you know, great one-on-one meeting cadences. So, you know, there's other ways to do that.

I think if you don't have those one-on-one topics, put together a proposal, you know, maybe it's an rfc, maybe it's a tech spec, but something that identifies the problem, the context, why you think this is important. And then, you know, there's always gonna be various degrees of this, but to some point, how you would think about solving the [00:30:00] problem.

Yeah. How much resources you think it's gonna take. Why it's, why it's gonna be important to the customer, to the business. Yeah.

Aaron Rackley: And then I think on the other side of that is, um, you know, how we respond as leaders when that that comes forward. Right. Um, so I think what, like what you're saying there is just be open-minded, don't.

You know, I think the nicest way is don't be a dick. Right. Don't be nice about it. Right. Um, cuz like you say, for some people it can take a lot of courage and a lot of, um, well courage is probably the best word. A lot of courage to come forward and even put themselves into that position. Right. Absolutely.

So,

Spencer Norman: cool. I think that's a, that's a great point just to riff on that for a second. Yeah, go for it. But even, even if somebody brings something to you that seems. Idiotic, right? Yeah, it, I think it can be valuable still to recognize the effort that went into putting something together and being willing to approach somebody in a leadership position about [00:31:00] it.

Even if you think, Hey, you know what, this is really dumb. I think acknowledging that effort and trying not to dissuade them in the future because maybe this idea. Ultimately wasn't the right idea. But if you squash that type of approach, or you squash that idea, or you squash that effort that somebody's making to proactively solve problems, mm-hmm.

Guess what? They are probably not gonna bring you something in the future. Yeah. They're gonna keep that to themselves. So I think even in cases where it's not this, you know, solution or perfect problem that you actually care about. Continuing to encourage that. Maybe you don't prioritize that particular one, but encouraging that type of behavior is really critical.

Yeah,

Aaron Rackley: no, a hundred percent agree with you there. What advice do you think we can give to leaders who might struggle with delegation or, you know, hesitant to let go of control?

Spencer Norman: Yeah, so there's a, I guess it's like a matrix. I think it is a riff on the Eisenhower Matrix that I've, I've used to [00:32:00] encourage people to.

Figure out what types of things they can delegate. But it's, it's a two by two matrix. And on one axis we have, let's call it the kind of the consequence gradient. Yeah. So we wanna map things from low consequence to high consequence. And I think that that in terms of, let's say the impact of, of something not going to plan.

Mm-hmm. And then on the other axis, we have the reversibility. Of that action. So you know something that's very reversible, you make the wrong decision, you can make a different decision tomorrow and, you know, just change, change your mind and it's not a big deal. Or, you know, at the other, a end of that axis you have something that's totally irreversible.

You know, maybe it is, uh, firing somebody might be an example. Like you can't undo that. If you make the wrong decision about firing somebody, they're not coming back. Uh, and so you can, you can map this out and so you have kind of four quadrants of [00:33:00] this matrix. You have inconsequential and irreversible, so something that really doesn't matter, but if you make the wrong decision, you can't undo it.

Mm-hmm. You have below that, let's say inconsequential and reversible. You have consequential and reversible, so something that really matters a lot, but if you make the wrong decision, it's not terribly difficult to change it. I think of many code changes that don't involve the database as being in this consequential and reversible yeah, segment where maybe it's a big deal, maybe the app goes down, you know, it's not great.

We don't want that, but. You can push a revert in seven minutes if you have a, you know, a good yeah. Ci cd stack, and it's always over. You're back online. Now, learning, again, you don't want to be taking down your whole production app a lot, but as long as it's reversible, there's some opportunity there to, to allow people to, to flex.

And then in the the final corner, kind of this top right, you have consequential and [00:34:00] irreversible. And these are decisions that are both, you know, of magnitude either to your team or to the business. And also, you know, a lot more difficult to undo if you make the wrong decision. And I think as leaders, the more of our time we can be spending in that consequential and irreversible segment mm-hmm.

The better. And if you kind of flip on the other axis, Uh, I think inconsequential and reversible decisions, you should almost never do those. One, they don't really matter. You know, in the grand scheme of things, which decision you make, probably not gonna matter long term. And if you do make the wrong decision, you can reverse it.

Those should be delegated almost a hundred percent of the time. So identify the things that you're doing that just, you know, aren't gonna move the needle. And can you have somebody else take those on? Not necessarily because you think they're the best at it, or because you're. Happy to give it up, but because there's just an easy way for you to, to undo it and, you know, [00:35:00] the, the net impact is gonna be low, I think of inconsequential and irreversible decisions as a great training ground for other leaders.

Yeah, these are the types of decisions where we're gonna have to live with them for a long time, but maybe they aren't quite so impactful as to to really matter. And so it can be a, a place for you to coach. Help somebody make the right decision, because again, you're not gonna be able to make a new decision on this later.

Uh, so identify those things that, you know, may be unchangeable, but just are, are lower impact. Yeah. And I think that's a coaching opportunity. You wanna delegate it, you wanna be consulted on these, not informed is kind of the mm-hmm. The, you know, the framework I would look at. And then kind of on the flip side, I think is another great place for future leaders, but that consequential and reversible.

Where this is a place to get experience doing high impact decision making or, you know, yeah. You know, thinking about something that really does impact the [00:36:00] business. But if they end up being wrong, well, we can make a new decision tomorrow. We can make a new decision next week. We can make a new decision in the next quarter.

And so think about, you know, how long are we gonna have to live with this decision? Uh, you know, and that reversibility is always gonna be a, a gradient. You know, there's never, never just, it's reversible or it's totally. Irreversible, uh, you know, usually there's a, a spectrum there, but how long are you gonna have to live with something?

And I think if you're able to walk through an exercise of taking, you know, let's say the, the more important things that you do on a week to week basis, and you kind of plot them on, on this chart. Make sure that where you're spending most of your time is in that, uh, that that quadrant where it's consequential and irreversible things, and then figure out for anything that's inconsequential, how do you have somebody else on your team do that?

Mm-hmm. And again, I think the, the more senior you are in, in an organization, the, the, the more consequential these things are gonna be. Yes. You know, if you're a ceo, the inconsequential [00:37:00] things to you are gonna be highly consequential. To whoever your team is. Yeah. Uh, if you are a line manager, you know, working with a, you know, QA engineering team, the inconsequential things to you may be, you know, fairly inconsequential to the business.

Uh, and may just extend the timeline a little bit. You know, maybe something takes an extra day to release, not necessarily something you wanna optimize for, but again, if you're resulting in having more leaders on your team or you know, people who are capable of taking on. Uh, additional tasks that they weren't comfortable taking on before.

That's probably a trade off that is worth evaluating.

Aaron Rackley: Yeah. So obviously we've just, you've just gone through a, a great matrix now, I just wanna say, I think this is the first actual podcast where I've had about four or five different. Uh, matrixes, um, racy, you know, you've got yeah. All of these different frameworks, um, for essentially talking about one subject.

And [00:38:00] for me, that just str about, that just shows you how in depth you can get into basically any, um, subject matter, right? There are tools and tricks for everything. And, um, one aspect of why I'm doing this podcast and. One reason, I just wanna get loads of people to come on and talk about different subject matters.

And the same subject matter is for that reason, right? It's that we can read blogs over and over again and, but I think having real conversations with people that are actually doing this work, um, is a hundred percent doable. Um, so I, one more I can, I'm being conscious of the time and so I think if we do one more question, um, and then we'll go on to.

A little thing I like to ask everyone, which I'll get to in a minute. But let's have one final question about, um, the racy stuff. So we're talking about, um, consent informed and your matrixes, and do you think you could go into a little bit more about, um,[00:39:00]

knowing when to knowing. When I should be using one over the other. Uh, does that make sense? I'm trying to, yeah.

Spencer Norman: Yeah. I think, let me try to rephrase what I'm hearing you ask, but we talked a little bit about, let's say, an inconsequential decision. Yeah. That is irreversible. You may still wanna take a consulting role in that and use it as a, as a coaching tool, whereas a inconsequential decision that is reversible, maybe you just want somebody to go do it and let you know when it's done.

And I think of kind of this, this gradient or this spectrum between do you wanna be consulted on a particular decision or particular thing that you're delegating, or do you just wanna be informed as having a few different elements to it? Uh, and you know, being consulted is not a free thing that you can just do.

You know, you don't wanna be consulted on everything because. Asking somebody to consult with you before they make a decision, before they make a choice is [00:40:00] gonna slow it down. Right? Yeah. It's a blocking mechanism, uh mm-hmm. And, and I think it, it puts you in more of a mentoring role. You know, you are teaching somebody, you are, you know, maybe taking more of a, a lecturing or or teaching style approach.

Um, and it's also happening before the decision is happening. So, you know, I think of this as the slow approach. Now, there's nothing wrong with that, and if it's a really irreversible decision or something that's higher consequence, you may still want to take that, uh, approach. Being, you know, or, or allowing somebody just to inform you once the decision has been made.

On the other hand, is, is very fast. You know, it's something where you're not informed until after the decision. And I think of this as unblocking, right? So you are expre expressly letting somebody else take the reins there and you don't need to know until it's done. Uh, this I think, puts you more in a coaching posture and I think of that kinda coaching versus mentoring.

Mentoring, your're, kind of telling somebody, here's how [00:41:00] I would do it. Coaching you are observing it, you're watching how it happens, and then. You're helping somebody process the result. How did that go? What would you do differently next time? You know, what skills do you need to build? Where can we work together so that you feel more prepared for that?

But it's happening kind of outside of the context of that particular decision. It's more helping them prepare and and grow their skills. So that's how I think about kind of, you know, do you wanna be informed or do you wanna be consulted? It's how fast does this need to happen? Can you unblock somebody?

Can you take more of that, you know, co coaching approach here? Uh, and I think there's benefits to that, even if it doesn't necessarily result in the choice that you would've made. Whereas, you know, taking a consultant role, you're really kind of injecting yourself in into that process and gonna slow it down, but it may result in a decision that you are personally more comfortable with.

Aaron Rackley: Yeah, I think what's, um, very interesting from that [00:42:00] is something I've never really thought of. Um, In my experience in delegation is, like you said, there is the difference in time and cost of whether that decision becomes you being a mentor or a, a coach or consultant. Right. I think that's, that's very interesting.

There's something that I'm definitely gonna have to think about, um, moving forward cuz uh, like you say, they both, they all come with their own times, caveats and extra work or, you know, and on them as well, right. Um, yeah. Awesome. Now, I know we've, you could probably talk about delegation forever, and I'm, and I hopefully will probably get you back another time to continue the conversation.

Um, but I'm just being conscious of the time. So before I ask you to, um, Spread the word of where you live online. Um, I have one question I like to ask everyone, and that is if you could recommend to the [00:43:00] audience one book to read. Now, it doesn't have to be tech-based, it can just be, you know, if you just love Harry Potter, right?

Um, just name one book that you think everyone should read. And essentially I'm gonna create a. A bit on the website of just like books that I think every everyone should read. So yeah. What do you, what have you got?

Spencer Norman: The one that stands out to me immediately, and this has helped me both personally and and professionally, is a book called Nonviolent Communication.

Okay, interesting. Uh, I think it's by Rosenberg. I think it's Marshall Rosenberg. Uh, but the book really outlines how to have. Conversations about important topics in a way that kind of avoids putting people on the defensive and, you know, it, it gets into feelings. It gets into talking about, uh, you know, how something makes you feel and you know how you feel about a particular thing.

Um, and the, the title, you know, for me, I looked at the title and I was like, [00:44:00] oh, do I wanna read a book about nonviolent communication? But it was an incredibly, incredibly useful tool. Uh, my old manager, Sarah Hicks, uh, put me onto it. She told me that it was her favorite business book she'd ever read. And I was like, well, all right, I'm gonna read that.

And it's been probably the book that I recommended the most to people who want to be in management roles, but, you know, really any kind of leadership role. Uh, but again, it's also helped me in, in personal relationships as well. So highly recommend nonviolent communication.

Aaron Rackley: Brilliant. I'll add that to the shopping basket right now, cuz that definitely sounds like a book I need to read.

And I've just checked. That's Marshall b Rosenberg. Yeah. Cool. Okay, so next question. Where can everyone find you online? Go for

Spencer Norman: it. Yeah, so I am still on the Bird app. Uh, I think Spencer Norman is my handle on the Bird app. I'm also on LinkedIn, so feel free to, to reach [00:45:00] out to me there. Um, I'm also@spencernorman.com, so I have ambitions to write more than I actually write, but you can find, I think we all have, that you can find links to, to talks I've given, uh, on spencer norman.com along with, uh, some of the other, uh, connections to, to places like the Twitters or the, the LinkedIn.

Aaron Rackley: Brilliant. I will make sure I add them all to the show notes as well. So honestly, Spencer, thank you for coming on and talking about. Obviously delegation. Um, it's been very informative. Um, there's a lot that I've took away from this and I hope that obviously the listeners have too. So hopefully we'll have you on again at some point for either more delegation or a different topic.

But, uh, thank you for joining

Spencer Norman: me. Well, thank you so much, Aaron. It's been an absolute pleasure talking with you and I appreciate the, the conversation. Thank you.

Aaron Rackley: Hey, thank you for making [00:46:00] it all the way to to end of today's podcast. I really do hope you enjoyed today's conversation with Spencer. If you like this conversation, please can you do me a favor and just share the podcast on your social platforms and then like it on the platform.

You're listening to it right now on It really does help us get the podcast to a wider audience. And finally, if you're a tech leader, I would like to come and have a conversation with me about the subject you are passionate about. Please email me my contact@teleadershipdecoded.com and then again, thank you and I'll see you in the next episode.

Bye for now.