Engineering Management Fundamentals 101

Management is a Role Change

Jem Young

Jem Young

Engineering Management Fundamentals 101

Check out a free preview of the full Engineering Management Fundamentals 101 course

The "Management is a Role Change" Lesson is part of the full, Engineering Management Fundamentals 101 course featured in this preview video. Here's what you'd learn in this lesson:

Jem discusses the role change that occurs when transitioning from a software engineer to an engineering manager. He emphasizes that engineering management is not a promotion, but rather a different role within the team. The lesson also explores various aspects of engineering management, such as compensation, hiring, expenses, and project prioritization, highlighting the importance of considering both the people and business sides of these decisions.


Transcript from the "Management is a Role Change" Lesson

>> One of the big takeaways, right? If you tune out right now and you're like, this is cool, maybe not for me. That's all right, right? I'm not offended, but I want you to take away that engineering management is a role change. Everybody says like, congratulations on your promotion, and I'm like no, it's not a promotion.

I've not been promoted to doing anything. In fact, I'm doing more and doing less at the same time in a very weird way. Engineering management is a role change. This is what we say in my company. We don't say it's a promotion, we say they shifted roles. On a team of software engineers I play a role that helps them deliver code, it helps the product get built, and deliver results for the business.

But I don't say, I'm better than my team, I'm in charge of my team, I just have a role on my team, to guide them to the right outcomes. And that's the way to think of engineering management. It's the best approach, it is a different role amongst all these other roles, it is a role that helps deliver products.

Let's do a quick, this is a group exercise, I'm gonna need your help for this one. I want you to think like a manager, because now, thinking like a manager, there's the people side of things. You have a team of people to manage. There's a business side of things, too, the business side that we just talked about in the past couple slides, but maybe you hadn't thought of it before.

So let's think about, like, what does that mean? Let's start with compensation, I'll do this first one. Compensation shows up on the people's side and you gotta pay your team, people don't work for free, even if they did, they still gotta eat. And if you manage to get people to work for free, we need to talk cuz that's probably unethical.

I don't know what's going on there, but let's have a talk about that. But with compensation, you have to pay people. On the business side, what does that mean? What is setting compensation for your team? Or even having salaries?
>> Budgeting?
>> Budgeting, yeah.
>> Probably market rate analysis to see like, am I paying people fairly, will they leave and go get more money somewhere else?

>> Yeah, equitable compensation, making sure people are happy.
>> Maybe what that compensation is, more than just money, maybe benefits, things like that.
>> Yeah, it's a great answer, more than just benefits, more than just money. There's a reason why it doesn't matter how much your management loves you, you're probably not making $10 million a year.

Maybe they would pay you if they can, but they can't, because this is a business, if we paid everybody that, we wouldn't have any money to keep the lights on. We wouldn't have any money to pay anybody else. So it's something you think about as a manager when it comes to people, or when it comes to compensation, is what is that right balance?

And there is a balance there, and you have to figure that out. Is someone gonna leave? Do they make more money? Can I pay them enough? We're gonna cover that more in 102 because it's a deeper dive, but a different perspective when it comes to getting a raise as your bonus every year.

All the factors that are in play that maybe you hadn't considered before. We're all hiring, when it comes to hiring, what do you think that shows up in people?
>> What will they add to the team?
>> Yeah, what will they add to the team?
>> Culture fit, personalities within the team?

>> Yeah, great answer, culture fit, you can't just hire anybody, being able to code is just an aspect of it. And we're gonna cover a really deep dive into hiring, as it's one of the most important things you'll do as a manager. On the business side, hiring shows up in a variety ways, but it's what products do we have to build in the future?

Does my team have the skill sets for that today? If not, you need to hire for that. What sort of growth path do we need to fill these roles that we're gonna need in the future? Are we gonna need an architect next year? Do we have that? Is that building in my team?

If not, I need to hire for that. So even hiring, which seems like a very people problem, is also a business problem as well. When it comes to expenses, now, this is a fun one. Expenses, so, Jem, I need a new laptop. How does that show up on the people side?

>> They're more productive?
>> Yeah.
>> Or less productive and that one, yeah.
>> Yeah, you have to make that call. You have to say, do you need the latest iPhone? Do you need the latest M3 laptop? Is that gonna make you more productive? I don't know, maybe, maybe not but that's a judgment call you have to make on the people side of things, is how important is it to this person within the team?

On the business side, money, do you need to spend this money?
>> If you spend this money here, is it coming from your off-site budget, is it coming from somewhere else? It's coming from somewhere, and that's a business decision as well. Does your team need this new equipment, will it move, any sort of metrics, or does it move the important things?

Project prioritization, how does that show up on the people side?
>> Do you have the skill set for the project?
>> Yeah.
>> How many people per project are on this project versus another?
>> Yeah, how many people, skill sets.
>> Does your team wanna work on this project?

>> We're laughing, but that's true, what's the interest of the people on your team, is this something they're excited about? Is this something you've talked about in a growth conversation? Saying like, hey, I'm gonna put you on this project, and you're gonna learn this, and it's something we've talked about.

I don't know, I wanna learn NoSQL databases and this is a good project to get up to speed. There's a lot that goes into project prioritization, and it's not just how many people necessarily. It's where your team is spending the time. What are they interested in? Do they have the technical competency to be good at it, or is there gonna be a learning curve, which is gonna impact other projects as well, so that's people side.

On the business side it's, is this the most important thing we need to be doing right now? What should we be focused on as the business? If we have six months of runway, is this the feature that's gonna sell enough software to keep us in our jobs? Is this gonna make the stock market happy when we launch this feature?

That's the business side. So the whole point of this exercise, and we can keep going all day. There's a lot to think about for all these little decisions that you'll make as engineering manager, and you're gonna make, in a week you're making hundreds of decisions. And you're always thinking about people, business, technology, there's a lot to keep in your head.

So hopefully by now, if you've never thought of any of these things before, you maybe have a little bit more appreciation for engineering management. And kind of what you have to think about when it comes to just the execution of building products and software engineering. So the takeaways from this section.

We learned software engineering is more than code. Code is important. You can argue, code is an artifact of the people, of the business. But it's definitely more than code. Code is important, but there's a lot more to it than that. That's a really important thing to realize as software engineers, especially as you move up.

We learned engineering management is a role change. There's a lot of roles in any business, whether you're a non-profit, an enterprise company, a startup, everybody has a different role. At a smaller company, you might wear multiple roles or have multiple roles, but engineering management is just a role change, it's not more, it's not less, it's just a different part of software engineering.

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now