In the last episode of Developer Tea, we talked about manager tooling, and specifically we talked about product lifecycle governance. We're not going to get into that today. I don't want to do a recap because it's probably an easier thing for you to just go listen to that episode. I encourage you to go listen to it because these manager tools that we're talking about, these are kind of fundamental ideas. There's not really anything proprietary in what we're talking about, nothing incredibly novel. Maybe I'm shooting myself in the foot here, but I think these principles are not necessarily new. I didn't come up with them. I didn't sit down and try to... distill all of my personal knowledge. This is as a result of both my own experience, but also many years of study by other people, books that I've read, conversations that I've had with other managers. That's where the tooling and frameworks that you're going to hear about on this show and many of the mental models, et cetera, that you hear about on this show, that's where they come from. It's not some special brand of process that is coming. It's not something from Jonathan Cottrell's brain. Instead, I want to share with you this common wisdom and longstanding wisdom. So in the last episode, we did talk about product lifecycle governance. In this episode, I want to give you another tool. And this tool is very simple to think about. It's a quadrant. It wouldn't be a good manager tool unless we had a quadrant, some kind of way of visualizing. You know, these, this idea and this quadrant describes different working modes that your team might find itself in. And more specifically, even an individual task may fit in. So to visualize this quadrant, I want you to think about the two axes. Of course, you know, a quadrant is essentially shaped like a plus sign. So the X axis and the Y axis on the X axis on the left side. Of that plus sign, that, that horizontal line, the far left side would be highly dependent. And then on the far right side of that horizontal line would be highly autonomous. Okay. So highly dependent and highly autonomous. This is the level of needed collaboration with others. Is this something that one person can take and go? Do entirely on their own? Or does this need to be, does, is there some collaboration required? And on the vertical axis, the, the vertical line, the Y axis on the very bottom, you have highly exploratory. And on the very top, you have highly defined. All right. On the bottom, highly exploratory on the top, highly defined. So what? The way you can kind of see is in the bottom left square of this quadrant, this bottom left portion is highly exploratory. Right. And highly dependent. This is work that is probably in its earliest phases. Usually that's the kind of work that would fit in this quadrant. But, but this is the, the kind of work that, you know, you might be doing together on a whiteboard, right? Or, or maybe it reflects. It requires a lot of buy-in across multiple departments or it's multifunctional in some way. All right. This is work that can't be done by one person, especially if it's very far, very far to the left, right? If it's all the way to the left on this X axis, then it's going to require a lot of input from multiple people, maybe multiple departments, multiple leaders. Maybe there's some kind of vertical dependency, right? It needs to be approved. You know, higher than just directly through the manager or through a peer. So highly dependent and highly exploratory. There's, there's, you know, a lot of things to figure out, right? This, this kind of work again is, is usually not well-determined. It's not like a single question that needs to be explored. For that, what you might call in, in you know, some, some work processes might call a spike. Right. A spike is usually on the bottom right quadrant. All right. The bottom right quadrant is autonomous, but there's still explore. There's still exploration to be done, right? It's, it's something that a given engineer on your team may be able to go and explore. But, you know, it doesn't really require a lot of other people. Okay. Now, of course, this is a gradient. That's the whole idea of the quadrant. It's not necessarily. A category as much as it is a gradient from extremely dependent on the far left to absolutely down to one person on the far right. And of course, we've only been talking about highly exploratory work. If, if we go to the top left, top right quadrants here, the top left quadrant is high dependency, but high definition, high dependency, but high definition. Something like. Like, for example, a migration project might fit in this category. Right. Especially if the migration is incredibly clear. If you've already spec'd out all of the work you've done, probably done some prerequisite exploration kind of work, exploratory work, then the top left quadrant may be a more likely place for, you know, follow on work to land. Because it's kind of diffusing that work across many different teams. This might be an adoption of a new tool might fit into this category. Right. It's highly defined, but it does depend on a lot of people. Sometimes, sometimes this is an area to look if you're trying to understand what you might optimize. Okay. Maybe there are some integrations. All right. And in this case, I don't mean like integrations with external tooling. I mean, integrating the work that is currently being done by three different people. Perhaps. Perhaps. Perhaps. Perhaps. Perhaps.ijijijijijijijijij is kind of counter to that phrase of shift left, but you'd be moving the work to be more autonomous, right? If you're integrating the work so that fewer people are required to accomplish something, then you're moving it up and to the right. Okay, so the top right quadrant is the most defined and the most autonomous, right? This means this is a singular kind of atomic task usually that would fit in this category or a user story, something that is on a JIRA board that's assigned to an individual, okay? We have an illusion as managers, our teams have illusions based on the idea that all of our work, all of our actionable work is in this top right quadrant. This is simply not true. And it's important for us to understand that so many of the common development kind of frameworks, processes, whatever you want to call these things, very popular frameworks, they're going to focus and optimize for work that fits in that top right quadrant and for moving work from those other three areas to the top right quadrant, right? And there is some validity to this idea because the more your teams can work, generally speaking, the better the flow will be, right? The higher the number of dependencies there are, the easier work gets caught up in those dependencies, it becomes inefficient. So moving things to be less dependent and more autonomous is generally a good thing. But there is also some value that can't be ignored in the exploration and in the, in the collaboration, right? So the highly dependent work is dependent because it requires some kind of collaboration. That's how you would, you know, kind of determine, is this dependent because it needs some kind of creative collaboration or is it dependent simply because that's how the lines are drawn, right? So if you're trying to figure out, okay, how do we, how do we optimize our team? If we're doing a bunch of back and forth, we're just getting rubber stamp approvals, that stuff that is over on the left side of the team, that stuff that is over on the left side of the team, that could be moved to the right. It's things that have non-value generating collaboration, right? The, the investment that you're putting into that being on the left side is, is not really generating any return. Okay. So broadly speaking, the top left kind of square in this quadrant is the lowest value production, generally speaking, all right? The top left part of this quadrant is going to be the lowest value production. That's because when you have dependencies that are spread across a bunch of people, but are not really requiring any kind of creative thinking, it just so happens to be spread across many people, or it has high levels of dependency, you know, chains or graphs or whatever you want to call that, that is producing little value, right? So if you're going to have dependency, you want that to be as much you want that to be as much as possible, you want that to be as much as possible, you want that to be possible, you want it to be in the bottom left. The bottom right part of this quadrant, the individual exploratory work, can be valuable, but this is an area to watch. Why is it an area to watch? Sometimes having individuals who are in an exploration pathway can be a liability. This isn't because the individuals are a liability, but because exploration on its own is largely unguided. Just by nature of this work, a spike, you could end up going too far down one pathway if you aren't guided or perhaps if there's not good boundaries on what exactly you're trying to explore. What you want to avoid is the far bottom of this quadrant. Work that is very exploratory, is very undefined. When you start getting down there, one of two strategies can work. Either move that to the left and involve more people. Now you have this natural guiding that happens by way of it being exposed to multiple people in a group. Another way to do this in a similar fashion is to ensure that the person who is executing on that has significant experience in that area. They can use their experience, their intuition. It's another way of saying, okay, I'm going to check in with some experience, whether that experience is in another person or in the individual that is performing that exploratory task. Broadly speaking, if there is a way to get the task to the top right, that's going to be generally the preferred quadrant to live in. This is the lowest risk work. Now it's important to recognize that just because work lives in the top right quadrant doesn't necessarily mean it will live in the top right quadrant. It's going to be the lowest risk work that lives in the top right quadrant. It may be the case that the most important thing your team can do is in that bottom left quadrant. It's going to be slow, exploratory, highly dependent, a lot of those characteristics of the work. The interesting thing, because as we mentioned before, a lot of our processes are optimized to show progress based on these atomic tasks that would fit in the top right quadrant. We sometimes actively avoid the work that lives in these other three areas, especially that bottom left quadrant. It makes sense to evaluate where should our work be in these four different modes? Should we be doing more slow down, exploratory, focus on trying to figure out a harder problem that not anyone can solve? Or do we have plenty of work on the table and we need to disentangle it? We need to make sure it has all of the necessary criteria so it can be autonomously executed. Maybe we're just lacking in the ability for each of our engineers to take a single task and carry it forward. That would be that top right quadrant. A lot of the work that we do in our processes tries to move it further up into the right quadrant. Think about what refinement does when you add acceptance criteria to a user story. You probably know this language. If you don't, it's easily Google-able. If you're adding acceptance criteria, then you are creating more definition. You're adding definition to the thing that should be done. Simultaneously, because there's more information there, you're also making it to where it's possible for someone to autonomously pick it up. Similarly, when we invest in training for our ICs, we are improving their autonomy. That is one of the goals of training, is to improve the autonomy of the individual engineers. This kind of framework, thinking about the different modalities or modes of work that your team is doing, can help inform other interventions that you might bring to the table as a manager. Thanks so much for listening to today's episode of Developer Tea. Hopefully, this is a useful manager tool. It's one that I'm going to be practicing and playing with as I enter a new role. I start a new role next week, and I'm excited to learn more about what's going on in my new role. I'll be playtesting this particular model in the coming weeks and sharing more manager tools and frameworks with you in an upcoming video. Thanks so much for listening. Until next time, enjoy your tea.