Engineering Management Fundamentals 101

Transitioning to Management

Jem Young

Jem Young

Engineering Management Fundamentals 101

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

The "Transitioning to Management" 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 talks about the transition from developer to a manager in software engineering. He also illustrates the how the scope, deliverables and perspective varies between a manager and developer varies. Jem also emphasizes that becoming a manager is not a promotion and that it is a different role entirely, and individuals should not feel pressured to make this transition if they are not comfortable with it.


Transcript from the "Transitioning to Management" Lesson

>> In the last section we learned, maybe some epiphanies about technology and the business of IT and the business of software engineering. Let's talk about that transition to management. One of the more challenging aspects of moving from ICT to being a manager. Everybody's transition is different. There's so many varieties of scenarios that you can end up it's it's you make the transition from ICT manager.

Sometimes you transition within your own company. Sometimes it's a different company, sometimes the same company but a different area of the company, different domain. Sometimes it's a different language entirely. There's so many different variables about what that transition looks like. So we'll talk broadly about how to make that a little bit more successful.

So we're gonna start with careers. And we're talking about the motivations on why people become software engineers and why they're usually wrong, or engineering managers, and why they're wrong. And we'll talk about making the move, like actually doing the thing and towards the end we're gonna wrap up with the interview.

And I'm gonna do a live interview with Brian just so you get a taste of kind of what that looks like because again like an engineering manager interview is something you'll probably never see until you actually do it. So, it won't get all the questions, but maybe I'll give you some insights there.

So let's talk about technology career paths. In the world, there's probably 27 million software engineers. Give or take, we don't have a good number on this, but this is a pretty good estimate. In the United States, there's about 4.4 million software engineers. Have you ever think about that?

That's a lot of software engineers. That's a lot of technology. But most software engineers don't even live in the United States, something we probably don't think about too much. Cuz all we see are sites and Internet, we see the English Internet but there's an entire other Internet out there.

Within the United States, there's probably half a million, maybe 600,000 software engineering managers. The numbers on these are a little bit murky, because there's different titles. Not everybody has the title of engineering manager. Sometimes it's Team Lead could actually be the manager, sometimes director is actually manager. So, this is probably our best guess on how many engineering managers, but the fact is, there's not that many.

Like, compared to software engineer, if you wanna I don't know, career stability, resiliency, and finding a job, you're probably better off being a software engineer. There's just more roles for that than there are engineering managers. Something to think about when you think about this transition. But in software engineering, there's two career paths you can think of, and these aren't perfectly straight ladders.

They kind of veer off to the side, think of them more as stairs. But generally, there's the technical side, and that's the side most people are familiar with. You start with junior, senior, staff, principal, distinguished moving up the ladder. And these titles will vary from company to company.

But generally, you start from knowing nothing, playing around with JavaScript in your browser to I architect entire systems. And I move the needle with code that I write, or code that I instruct to write. Then there's the other side, the people side of things, where manager, maybe senior manager, director, senior director, vice president, all the way up to CTO, the chief technology officer of the company.

And these are both important ladders too. They both do something. One is not better than the other the focus is just different. But here's the thing, it doesn't matter which ladder you climb. There's truths about software engineering in general as you move up the career ladder. The first truth is the individual lines of code is less important.

The further up you go, the less the nuances of so what's the sorting function I use for this array? What framework are we using as you move up and up and up, it just becomes less important and not saying it's not important don't don't let me take that away from you.

But the truth is if you're a principal software engineer or your CTO they don't care about what stack you're using necessarily, unless there's an actual material impact. They don't care about which database you're using, unless there's a material impact to the company. And it's a very different perspective on software engineering.

It's one of those things that's really hard to understand. And you don't appreciate it until you start moving up and up and up. And you say, you know what? People arguing over which font to use in VS Code. I'm so much more productive in dark mode than light mode.

It's just so unimportant in the grand scheme of how software gets built. And I'm not knocking any of you. If you wanna have those arguments, that's totally fine. I'm just saying the truth of what actually happens when you move up. Question?
>> Are these distinct ladders or is the people path a branch of the engineering ladder are realistic that a person could land a first position in management?

>> Great question, they are. I wouldn't say they're actually distinct. This is more of a visual picture. A lot of people go back and forth. They go from senior to manager, I've seen people go from VP back down to senior engineer A lot of people jump back and forth, it's actually probably some of the best software engineers that I know were engineering managers at some point, and they're just phenomenal to work with.

I don't have to pull teeth on like OKRs and KPIs and project management, they just know how to do it, which is the best way to become a well-rounded software engineer. But really, I think the further up you go, they come a little more distinct. But generally, these are just bulk batches of software engineer, this is how things happen.

You couldn't have, again, we'll go back to Windows, you couldn't build Windows without the people side of things managing that. But you can also couldn't build it without people writing code. So they're both equally important, but you're free to go back and forth. Again, I said in the beginning of course, I don't recommend people moving to management before making senior software engineer at least three to five years experience minimum.

The fact is you will have to talk about technology. You'll have to learn about it. If you don't understand what people are saying, because you don't haven't done it yourself, you're gonna have a much harder time than someone who's actually moved up the ladder on this technical side and then jumped over the people side.

You can do it differently people do just fine perspective from making it easier on yourself. And then the truth of both of these letters is business becomes more important. How things are actually functioning, the roles of everybody else who isn't writing code becomes a lot more important. Why we're writing the code, how we're getting paid, who's double checking that?

Are we reporting to investors? That becomes a lot more important. You're focused on, hey, we got to raise the next round of money. Are we delivering these features? Things that as a software engineer, you probably don't think about as much. But as you move up, it doesn't matter if it's people or technical side, it becomes a lot more about the business.

Your impact is bigger. The ladder is a good analogy here. Because as you move up, what happens when you move up? It's not a trick question. If I'm on a ladder and I stand up higher, what changes?
>> The risk of falling.
>> [LAUGH]
>> Let's see more.

>> Yes, the risk of falling is true. We talked about that with availability of roles. If you lose your job as VP, it's there's not that many VP of engineering roles in the world. So the risk of falling is a lot higher and you fall a lot harder for some junior engineer and I fall.

Go find another job. I'm a CTO of a company. How many of those are there in America? Not that many. So the risk of falling is true. But the your perspective changes, you're up higher. The things like, the blade of grass that you may have focused on as a software engineer and argued over the colors that a green said it's kind of a blue green and you know the the nuances.

You just don't anymore because you can't even see it that low you move further away from the code and your perspective changes. You see a lot higher like this tree that I thought was the world is actually part of a forest and that little speck in the distance.

That's actually a big mountain that people don't even think about when you're down low. So your perspective changes. But with your perspective, your impact becomes broader as well. Knowing, hey, you know what? If we did switch this piece of technology because this team's using it, but they don't even know that each team is using it, but I can see that because I'm up higher.

How about we just create a central team that figures out how to make this more effective for everybody? We make this a default technology solution for the entire organization. And that's a bigger impact you could have, but it's one of those you can only get with the higher perspective.

You become more big picture when it comes to technical understanding. You will not be as good as code. The further up you go, you probably won't be as technical about the individual piece of the code. I know I keep hitting this part, but it's something really important when you think about transitioning to management.

Even as you move up, you have to understand how systems work. It doesn't matter which ladder, you have to understand more and more and more how the parts come together. If you wanna use a car analogy, as a software engineer, you probably build, I don't know, a transmission maybe.

Actually now you probably won't get that far. You probably own a couple bolts on the engine. And as a say, I don't know, VP of engineering, you have to understand how cars work. How engines work, the chemistry of that, the combustion. And the same for, say, a principal engineer.

You have to have that same understanding. And that's something that it doesn't matter which ladder you move up. You have to be able to have this big picture of technical understandings, how things work. And we talked about this. The further up you go, the fewer roles there are, and that's just the God's honest truth.

There just aren't as many engineering manager roles in the world, and there's even less for directors, there's even less for VPs and CTOs. So again, I'd say senior is actually a good level to land at. If you say like, I just wanna make my career in software engineering and I wanna just code for the rest of my life, senior staff is a perfectly good place to be.

Because it's not a promotion. I keep saying that it doesn't matter what the world says, software engineering or engineering management is not a promotion. It is a different role entirely. So, don't feel pressured that you have to move up the ladder. And I'll say that again, do not feel pressured that you have to move up the ladder.

It is not a sign of your success or failure if you just stay Senior Software Engineer for the rest of your life or staff. Some of the worst engineering managers I've met and seen and heard have heard of there are people that have been forced into the role because they felt, well, this is the next thing obviously.

I have to move up the ladder. Otherwise, what does the world think of me? I've been this company 10 years and I'm still a software engineer. Ignore that, that's not true at all. It's a different role. And if you do it for those motivations, you will not have a good time.

I like to write code. Cool, I don't recommend being a manager then. Like I said, this is practical engineering management. This is just the truth of the situations.
>> Some companies have a team lead rather than engineering manager. So that could be a potential as well.
>> Yeah, and we have a section on I have a section on building up skills and some of that is team lead role.

You can get the engineering manager experience at least some of it without having to make the full title switch. The main differences people side and not a little bit. But yeah, I just wanna emphasize that you are not obligated to move up to engineer management is not a promotion.

It's not something you have to do. So if you're not comfortable doing it, that's totally fine.

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