let's say you're a new leader you are trying to learn how to manage your overwhelming schedule or your long list of responsibilities and you've probably been reading about something like the eisenhower matrix if you haven't heard of the eisenhower matrix the basic breakdown is a quadrant four-part graph and on the x-axis we've talked about this on the show before on the x-axis is urgency and on the y-axis is importance so you have x-axis would be not urgent or urgent and then not important or important and the idea is that based on where you put your focus on the x-axis you're going to be able to do a lot of things and you're going to place the different things that you have on your list you might take different actions for those things so for the things that are urgent and important do them now for the things that are urgent but not important you may delegate those for the things that are important but not urgent plan for those and finally for the things that are not important and not urgent delay or offload don't do them cancel them and this gives you this bucket we want to focus in today on the delegation bucket the idea that you would basically transfer the ownership we're going to use very specific words today the ownership of those particular tasks or responsibilities to another person or to a team or to a service so as you're looking at this bucket you're going to want to focus in today on the delegation bucket as you begin to grow in your career what may have once been urgent and important may move down to that urgent but not important square because it is dependent on your context dependent on your role your responsibilities your goals your values all of these things can play into your prioritization scheme but here's where we get something wrong and i want to zoom in again on this delegation concept in our heads what we imagine that we're doing it was we're taking those items off of our matrix and we're putting them on to another person's matrix presumably we're hoping to put them on to somebody's important or important and urgent box right maybe they are urgent but not important for that person and they can find another way to delegate that but in any case we're imagining that we are just lifting and shifting those things to our next person and we're going to do that in a different way so we're going to do that directly to them but what tends to happen in reality is very different we tend to only put parts and pieces of those things onto other people's shoulders we're going to talk about two specific ways this can go wrong in today's episode we're going to define some terms here that we'll use in sort of a framework we're going to use this ownership concept to mean a full ownership of whatever that item is and the two sub parts of that ownership the two things that are kind of required to make up ownership is responsibility and agency responsibility and agency responsibility is you are accountable for that thing being done you care about the outcome you have some stake in the outcome and the agency is you have the you know reasonable ability to operate within the space within the space and you're going to take that responsibility and you're going to take that the solution space and make decisions that have some level of consequence. Those decisions are not being made for you if you have agency. Usually agency comes along with some kind of empowerment to make the agency actually have weight. Specifically, I want you to remember the four T's for the sake of this episode and maybe going forward a good framework for you to think about this. Agency tends to be proven through the four T's. The four T's are training, time, tools, and talent. Training, time, tools, and talent. These are the resources that you would need to be able to operate with to have agency. Implicitly, all of these things can translate to some kind of monetary value in one way or another, but those four things are critical. If they are being provided to you, then you have some kind of value. If they are being provided to you, then you have some level of agency. If you have full freedom across all four of those things, then you have a very high level of agency. Okay, so with this framework in mind, you have the idea of ownership breaking down to both responsibility and agency. You can kind of see where this is going. If you delegate only agency to someone, in other words, if you're only delegating the ability to make a decision about an outcome that they don't have a stake in, there's no responsibility attached to that, then it's very unlikely that this person will understand any kind of motivation for doing that thing. What will probably happen is if they do that thing at all, they're going to do it through some kind of social obligation to you. This is something that sounds like responsibility. It may look like responsibility. They are being held accountable to you for you asking them to do the thing, so it may look like, and feel like responsibility, but in fact, it's not actually true full ownership. You're still owning the thing that you care about the real outcome for. If they could accomplish the social contract that you've requested for them to accomplish without doing the thing, without spending their time, without spending their training or their tools or their talent, if they could do that thing without using that agency, they're likely to fulfill that requirement without actually caring about the outcome. That's not because anybody is nefarious in that particular situation, but because the thing that they own is not the thing that you care about. They have only been given an agency without having a stake in the actual outcome. This tends to happen a lot in companies that produce some kind of goals at a very high level, but don't produce goals that are more atomic or at a low level, more practical, specific goals for the teams that are executing against the higher level things. Because the teams at the lower level can't necessarily associate the work that they're doing to those higher level outcomes very easily, they have to substitute a different responsibility. In other words, they're doing the thing because fill in the blank, their boss told them to, because they have some obligation to another team. There's a social contract rather than a full ownership. There's a social contract rather than a full ownership. There's a social contract rather than a full ownership. And this creates a breakdown because the outcomes that you care about at the high level, they ultimately are going to be accomplished by the work that's done at the lowest level. So those OKRs that you have at the team or at the company level, they are essentially meaningless in terms of ownership. Your teams are not going to feel any ownership over those OKRs because they can't see how that works. How those outcomes connect to the work that they're doing. At least that's true in sufficiently large organizations. So the work to be done there to fix that is to try to encourage the full ownership transfer. So you're not just giving agency to people to operate, but you're also saying, hey, your success is dependent on these outcomes. It's not a social contract between you and your boss. It's a social contract between you and your boss. It's a social contract between you and your boss. It's not an expectation that you just make somebody happy. It is based on this thing that you now are responsible for. So you're pairing the responsibility with the agency. We're going to take a quick sponsor break and then we're going to come back and talk about the flip side. What happens when you're asking somebody to own something, but you're not giving them the agency to operate? Today's episode is sponsored by Jam.dev. Jam.dev is developer-friendly bug reports in one click. You may have heard it before. It is used by more than 75,000 people. It's a free tool that saves software engineers a ton of time and frustration. You've probably received bug reports that are really frustrating. They mean well, probably, but unfortunately, they're not going to help you. So if you're looking for a way to get rid of them, you're going to have to do it. There's no console logs, no user ID attached. There's no replication specificity. They may say that they closed the window, but you actually care about did they use the X button or was it just a tab? Did they quit the browser? This kind of context is important for you to be able to solve the bug, but if you don't have it, it ends up going back and forth over weeks in the ticket comments. Maybe it gets lost or drops through the cracks, or maybe it's just a bug that you're the bug goes away and you have no idea how it got resolved in the first place. And then it shows back up a few weeks later because actually turns out it wasn't resolved at all. And jam.dev helps solve this problem. Jam.dev provides the correct guardrails to make sure your teammates are making the perfect bug report because they literally can't do it wrong. It automatically includes a video of the bug, console logs, network requests, all the information you need to do to debunk, uh, even things like internet speed, um, and even automatically lists out the steps needed to reproduce the bug. And it's so easy to get your teammates to use because it's just a Chrome extension. When they see a bug, they click a button and right away it creates a ticket in your issue tracker. So it saves time for them. And it saves you a lot of hopping on calls and meetings to debug using jam. You can go from having a bug report that doesn't have any information that's relevant to having something that's so descriptive. You could make an automated test just by copying the attributes from the report. And then you can go from having a bug report that doesn't have any information that's relevant to having something that's relevant to having something that's relevant to having a bug report. Head over to jam.dev to get started. It's totally free today. Uh, if you're an engineer, you'd rather spend your time writing code than responding to comments in your issue tracker. Send your team to jam.dev. That's jam, J-A-M dot D-E-V. Thanks again to jam.dev for sponsoring today's episode. In today's episode, we've been talking about ownership and delegation. We're using these terms with really specific definitions, uh, for the sake of the episode. There may be other words that you want to use in place of this, but really ownership is a combination of caring about the outcome and having the agency to actually do something about it. So we're saying ownership is a combination of responsibility and agency or power. So what happens if you, uh, try to delegate, um, but you don't provide the right amount of money, agency, what this typically looks like is a well-meaning, perhaps well-intentioned push from a leader, uh, of some kind. Usually, uh, this is, this is the way it goes. Uh, a leader is saying, well, you know, you can own the solution. We're really relying on you to do this. This is part and parcel of your job. We, we really want people at your level owning these kinds of problems, right? So this is the intention. And the problem on the backside of that, that sounds a lot like ownership, right? But it's missing the critical piece, which is how do we actually get this done? If agency is not provided, if that, let's say you're an engineering manager and you're being asked to do something, or you're an engineer and you're being asked to own a particular problem. If you're not able to then say, I need X, I need to, you know, uh, I need a new, I need people. I need time to get that done. If you're unable to say the thing that you're needing in order to accomplish the thing that you are now responsible for, then you lose the full ownership. All that's really happening is that you're now stressed out about trying to do more with less. The resources you have available to you, if you're in this position are now less powerful. Than they were before, because your responsibility list has grown, but your options list or your capabilities list has stayed the same. If you don't have the training, the time, the talent, or the tools to do the thing that you're being asked to do, or you're being asked to do more with the same of those four T's of same resources that you have before, that really is not providing ownership to that person. It's just, it's just increasing their stress level. So if you're in a position of power and you're asking for people to own the solution on something, my challenge to you is anytime you're asking someone to do something or asking them, what can you do? You should always pair this with, what do you need? What can you do given some resources? If you don't provide the resource, uh, uh, you know, follow up for this, then you're basically relying on that person to then ask for the resources, which may be a reasonable contract that you have with them. But recognize that this is a position of power, uh, usually that you're sitting in and someone asking you for something after you've asked them for something can be a little bit uncomfortable. If you're on the other side of this, if you are on the receiving end of somebody asking you to do something, then it's not going to be a good idea. You're going to have to be a little bit more comfortable. You're going to have to be a little bit more comfortable. You're going to have to be a little It is your responsibility to make it clear that in order to do whatever it is they're asking you to do, you may need, you may need some agency. All of this of course assumes that your goal is indeed full ownership. In most cases, full ownership is the most effective strategy for delegation. It's not always the case, but in the vast majority of cases for people who are listening to this show in the careers that you're in, full ownership is going to be a much more effective route than partial ownership. Thanks so much for listening to today's episode. Thank you again to jam.dev for sponsoring today's episode. If you want, uh, your bug reports to get much better than they are today, head over to jam.dev to get started totally free today. That's jam.dev. This episode and every other episode of developer T can be found at developer t.com. I recently pushed a bug fix to this. Uh, it's a longstanding bug. Um, and I'm going to be doing a lot of work on that. So if you to the developer T website, uh, you can now access all of those old episodes that had kind of disappeared or they were actually returning a four Oh four for quite a while. Uh, that is now fixed. So you should be able to listen to the full back catalog of developer T now. Thanks so much for listening. If you enjoyed this episode, please consider joining the developer T discord community, head over to developer.com slash discord. Thanks for listening. And until next time, enjoy your tea. Okay.