in the last episode of developer t we talked about manager tooling and specifically we talked about product life cycle governance and we're not going to get into that today i don't want to do a recap because it's 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.
And 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 the show and many of the mental models, et cetera, that you hear about on the show, that's where they come from, right?
That is not some special brand of process that is coming 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.
Okay, 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, 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, uh, 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, uh, highly dependent, uh, and highly autonomous.
This is the level of needed, collaborated uh collaboration with others is this something that one person can take and go do entirely on their own or does this need to be uh does is there some collaboration required and on the vertical axis the uh the vertical line the 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 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 independent
this is work that uh is probably in its earliest phases usually that's the kind of work that would fit in this quadrant but but this is the uh the kind of work that uh you know you might be doing together on a whiteboard right or or maybe 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 or a peer.
So highly dependent and highly exploratory.
There's, you know, a lot of things to figure out, right?
This kind of work, again, is usually not well determined.
It's not like a single question that needs to be explored.
For that, what you might call 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 exploration to be done, right?
It's something that a given engineer on your team may be able to go and explore, but it doesn't really require a lot of other people, okay?
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 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, for example, a migration project might fit in this category, right?
Especially if the migration is incredibly clear.
If you've already specked out all the work you've done, probably done some prerequisite exploration kind of work, exploratory work, then the top left quadrant may be a more more likely place for, you know, follow on work to land.
Uh, because, uh, 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.
Uh, sometimes, sometimes this is an area to look if you're trying to understand what you might optimize.
Okay. Maybe there are some integrations, right?
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 it's time to integrate that.
You might hear this phrase of shift left in kind of traditional business terms, vertical integration or horizontal integration, the idea of bringing the functions closer together other.
Uh, if you've ever heard, you know, the phrase that, uh, you know, a designer who can code, this is a type of integration that would fit in this top left category.
Okay. That, that would kind of eliminate or, or move it to the right, just kind of counter to that, that phrase of shift left. Uh, but you'd be moving, uh, the, the work to be more autonomous, right?
And if, 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.
The top right quadrant is the most defined and the most autonomous.
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.
individual okay we have an illusion as managers our teams have illusions uh uh 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 uh the 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.
And there is some validity to this idea because the more autonomous your teams can work, generally speaking, the better the flow will be.
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 collaboration.
collaboration, right?
So the highly dependent work is dependent because it requires some kind of collaboration.
That's how you would 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 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 on the left side of this quadrant that could be moved to the right.
It's things that have non -value generating collaboration.
The investment that you're putting into that being on the left side is not really generating any return.
Broadly speaking, the top left square in this quadrant 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 as possible, you want it to be in the bottom left, okay?
The bottom right part of this quadrant, the individual exploratory work, can be valuable, but this is an area to watch, okay?
Why is it an area to watch?
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, right?
So just kind of 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 what exactly you're trying to explore.
So what you want to avoid is the far bottom of this quadrant.
Okay. Work that is very exploratory, right?
Is very undefined. When you start getting down there, it's one of two strategies can work.
Either move that to the left and involve more people.
All right. So now you have kind of 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.
So they can use their experience, their intuition.
It's another way of kind 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 generate value.
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 you know a lot of those kind of characteristics of the work and the interesting thing because as we mentioned before a lot of our processes are kind of optimized to show progress based on these atomic tasks that would fit in the top right quadrant we sometimes avoid actively avoid the work that lives in these other three areas.
Okay. Especially that bottom left quadrant.
And so it makes sense to evaluate, uh, you know, where should our work be in these four different modes?
Should we be doing more slow down, exploratory focus on, you know, trying to figure out a harder problem that not any one task is going to solve, or do we have plenty of work on the table?
And we need to disentangle it, right?
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.
And a lot of the work that we do in our processes tries to move it further up and to the right.
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.
And 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, right?
That is, that is one of the goals of training is to improve the autonomy of the individual engineers.
So 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 kind of 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.
And I'll be kind of play testing this particular model in the coming weeks and sharing more manager tools and frameworks with you in upcoming episodes.
We may just make this kind of a long running series and do kind of intersperse other content with these frameworks and tools as we go into the future.
Thanks so much for listening.
And until next time, enjoy your tea.
