If management isn't a promotion, then engineering isn't a demotion

This is great in principle, but it’s only a starting point - there are huge issues that are left unaddressed.<p>The biggest issue is that it presents status as if it can be conferred independently of power, or as if we can change the dynamics purely by changing the way we think about this.<p>Managers have power for many reasons - they generally do have a significant influence over subordinate’s career prospects, and they have access to all kinds of organizational information that ICs simply can’t obtain, at the very least because they can usually spend time in conversation with other managers or in meetings with people at higher levels in the organization.<p>Engineers obtain power through indispensable or highly valued domain expertise or institutional knowledge.<p>Both forms of power are real and confer status.<p>If you move from management to engineering and your power as a manager is not replaced with corresponding power as an engineer then <i>you have been demoted in status</i>, irrespective of how the organization claims to value people.<p>Organizations that want to deny this, even with the most positive intentions end up gaslighting their employees. I.e. saying things like “Our organization doesn’t see these moves as a demotion”, when manifestly the individual’s power and status has changed in a way they and everyone else can directly perceive.

I think the focus on &quot;managers have power&quot; is overstated. Places I&#x27;ve worked (as both an IC and a manager) there&#x27;s also greater responsibility and higher ups hold the managers much more accountable than the ICs. I know many people who simply do not want the responsibility or accountability. Maybe the work is not better or worse, easier or harder, but often there is more pressure&#x2F;stress.

IC = individual contributor. I was trying to figure that out till they defined it halfway through the article.

In my opinion the best way to deal with the issue of hierarchy would be to make management an assignment, not a job. Someone takes on the role of &quot;manager&quot; for an upcoming project, at at the conclusion of that project they go back to engineering.<p>Apparently this is how Valve does things. I&#x27;ve heard Gabe Newell say in an interview (that I can&#x27;t find right now) that often times the management role is given to the newer employees. They see it as a big honor at first, but by the end of it they&#x27;re pretty happy to go back to engineering and let someone else deal with the responsibilities of management.

I think one thing that&#x27;s missing from this article is what engineers at higher levels of IC status (up to VP) do. When a Sr. Engineer is choosing between a Manager and a &quot;Principal Engineer&quot; type role, I have to remind them that PEs also don&#x27;t do much depth coding. They write proposals, discuss architecture, sit in meetings. Ultimately, the same mechanisms that Managers use.<p>There&#x27;s certainly SOME PEs that go deep in some areas but the majority I&#x27;ve worked with are broad owners of technology in large organizations. The difference between the two roles often has to do with what balance of time you want to spend influencing others for broad goals vs. building up jr. folks to accomplish your team&#x27;s goal.<p>In either case your authority is derived from whether people &quot;under&quot; you want to work with you. People who can&#x27;t get a set of people to go a certain direction won&#x27;t last long in either role.

One fix could be to give managers a title that is of lower rank than an engineer e.g. a manager’s official title should be “support” and ensure that every part of their role is about supporting the engineers they are responsible to.

They&#x27;re promotions if you get paid more. They&#x27;re demotions if you get paid less.<p>People refuse promotions all the time because they don&#x27;t want the role&#x2F;responsibility and prefer other stuff besides money. Doesn&#x27;t mean it wouldn&#x27;t have been a promotion.

It doesn&#x27;t matter how you define what is or isn&#x27;t a promotion.<p>The real issue is that <i>there isn&#x27;t one, single right answer</i> about what role is right for everybody.<p>It is not the case that being a manager is strictly better in every way for every person. That&#x27;s the assumption that people need to let go of.

Seems like people instinctively associate status with having control over other people. Maybe engineers could fight back by calling their programs cute names or putting hats on servers? Cloud computing is not helping though.

One further complication is when a move back to engineering is coupled to a change in employer.<p>As an interviewer, seeing somebody whose last job was in a management role apply for an IC position is a warning signal for me. Do they just apply for that position to get a foot in the door (especially for a move to a FAANG), and will they immediately angle for a move back to management?<p>So this is generally an area where I would ask follow up questions (and probe a bit harder in the technical interview, to assess whether any rust has crept into the technical skills). It&#x27;s not an automatic red flag; we&#x27;ve hired former managers for IC roles and it worked out, and leadership ambition can be a positive in any role, but it&#x27;s worth some exploring.

&gt; The work done by a database engineer is different from the work done by a VP marketing, or a director of database engineering. It is not inherently better or worse, easier or harder, more or less deserving of praise and admiration. It is simply different.<p>The big problem is that it is the VPs and directors who are getting together and deciding what everyone should be paid. And, lo and behold, somehow, they almost always decide that VPs and directors should get paid more than database engineers.

I am sure this is going to sound silly, but I honestly still have trouble figuring out what value is contributed by managers and executives at all.<p>I can&#x27;t get past the gut feeling that essentially the model hasn&#x27;t changed for thousands of years: wealthy owner, boss with whip, wage slaves being watched over.<p>I mean I imagine a group of people who are actually competent and intelligent working together. Some people would have more seniority and power, but everyone is actually a useful worker there involved in the day-to-day work.<p>I feel like most managers I have had have spent the majority of their efforts trying to pretend that problems don&#x27;t exist and reduce the amount of actual useful engineering work in order to push _anything_ out faster and cheaper. Or just basically telling people to hurry up.<p>That&#x27;s why I think we had the Boeing crapshow. The guy at the top was actually good at doing what management actually is for most companies, like I described above. He avoided doing real engineering and got a product out. And then hundreds of people died. And still they tried to blame the engineers.<p>It actually comes down to a class struggle for me. Parasites without integrity have managed to work their way to the top while feeding off of the honest workers below.<p>Sorry I know it&#x27;s kind of extreme but I am just being honest.

Interesting to compare this with practices in other professions, eg Doctors, Architects, Scientists and so forth.<p>Certainly management happens in those areas, but I believe that as your career progresses you would naturally be expected to take on more management activities - there isn&#x27;t a dual track in quite the same way.<p>In more recent times the waters appear to have become muddied somewhat, with the appearance (and glorification) of administrators, project managers, &#x27;CEOs&#x27; of various kinds.

This reads more like an attempt to extract “powers” that managers have and give them to staff &#x2F; principal engineers, but I think this is a bad mistake.<p>The people in those roles should influence those things, sure, but not “own” them, under some faulty idea that management doesn’t lead or own strategic and technical roadmaps or execution.<p>An engineering manager is someone who takes inputs from their immediate team or staff, as well as cross-functional stakeholders like product managers, directors, staff&#x2F;principal engineers, and more. Then you synthesize that into team or org investments: projects, roadmaps, staffing, resources, tools.<p>An engineering manager is not someone who “just executes 1-1s and fills out HR feedback cycles.”<p>They are more like a staff engineer or architect who takes an expanded point of view to include team dynamics, career growth, budgets, strategy and resources into the solution design process.<p>This often just <i>is</i> a promotion above staff or principal IC roles because it usurps and supersedes a lot of that work while also involving additional new work managing career growth, hiring, training, resource investment, etc.<p>I’d put product manager and engineering manager at the top of the promotion pyramid (excluding director &#x2F; VP &#x2F; executive roles). Staff and Principal ICs are next, then the rest of ICs.

If one group has firing power, and the other does not, they are not equal, regardless of what&#x27;s written down.

Managers do have some formal powers engineers don&#x27;t. They are three: they have access to budget; they perform the management function which assigns resources to problems. Since demand on resources almost always exceed available resources, they must assign priorities well. They also have high input on hiring choice.<p>Doing this well requires,<p>- requiring internal service suppliers to be (internal) customer driven. Too often however things we&#x27;d never put up with an external supplier we&#x27;d pay money for are tolerated and even protected by management. Internal suppliers are required for use. It&#x27;s hard to fire them.<p>- cross functional management: reduce silos. Again my area and your area might be &quot;clean&quot; but users of both of our services are often left to die in the crummy alley way between our groups. That&#x27;s a major source of frustration for engineers.<p>- promote openness and honesty: there&#x27;s too much happy talk and PC correctness at the office.<p>- supply chain management: engineers are often confronted by too many point solutions that don&#x27;t integrate. See above points. Managers need to cull and combine supply chains time to time.<p>- be customer in not supplier out. Older companies often have organizational norms where what can be produced is more a function of what internal politics allow or company culture tolerates than what customers want. Managers need to be on top of this.<p>- top management needs to give TLC to middle management perhaps the toughest job. Here they (middle mgmnt) cannot micromanage while they are held accountable for broad corporate goals like lean organizations, top line growth, reduce expenses, and better expense control. They neither are hands on nor are too far from the real work to be too abstract.<p>- teamwork (see schutz&#x27;s human element the best single read on this) namely that ridgid individuals are the single fastest way to break teams. Today&#x27;s work depends more than ever on good teams.<p>When managers do above well it&#x27;s a pleasure to work with them. It&#x27;s a difficult task.

If you think there are a lot of bad managers now wait until they&#x27;re explicitly paid less and aren&#x27;t accountable for their team&#x27;s impact (what happens when you shift all accountability of technical strategy to TL).

Solution: take away some of the formal powers of management - for example the ability to assign resources on personal decisions. A manger wants X to happen so spends Y of her budget to hire a team to do it.<p>That is power.<p>Simply make all such decisions open, transparent and democratically elected - in other words have employees vote.<p>We live in a world where we value democracy but spend our working lives in autocratic dictatorships.<p>Yes Coase and efficient allocation, but really I think information revolution is changing that equation.<p>Democracy in companies now! Struggle brothers !

This hit close to home.<p>A manager at a previous company kept saying that his role was to support engineers and that management was a separate track, that he wasn’t my superior (probably from some internal training BS). He acted completely the opposite way. He obviously wielded more power by having more information, and, to add insult to injury, played tech lead as well.<p>Suffice it to say, over the years almost all the original ICs have left his team, and he’s still wondering why he can’t get the team to run.<p>Good riddance.

Does anyone do the pendulum? How well does it work?

There is another aspect of it: when you want to change from management to &quot;lower&quot; status jobs, the person hiring you will have a hard time understanding your decision. &quot;You understand you&#x27;re overqualified for this post, right&quot;? They get suspicious even if you&#x27;re a perfect candidate.

This is an interesting instance of two HN tropes in conflict: Managers are able to ‘create’ more (by improving IC productivity) than any individual contributor (and thus more value), unless you believe in 10x engineers.

If your company is like mine, then they&#x27;ll combine the jobs and pay you the lower of the two salaries while selling it as a great opportunity.<p>Simultaneous promotion and demotion.

I really hate these kinds of articles, primarily because they are trying to sugar-coat reality here.<p>The fact of the matter is this, management _is_ a promotion, because you get paid more and you gain access to more powers. If it were _not_ a promotion within the company, no one would take it up.<p>Management is a simple deal, you give up power _outside_ of the company for power _within_ the company. It is far easier to join another company as an Engineer than it is as an Engineering Manager.<p>However, I agree that it should not be. It should not be there to create a sense of hierarchy. This is why, I believe that you should rotate your managers _within_ the team. Back at my old company, we had people who would go into a Team Lead position for a certain project, and then someone else would take over.<p>Pay was already high, so no one really wanted to take up lead because it meant more responsibility.<p>This is how power needs to be treated, you should not have it for too long. This is why we have term limits.