Many of you probably know that my day job for many years now across multiple companies has been to operate primarily as an engineering manager.
manager. Now, that looks different from one company to the next.
It looks different depending on the kinds of teams that you might be managing.
What kinds of reports do you have?
Are you in a startup?
Are you in a larger organization?
I've worked in multiple organizations, some a little bit bigger than others.
I've never been in a mega large organization.
Take what I have with a grain of salt if you're in one of those kinds of situations.
But I do think that what we're going to share today is still applicable to you as well.
One of the things I've noticed since I kind of went down the road of becoming an engineering manager is that there seems to be a lack of engineering management specific content.
There are some very good books out there.
There are some good other podcasts that focus on this topic, but there is still a lack of information and guidance out there for other engineering managers.
What I want to do in this episode and in a series of episodes after this one, I want want to talk about specific tools or tactics, you know, things that you might take into the workplace as an engineering manager.
Now, before you leave, if you're an engineer and not an engineering manager, I do think that this episode and the following episodes will be relevant to you still, because one, you might one day choose to go down the management track.
This will help you get a taste of some of the things that you might care about or might want to do as a manager.
And, you know, either make that decision, maybe it will help you make the decision one way or the other.
And then secondly, because the things that we're going to talk about are not necessarily only, you know, something that engineering managers can do.
A lot of times in organizations, especially smaller organizations, lead engineers tend to take on some of these management duties, right?
And, and also staff engineers, you know, project leads, whatever those roles are, a lot of the time, there is some crossover between the more formalized kind of engineering manager role, and those leadership engineering roles.
So I don't think that this this episode or other episodes in this series, this kind of manager tools and tips series are necessarily going to serve you wrong.
It won't be a waste of time by any means.
So I encourage you to stick around and listen to these episodes like you would any other episode of developer T in this first episode, I want to give you some language that you can use a conceptual language or a mental model, if you want to call it a mental model, it's more just a concept for you to use to understand and very likely solve a lot of problems that your team may be having.
So we'll start with a problem that you might be experiencing.
And then we can discuss some of this model, this language that may help you work through these problems. The problem you might be experiencing is you're not really sure how to order your backlog.
Maybe you're struggling to understand exactly what the next priority is.
Or maybe there is some kind of misunderstanding between you and another leader, maybe a product owner, product manager, program manager, your boss.
And it may be that you're coming from another situation where all of this was very different.
And you're trying to kind of wrap your head around how this new team does things.
So the language I want to give you to kind of understand this problem is product lifecycle governance, product lifecycle governance.
What does this mean?
Well, a lot of times we imagine that any company that we're working at is going to have the same kind of product development lifecycle, right?
A very natural assumption will be that however your last company worked is how your next company will work.
And so this information is particularly relevant for those of you who are moving into a new role.
This might be surprising if you're going from a developer role to an engineering manager role, but also for engineering managers who are moving from one company to another.
So this This concept, product lifecycle governance, is directly related to the product development lifecycle.
You've probably heard of this.
At some point, the PDLC is what it's probably quickly referred to as.
The product development lifecycle kind of walks you through the stages that work goes through, right?
If you think about how does something arrive on your engineer's plate, right?
If you're a manager, you should know or you should be able to find out how does work ultimately end up in front of my report?
Because the ideal state, everybody wants to be working on the most important thing.
There are very few people who would consciously choose to sit down and work on something that their boss or their organization doesn't want them to work on.
okay so what you're really asking when you ask this question is how do we determine what the work is and in what priority order we should work on it how do we determine what the work is and in what priority order we should work on it now there's a a lot of things that go into to that full life cycle, right?
And parts and pieces of that that are very granular in nature.
For example, whose responsibility is it to populate the backlog?
You may have an immediate answer that comes to mind, but I promise you that there are probably a hundred other companies that do it a hundred other ways.
So whose responsibility is it to populate the backlog could have multiple There could be two completely different and still effective answers to this question.
So what you're really trying to do as a manager is understand where are the decisions being made?
That's the governance part of the product lifecycle.
So if we're determining what are we going to do, should we work on tech debt or should Should we work on this new, you know, this new feature is a common conundrum that an engineering manager is faced with.
How much tech debt should we take on?
What is the governing model for how we manage tech debt, right?
That's really what the kind of thing that you're asking here.
What is the governing model for when we are choosing to adopt new work in?
in? Should we, you know, work on the new feature or should we expand the existing feature?
Who decides, right?
Again, you know, even I have to kind of push against my preconceived notions of answers to these questions.
I have ideas about what an effective kind of setup might be for this, right?
In that particular case, you know, who should decide that?
Probably somebody who has product expertise.
But that's not always going to be how your organization operates.
So what you really need to understand is where are the decisions being made?
Decisions are the kind of the fuel of governance, right?
So who is governing, who is changing the direction or moving the energy, right?
Deciding what energy goes where, who decides what the team should be working on.
You are probably part of that equation as a manager.
You are probably one of the empowered governors, okay?
So it's very important for you to understand what your power is.
What are you able to speak to?
What are you able to govern?
And what things are out of your hands?
Or should you be working with someone else to make decisions about?
Ultimately, if you don't understand this, you could end up not executing where you're supposed to, right?
You're omitting your governance, which is not good because you could end up having chaos in that particular area.
and alternatively you could end up trying to govern where you're not supposed to or where the the kind of model dictates you're not supposed to and then of course it could be that the model doesn't have good specificity and that you may need to collaborate with your peers or with your product partners or with your team to actually develop a better governance model So again, the language here is a product lifecycle governance.
What is the product lifecycle governance?
And this is through all stages.
Really, you want to understand the ideation phase of work.
Where does it originate?
Are we doing product research with our users?
You know, when we get a bug, are we evaluating the bugs so that we can bring that into our bug backlog?
You know, how do we surface tech debt?
This is one that's often totally forgotten.
You probably have tech debt that doesn't have any representation in your backlog because you don't really have any governance model for who's responsible for surfacing that tech debt in a way that can be actionable, right?
All of these aspects of governance are part of the product lifecycle governance model, and it makes sense.
It makes sense to write this down.
It makes sense to surface it and share it, and it also can evolve over time.
It makes sense to iterate on it, to retro with other engineering managers in the organization, with other leaders in the organization, to determine, is our governance model working, or is there confusion?
Is there frustration?
You know, do we have the right information at these decision points?
This is, you know, one of the main tools that you can use, especially to establish some of the other parts of your process.
If you don't have your governance model right, then a lot of your other process pieces are probably going to fall apart.
Because again, your governance model is intended to produce what outcome?
Think about it. The outcome that your governance model produces is the idea that everyone is working on the right thing at the right time.
That is the whole point of this governance model is that we are optimizing our decision making and our processes so that all of our human resources, all of our deployed engineers, all of our individual contributors are all working.
They're all focused and expending their energy towards the right things.
things towards the things that we want to spend our energy on, right?
If you don't have the governance model, then all of your other processes that are kind of sub -processes, right, they're intended to, you know, help, you know, with a smaller part of the development process, you're going to be working on the wrong things.
So it doesn't really matter how effective you are on the wrong thing, right?
So that's why the governance model is kind of the entry point to all of the other work that you'll do.
Thank you so much for listening to this episode of Developer Tea, this kind of special manager tips and tricks.
I'm not really sure what we're going to call a series.
It should show up in the title of the episode, but hopefully this was insightful for you, even if you're just starting out in your career as a manager.
Or if you're an engineer and you're curious about the idea of becoming a manager, you could even ask this question of your manager.
And it might be the first time that your manager has ever heard of this.
Then you can point them to this episode that, of course, can spark good discussion amongst your team.
Thank you so much for listening.
And until next time, enjoy your tea.
