My previous employer basically had no path. All engineers are ICs (some are tech leads or team leads), but there’s no levelling there, so you can either move sideways (to another team or department) or hope a tech lead role opens up, or move to management. I was the tech lead for my team in my time zone, so there was no real opportunity for others in my team to level up in any official way. This frustrated a few of my team members quite a bit.
My current employer has a great career path for ICs which is well supported at a company level and managers are strongly encouraged to work with their reports to make sure they’re getting what they want from their career and promotion ambitions.
Now I’m at the Staff level (and as a tech lead) I’ve started reading The Staff Engineer’s Path. It’s a great read so far and I can really relate to everything it talks about.
I’m quite skeptical of a book that starts the blurb with:
For years, companies have rewarded their most effective engineers with management positions
The first company that I’m aware of that stopped doing this was HP in the ‘80s. They had explicit management vs engineering paths and normalised the idea that an engineer might be at a higher level than the manager that they reported to (managing a small team may not require a senior manager, but the work that they’re doing may require some of the most senior engineers in the company). This has been something covered in a lot of different management theory books that I’ve read and seems to be universally regarded as a good idea (I’ve never read anything defending the management-is-the-only-promotion-path idea, the closest is to recognise that it’s good for managers of engineers to be able to understand explanations that engineers give and so they should have some relevant technical background).
At Microsoft, I think the two-track approach was introduced in the ’90s, possibly earlier. The IC track ends with Partner, Distinguished Engineer, and Technical Fellow. A TF is the same level as a Corporate Vice President and is invited to the senior leadership team retreats and things but does not (normally) have any people-management responsibilities. As I understand it, the only level above CVP is Executive Vice President (and CEO) and those are somewhat intrinsically management roles.
It definitely depends on the company, and the size of the company. All the companies you name are behemoths, and I’m not surprised they all have a good two-track system.
My previous employer was a startup that grew quickly and took a very long time to even have formal managers. 10 years later they still don’t really have any real track for ICs, as I mentioned, and from what I’ve seen this is relatively common amongst tech companies that are still relatively immature and don’t take an early decision to create a good career path.
I understand your skepticism, but as usual it’s all about context and experience. My current role is the first job I’ve had in my 20 years of working that actually has a good career path.
I understand your skepticism, but as usual it’s all about context and experience. My current role is the first job I’ve had in my 20 years of working that actually has a good career path.
I’m more skeptical of the book than the idea but my experience is somewhat tarnished by having recently had to do a load of manager training that got very excited about ideas that I’d read in books published in the ’70s and ’80s as if they were previously unheard of.
It’s hard for very small companies to have this kind of separation, but it’s something that you can introduce as soon as you have a management track and it’s something that pretty much everything that I’ve ever read about managing engineers tells you to do. If a company doesn’t do it then I have to wonder what they’re doing in terms of expectations for managers.
I was at HPE within the past decade. My first manager was an individual contributor who was promoted into management so that the team did not collapse, and incidentally they were also the person who built the product initially. My second manager was an external hire who did not know how to code. It looks to me like the book has a reasonable grasp of the situation.
the idea that an engineer might be at a higher level than the manager that they reported to
What does “level” mean in practise, at this point? Is it just about compensation, parking spaces, corner offices and generous travel allowances? Or is there some sort of implicit authority that comes with a higher level? (And what then does it mean to manage someone at a higher level?)
What does “level” mean in practise, at this point? Is it just about compensation, parking spaces, corner offices and generous travel allowances? Or is there some sort of implicit authority that comes with a higher level? (And what then does it mean to manage someone at a higher level?)
Seniority along their respective tracks. This normally comes with increased compensation and so on. Authority is contextual, but someone at a higher level on the management track would be expected to be able to manager higher-stakes and larger teams than a more junior person. Similarly, someone at a higher level on the engineering track would be expected to be able to solve more difficult engineering problems (for example, design the architecture for larger systems, implement things with more constraints on resources, and so on).
Managing a senior engineer does not intrinsically require a more senior manager (often the reverse, since a more senior engineer may be more able to articulate their requirements and more able to accurately predict schedules) and that was something that their model reflected.
I see. It sounds to me like the contextuality of the levels makes it hard to compare an engineering level to a management level, aside from compensation and similar.
If your employer can pay for it, the only management training that I’ve been made to do that wasn’t either of zero or negative value (e.g. telling me to do things that were known to be bad practice in the ’80s by anyone who actually paid attention to research) was The Coaching Habit, run by Box of Crayons.
I’ve seen too many good developers end up in dead end middle management, adding fat to an org they previously contributed to.
And every time it was this. Many not a complete lack of awareness, but at least a lack of belief that their technical skills could be highly valued.
Have I left some possible money on the table by sticking to my guns and staying technical? Once or twice. But that doesn’t mean I ended up stuck forever.
Not just managers, but companies in general.
My previous employer basically had no path. All engineers are ICs (some are tech leads or team leads), but there’s no levelling there, so you can either move sideways (to another team or department) or hope a tech lead role opens up, or move to management. I was the tech lead for my team in my time zone, so there was no real opportunity for others in my team to level up in any official way. This frustrated a few of my team members quite a bit.
My current employer has a great career path for ICs which is well supported at a company level and managers are strongly encouraged to work with their reports to make sure they’re getting what they want from their career and promotion ambitions.
Now I’m at the Staff level (and as a tech lead) I’ve started reading The Staff Engineer’s Path. It’s a great read so far and I can really relate to everything it talks about.
I’m quite skeptical of a book that starts the blurb with:
The first company that I’m aware of that stopped doing this was HP in the ‘80s. They had explicit management vs engineering paths and normalised the idea that an engineer might be at a higher level than the manager that they reported to (managing a small team may not require a senior manager, but the work that they’re doing may require some of the most senior engineers in the company). This has been something covered in a lot of different management theory books that I’ve read and seems to be universally regarded as a good idea (I’ve never read anything defending the management-is-the-only-promotion-path idea, the closest is to recognise that it’s good for managers of engineers to be able to understand explanations that engineers give and so they should have some relevant technical background).
At Microsoft, I think the two-track approach was introduced in the ’90s, possibly earlier. The IC track ends with Partner, Distinguished Engineer, and Technical Fellow. A TF is the same level as a Corporate Vice President and is invited to the senior leadership team retreats and things but does not (normally) have any people-management responsibilities. As I understand it, the only level above CVP is Executive Vice President (and CEO) and those are somewhat intrinsically management roles.
It definitely depends on the company, and the size of the company. All the companies you name are behemoths, and I’m not surprised they all have a good two-track system.
My previous employer was a startup that grew quickly and took a very long time to even have formal managers. 10 years later they still don’t really have any real track for ICs, as I mentioned, and from what I’ve seen this is relatively common amongst tech companies that are still relatively immature and don’t take an early decision to create a good career path.
I understand your skepticism, but as usual it’s all about context and experience. My current role is the first job I’ve had in my 20 years of working that actually has a good career path.
I’m more skeptical of the book than the idea but my experience is somewhat tarnished by having recently had to do a load of manager training that got very excited about ideas that I’d read in books published in the ’70s and ’80s as if they were previously unheard of.
It’s hard for very small companies to have this kind of separation, but it’s something that you can introduce as soon as you have a management track and it’s something that pretty much everything that I’ve ever read about managing engineers tells you to do. If a company doesn’t do it then I have to wonder what they’re doing in terms of expectations for managers.
I was at HPE within the past decade. My first manager was an individual contributor who was promoted into management so that the team did not collapse, and incidentally they were also the person who built the product initially. My second manager was an external hire who did not know how to code. It looks to me like the book has a reasonable grasp of the situation.
What does “level” mean in practise, at this point? Is it just about compensation, parking spaces, corner offices and generous travel allowances? Or is there some sort of implicit authority that comes with a higher level? (And what then does it mean to manage someone at a higher level?)
Seniority along their respective tracks. This normally comes with increased compensation and so on. Authority is contextual, but someone at a higher level on the management track would be expected to be able to manager higher-stakes and larger teams than a more junior person. Similarly, someone at a higher level on the engineering track would be expected to be able to solve more difficult engineering problems (for example, design the architecture for larger systems, implement things with more constraints on resources, and so on).
Managing a senior engineer does not intrinsically require a more senior manager (often the reverse, since a more senior engineer may be more able to articulate their requirements and more able to accurately predict schedules) and that was something that their model reflected.
I see. It sounds to me like the contextuality of the levels makes it hard to compare an engineering level to a management level, aside from compensation and similar.
Right in time for me to add “Be a better manager” to my 2023 goals at work. Definitely food for thought and some decent resources here.
If your employer can pay for it, the only management training that I’ve been made to do that wasn’t either of zero or negative value (e.g. telling me to do things that were known to be bad practice in the ’80s by anyone who actually paid attention to research) was The Coaching Habit, run by Box of Crayons.
Thank you for the resource! I will definitely look into it.
I’ve seen too many good developers end up in dead end middle management, adding fat to an org they previously contributed to.
And every time it was this. Many not a complete lack of awareness, but at least a lack of belief that their technical skills could be highly valued.
Have I left some possible money on the table by sticking to my guns and staying technical? Once or twice. But that doesn’t mean I ended up stuck forever.