Career Development: What It Means to Be a Manager, Director, or VP (2015)

I agree about the hidden work, but you describe it in a reactionary manner.

A huge amount of management effort goes into being proactive so you don't even need to get to the point in the conversation where they voice wanting to leave. Or when they do, you've seen it coming, have plans in place and they move on with your blessing.

* Creating a culture where employees (and managers) feel valued and have autonomy.

* Ensuring employees are clear about where they are headed, giving them something to work towards.

* Proactively identifying and unblocking issues before they become crises, often across functions.

* Identifying areas of frustrations for teams and individuals.

That's just a small number of the things you'll be doing, and whilst scope varies massively by company size (though until you get to the large corp environment most of this is still covered up to the VP / CTO level), you'll be juggling it all alongside technical input, cross functional leadership responsibilities (VP may well be in the SLT if the company isn't huge), horizon scanning, constant process refinement.. The pillars of people, process and technology all need to be constantly considered..

Having done this repeatedly from IC all the way through Head, Director and VP level (and up to CTO), I can say that being a proactive problem solver is always required of a good manager / Director / VP.

Edit: Having read the actual article ;)

IC paths map this quite well too..

Tech Lead maps to manager, Staff maps to Director, Principal to VP

This is very true and I learned this quickly when moving to a management role. As an IC, when someone is out for some life event, it might mean more work for you to pick up the slack. As a manager, everyone on your team's problems become your problems.

Cancer/long-term illness, death in the family, miscarriages, etc all weigh heavily on my mind when something happens to one of my direct reports.

Not asking for pity, but being a manager has a heavy emotional toll if you have even the slightest bit of empathy that I don't think most ICs appreciate fully.

I had the same experience moving from IC to manager. I didn't realize the amount of work that managers are doing that I didn't see and more importantly that they couldn't tell me about.

Retention is definitely one, but there's the flip side of dealing with poor performance. You can't announce to everyone that one of the team is on a PIP or struggling with personal issues. But a poor performer means that I'm doing a _ton_ of work to figure out how to fix the issue (whether that's spending hours every week coaching them, building all the long-term documentation that HR requires before we can fire someone, picking up some of their slack myself in the meantime...)

Coordination of people also takes way more time than I realized as an IC. If you meet with your manager once per week, that's an hour out of your week. But your manager is meeting with everyone on the team and a good manager is going to spend at _least_ as much time thinking and planning for each of those meetings as they spend in the meetings themselves even if everything is going well. They have to make sure nobody is accidentally working on the same thing or impacting someone else, talking to other teams, that sort of thing. That one hour out of your week is 1-2 days for your manager. Not to mention that they then have to go do the same sort of coordination with other teams.

You have something that blows up your week that you need to escalate once per quarter? Multiply that by the number of reports your manager has and that's how much time they've spent fighting fires this quarter. And they need to explain to their leadership what happened and why it won't happen again.

Etc. etc. It's not harder work, but it is very different work from being an IC. (On the other hand, being a manager has made me a better IC too. Everyone I've ever managed that was previously a manager themselves has this -- they know exactly what I need to know because they know what they needed to know, so our 1:1s go much faster :) )

One anecdote I have is that when I first moved to a management role, I told a colleague how happy I was that I'd finally have real control over my calendar. After he finished laughing (literally) he said "your calendar belongs to your team and you'll never be in control of that again". He was absolutely right: if something goes wrong or someone is unhappy, everything else moves aside so I can fix my team's problem.

In my (big tech) company, managers have little leverage to retain people. Salary/bonus aren't in their control. Even evaluation aren't decided by them.

They can try to make people happy so they stay in the team, but I find that they aren't very good at that either. When the team has issues, I don't find them effective to solve any problem.

They do administrative work, communicate with leadership, hire, 1:1 which are more or less useful, help with roadmapping and alignement, attend calibration meetings for evaluation.

I'm not saying they're not useful or that they don't work, but I find they leave the hard parts to the team to figure out. The hard part would be things like pushing backs on leadership demands, helping prioritizing tasks in the team.

Concrete example: right now, everybody is overworked in my team, oncall is hard because we're pushed to ship new features, not work on reliability. Manager pretends to be empathetic, "always happy to help". But practically does nothing.

My criteria for a good manager is that they're not harmful and don't add friction and stress (and those ones aren't appreciated by higher management). More than that, I've never seen it. But maybe i wasn't lucky.

In my experience the inverse is also true. Dealing with performance and behavioral issues can take a huge amount of time, and it something that is never discussed with parties who are not involved.

Well run engineering organizations are like a well running engine. They need to have solid parts but they also need constant attention and fine tuning. The best managers do this well.

If you are a very senior IC, managers may consult you in these situations as well. Fishing for interesting projects or possibly even trying to have you talk to the person leaving as well. You generally would have context and an ability to connect with the other IC in a way a manager may not. I've never been in management but have on many occasions been roped into these scenarios.

There's also a huge part of "managing moods" to prevent people from thinking about leaving in the first place. And all of that within the constraints of the department budget and company policies.

Its a good example to call out but it should be obvious to anyone genuinely considering the transition. Managers are there to manage people, the job is easy when the teams awesome and the jobs hard when the team isn't awesome. This includes poor performance, attrition, and people drama. All things that come with the territory of managing humans.

I've had a similar experience, however I found it tied to the size of the company. If you're a director at a large corporation, you will be very siloed and you most likely won't be doing much coding. If you're a directory at a small company, you're going to be coding, managing coders, and being part of leadership and strategic discussions.

And it's not necessarily a bad thing. I should think adaptive roles would be a benefit, not a hazard. At my company we simply list "software engineer, all levels" in our postings.

> The only thing you can really depend on when it comes to leadership titles in software

It's not just leadership titles. Even if they list tech stack, responsibility or any of it it may not eventually be reality. Sometimes it's a wish list, sometimes it's planned and other times they "forgot" to update it.

Isn’t the most effective way to find out what you’ll be doing is by measuring how many people are going to be under you overall?

A “vp” at a startup with 20 people under them will likely have very different responsibilities than a faang director with 200.

I believe this is why you get asked how many people are under you when interviewing at these roles. The titles - as far as I’ve seen - are mostly meaningless. It’s about the scale of your decisions. I know the article talks about the type of influence/decisions you’ll be making. (Executing others decisions vs making the decisions) But I find it’s rare for these bigger companies to really give a shit about that. They care more about how many people you’ve had under you. It’s rare to see someone be VP at startups with a few people (and that’s their only experience) and then be VP at faang in their next role.

s/I'm/I've

[flagged]

A great book is "Strategy and the Fat Smoker". It's written by a consultant but points out an obvious point: the quality of the strategy itself is not nearly as impactful as the ability to execute. The author compares this to being a fat smoker who won't change their habits - knowing the right strategy is insufficient.

> Nobody gives a hoot about profit.

— W. Edwards Deming

Ruin is subjective, results are objective.

I think that what you are missing is that "what must I do to make L10" and "what is valuable to the company" are typically somewhat orthogonal. A prototypical example is that almost every career ladder out there mentions things like "impact" and architect/systems design work rather than often more valuable maintenance work that keeps current systems running. In addition, measuring the contribution of any individual to a team effort is always difficult, in some cases pretty much impossible until years later. This means that it is always possible to game such career frameworks by focusing only on the things the framework rewards and skipping everything else.

In short, encouraging people to get to the next career level in a well-defined framework is exactly the type of "situation where people are rewarded for being bolshy and savvy rather than being valuable to the company" that you mention as being undesirable.

> Otherwise you can easily end up in a situation where people are rewarded for being bolshy and savvy rather than valuable to the company.

This is how it works though. If you have someone that is quiet and does amazing work but doesn't seek out promotions and doesn't actively market their accomplishments then it could happen that they will lag on salary over time. If there are good managers advocating for their people then this will happen less.

Its a really simple conversation for a manager to have with their mgmt and HR about person X's salary is behind market, Y and Z are in same title so I think we need to bump them up a little to keep pace. A good organization will recognize that and help make something happen. Bad organizations will have an attitude of not doing anything until its too late. If you work in a bad organization then the path to get raises there is to do the work yourself, go out to the market, interview and get offer(s) and bring them back and/or just leave. I say good/bad organizations but really its not binary, there are situations companies may be in where raises or market based increases aren't possible, there might be bad executives but good managers, etc. YMMV.

I think the problem that developers may feel is that they want to earn more money for being a better developer, but not nessicarily accept more responsibility or spend less time developing code.

I do agree with you that clear progression frameworks are a necessity for transparency and goals for developers, but some may feel daunted by a jump up meaning they don't get to write as much code if L39 (or whatever) starts including responsibilites that pushes you into meetings and convincing.

To get promoted you must just pander to your boss and completely ignore what your job is supposed to be and what the company needs.

> It encourages a mindset of saying, “what must I do to make L10” when you want to say, “I want a $10K raise.”

> It's not obvious to me why this is a bad thing.

In most cases, level isn't the gaming type level. Level these days is more like different jobs. What used to be analyst, architect, tech lead etc are all disguised as "level".

As you rise in levels you might code less and focus on system design, coordinating, mentoring or something else. Is it really "career development"? It's moving sideways.

> Am I missing something here?

Yes, reward people for ownership, and getting better at their job. That's not what the current level system is.

Pay and rank have a connection but not a direct connection.

What is the value of your work? Is your impact worth millions to the company? Is it worth just your salary? Are you in an overhead function that enables the rest of the business? Do you work on just new business ideas that have no value now but maybe a lot later? Can you do things that others can not or will not?

The answers to these questions and your ability to negotiate will dictate your pay. The fact is that being savvy and being able to navigate politics/being well liked, intentionally or otherwise, is hugely important. Most companies don’t make it particularly clear how to progress or how a manager should compensate the team aside from a rough rubric on how to get there. Most years an HR BP says to me “you have a X% budget, we recommend an (X - 2)% COLA and the rest is for your merit raises.” At some places they just ask for a stack rank and come up with the number. In either system, demonstrated effectiveness and willingness to work well with people (aka being savvy, political, likable, full of BS, etc - pick your favorite) affects your ability to get more than that Cost of Living Adjustment. When it’s promotion time, a good manager will make sure your skills fit the role. A bad one just picks someone based on their biases - positive in your favor in the short term, bad for your career if you never catch up to what is needed to do the job.

Now this is the time to draw the line at pay vs rank. Most of leveling and rank is about org design and you can be a Director making 70K or a Director making 300K in the same type of software role in the same vertical.

Leveling is an HR and management thing. Value is what you provide and should be compensated for. Bands are there to keep things from being completely insane. Levels are a guide for what should be.

If you were able to change your title at work to “Professional Enthusiast” and your level to L-1, but did all the same work and were just as effective, would you want your pay to be any different? Again, let’s differentiate value and compensation from the rest of the structural stuff.

These management constructs are checks and balances on both good and bad managers alike. Even if you do a great job as a manager and someone is ready to be promoted, your HR BP can have the bad news that there is no money for that promotion and to assign no new responsibilities (“no free consulting” as I have had to tell my reports in this situation). Conversely the money could be there but the space for the role is not. Do you really want to work somewhere that has 1000 people and 100 VPs? Who exactly is in charge? Is it VP Tom who is a peer of VP Jimmy who reports to VP Marry who reports to SVP Sarah? Heck no, just break the bands. Every time I’ve had a long tenured Staff/Principle engineer they’re sitting at 25% over what the band says they should make and no one in HR or the SLT ever complains. They see that and they know exactly who that person is.

In turn, all of this exists to solve the problem of org design and hierarchy. Leveling is a tool against title inflation. Need to restrict movement into senior management? Get pickier in your leveling. Need to retain people? Give them a bonus structure or widen bands. Titles are nice and all but they don’t buy private school tuitions, sports cars, and fancy vacations. My L4 employees that could afford a new condo and a vacation to Bali were never all that upset they were never going to see L3 and L2 due to org design constraints.

I myself am a slightly funny example. I moved from a multinational based in Europe to a small software company in California. My title went from Director (L3 there, Senior directors and in between to VP got point numbers) to Senior Manager (L4.X on the old scale but an effective L3) and my span of control from 30-60 to 6. My job is basically the same except for the number of people in my span of control (in the former job the same number of Managers and Staff engineers reported to me directly). We don’t have a CTO and there are two VPs where one has a “Head of” title. There are a couple Directors as well (call them effective L2 here). Effectively my title has changed but my level has not. The pay also went up a little bit with the move.

There is really no where for me to go in this hierarchy since we’re pretty small. If/when they add a CTO, down the ladder I go, a CTO level is added, and more restrictions are placed to stratify the leveling to match the stratification of the jobs. What will a CTO do over the current Head of Tech? Not sure as my skip level does everything all the other CTOs I’ve worked for has done. I’m sure they’ll come up with something for my current Skip Level to stop doing though.

In some companies I’ve worked and famously at Google, you have ICs that are at the VP level, by either title or level, that aside from having to go to a few mandatory Senior Management type meetings are exceptionally well paid Staff/Principle engineers. There’s nothing wrong with this so long as the title is not abused and the value is there. It tends to look crazy though. Why do these situations exist? Someone needed to pay them X to get into the business and X happened to be in the band for VP. Or, they were part of an acquisition and actually stuck around. They needed some significant title and to report to the CEO and it happens that VP is the currency available for that even though they’re not doing that work. At my last job we didn’t do this and at one point a CTO of an acquisition actually reported to me, a Director.

It’s the holes in the way things work that best betray that value and title are not directly connected but management come as close as possible just to make it possible to figure out what the heck is going on at a glance. In turn, ask for that 10k if you think you’re worth it. It may be easier to get it than to get the level bump.

i smiled at that too. miss those innocent times.

The author is excited to talk about helping the employee grow and have more impact, which (if successful) should make them more valuable to the company, resulting in promotion and increased compensation.

He perceives employees who want to talk with him about "leveling" as seeking the formula or checklist to get paid more, and not necessarily about growing or putting in the work.

The latter is fine if your performance objectives are objective and directly aligned with company success (i.e. achievement of sales quotas). It's more fraught if your performance objectives are more subjective or defined in ways that are proxies for company success—it's easy to fall prey to https://en.wikipedia.org/wiki/Goodhart%27s_law where employees do the things that get them promoted, which may actually make them or the company more valuable.

I’ve managed a few people who have come to the same conclusion as you did there, and had a mixed success rate there.

It’s not about not asking questions, it’s about knowing which questions are appropriate to ask, and if you don’t know the answer to that it’s my job to guide you to finding it out.

I’ve never held back on a promotion because someone asked too many questions, but I have recommended we don’t promote because they’re asking questions that they should be answering themselves. The gauge of skill is “do you know what you don’t know”, basically.

> Every junior developer is told they should feel free to ask questions - and now they have a financial incentive not to.

This is such a fine line though, encourage developers to ask questions, but they also need to try problem-solving before they immediately go asking for help. If I _consistently_ get asked for help on problems that I can solve it within 5-10 minutes using no “company knowledge“ (just plain debugging), then that cements someone as “junior” in my mind.

Contrast that with the people who ask lots of questions but they are well thought out questions that require knowledge of the inner workings of the system.

“This isn’t working” vs “I can’t figure out X works, I tried Y and Z but that gave me this error that I don’t understand but I did find….”

Asking questions and unblocking yourself is a required competency for acting independently.

Developers should aim to be resourceful and respect others time, but I expect my reports to seek out help if they get genuinely stuck for more than 15 minutes (no clue what to do.)

It's much better than waiting around for your manager to find out you were working on the wrong problems (or nothing, waiting for instructions.)

I think to be a manager, also 'read the room', or 'context'. Your response is just a bunch of "I this" , "I That". Nobody knows you. What does your current step in life have to do with anything, with anybody else.

The "I" isn't important. At best someone that does this, could just bore everyone, or at worst could alienate, or give impression as arrogant, self centered, if you are only talking about yourself. (you didn't, but could lead to that).

It is possible to phrase information in a non-self referential way. Talk about what others want to hear about.