If you ask me, the "demotion" in this article is not going from Director of Design to Software Developer. The demotion is going from a senior level position to an entry level one. But that's not how it's presented.
If you ask me, the "demotion" in this article is not going from Director of Design to Software Developer. The demotion is going from a senior level position to an entry level one. But that's not how it's presented.
As an individual contributor, the impact of your decisions may be broad, but however broad your individual impact is, your manager's impact on you is [broad * number of directs], so it's always "greater" (note: not better, just greater).
So in that sense, the "value" of a manager/director is "higher".
IMO it's all just a series of roles, and you need someone to do both. Someone has to be designing and building code while someone else attends meetings and understands the larger context of that code, making sure the code makes sense a week/month/year later.
In fact, I prefer it when managers take on a much less "HR" role, and instead act as "go-fers" for their team, a la "how can I unblock you today?". Bonus points if they can mentor, but not necessary.
Being an individual contributor isn't a "demotion", but it is a change in where your impact hits (people vs. things). You need both, and it's fundamentally a partnership, I wish more people realized that.
Every time I hear this explanation, I can't help but think "so we're still smoking Luck Strikes, huh?"
When you make a decision as a software engineer, the impact of that decision can often have a multiplicative or even exponential force.
The goal of 21st century organizations -- especially software organizations -- should be to make things scale in way that's at most sublinear with the number of people you throw at it.
Automation prints money and businesses that can harness automation have huge profit margins.
People are expensive and body shops are shitty companies waiting to be replaced when technology catches up with whatever work they're throwing bodies at.
It's not 1960 anymore. Invest in your automators and treat your people managers as a low-value-add cost center.
And, more importantly, what might be the massive unintended consequences of routing your org's permission structure in the same way you route its head-count?
Strategic decision-making is not the same as people managing, and people managing can even create blind-spots that get in the way of good decision-making.
Would you rather have developers wearing every hat in an org? When would they find time to code? I know many developers who don't want to have to do all of that work simultaneously, and are extremely grateful for a manager who can take many of these tasks off their plate.
When was the last time you tried to add a recurring meeting to a development team's calendar? They... don't like it, in my experience, and I respect the hell out of that.
Just because you treat something as low-value-add or admit it's a cost center doesn't mean you don't need that work to happen!
> When was the last time you tried to add a recurring meeting to a development team's calendar?
Yes, I agree, managers' secretarial and political work is incredibly important to the success of an org. But the 1960s idea that it's a "force multiplier" worth high comp is a mistake.
I'm not contesting whether managerial work is important or necessary or to be respected. I'm contesting the idea that managerial work is a force multiplier for individual contributors, in any sense other than in the same sense that janitorial work or admin assistant work is a force multiplier. The only orgs where I've seen managers to be actual force multipliers were body shops.
This is why managers often get paid more, and it applies even more the further up the chain you go. A good CEO is worth every single penny of the millions they get paid, because of the multiplicative force they have on everyone below them on the org chart.
I think we are disagreeing because we're talking past one another. Hopefully the following observation helps make my point:
The average base pay for a manger in the USA is much lower than the average base pay for an engineer in the USA.
I'm talking about management as a discipline in general and engineering as a discipline in general.
> A good manager is worth 10x a good developer, and a good developer managed by a good manager is 100x base developer value.
Can you define "good" in a way that would allow us to empirically test this statement that doesn't make this statement a literal tautology?
The skills involved in figuring out what to build are entirely separate from the skills involved in building, and you are making the classic mistake of worshiping the skill of building to the exclusion of all other skills.
It is much rarer to know what to build than it is to know how to build.
Right. The whole thing is a silly tautology.
Good managers are force multipliers. Better hire good managers! and then if they don't force multiply they must not have been good managers :(
It's literally an unfalsifiable tautology.
> The skills involved in figuring out what to build are entirely separate from the skills involved in building, and you are making the classic mistake of worshiping the skill of building to the exclusion of all other skills.
"Knowing what to build" is not what 90+% of managers do.
A good manager will improve the performance of her direct reports. If you can't understand this fact, then I don't think you and I have anything more to discuss.
Have a good day!
Right. A good manager indisputably force multiplies because a good manager is defined as someone who improves the performance of her direct reports...
Importantly, any empirical evidence that less management structure improves outcomes is easy to dismiss because it's really just proof that the particular manager/company that failed wasn't a "good" manager/management structure. After all, if they were "good", then the output of engineers would have been multiplied, right?!
Tautology (n): a statement that is true by necessity or by virtue of its logical form.
Saying that we know good managers force multiply by improving performance of reports -- and then defining "good" to mean "improve the performance of her direct reports" -- is absolutely a tautology.
More importantly, ignoring empirical evidence by making a rational appeal to the truth of this tautology creates a rather pointless conversation.
Given the choice between blind faith in a tautology that "good managers = good" and empirical evidence that sometimes "less emphasis on/power for managers = better", I prefer the latter.
You have a good day as well :)
That depends on how high the multiplier is and how many direct reports a manager has. A manager with 5 direct reports and a multiplier of 110% is only producing as much net value as 0.5 of his/her reports. A manager with 20 direct reports and a multiplier of 106% produces a net value of 1.2 of his/her reports.
It's not safe to say that managers in general produce more value. Some do, some don't. It depends on their ability and the abilities of those they share a management relationship with. But the same could be said about engineers/architects/devs.
It's 2002. Does a Kohls Director Of Whatever with tens of direct reports and thousands of people below those reports have more leverage than a single engineer at Amazon?
It's 2021. Does a manager of hundreds of warehouse workers have more leverage/impact potential than a single engineer in a robotics R&D division?
But this is obviously false, right? If the IC is truly a spectacular IC, then it's likely that no matter which manager they're under, they will have large impact.
The impact of the manager isn't the entire impact of their directs, but rather the relative difference between the impact of their directs and the impact their directs would have under a different manager. Which is substantially less, and could easily be less than the impact of a particularly strong IC.
The above resonates as an exercise in tautology to me. If the job of a manager is defined as a position in which a person's decisions will have a multiplicative force... well... then of course their decisions will have a multiplicative force! Though I'm not sure the above is even remotely true for the vast majority of management-type positions, save those at the highest-level. And even if it is... then it of course a fact that the value derived from an individual in such a position is therefore not related to the "multiplicative force", rather, the decisions themselves.
I'd wager most managers come from two camps (the first two below):
1. Those that are ex individual contributors who have accumulated enough seniority and experience to best-understand not "what to build", but rather, "how to build it best". And are therefore given the authority, responsibility, and pay-check to do so.
2. And those who are not really managers at all, and whose job would be more accurately named "coordinators". This seems to be the role you are hitting on at end. You know, the guy who asks the engineers "how can I unblock you today?" and whose explicit role is to have the authority to act on the answer. Notably, not synthesizing the answer in the first place.
3. The third camp is of course the ones to which you seem to be alluding in your comment. The high-level, c-suite, "director of strategy"-type roles. And you are exactly right about them. Clearly the person deciding which widget needs to be built is in a position of tremendous responsibility when the value they can add (and remove) is extremely consequential (assuming the resources required to do so are equally consequential). There aren't many roles like this in a company.
It's the second group of "managers", I think, that the OP is confused about. They don't actually make that many decisions, and the ones that they do make are rarely different from the one their most competent reports wouldn't also make. Sure these "managers" sit in meetings and talk about the larger context of the code, the product vision, etc., but only insofar as that its useful to have someone who can distill and relay this information back to the engineers building the product. Because as an engineer it is, of course, nearly impossible to build a truly great product if you don't understand its larger context. It is this group of managers where the tautology is glaring. It is their job to carry-out the work necessary to multiply force. The work isn't all that creative, doesn't require much judgment, and rarely requires much expertise. The value isn't in multiplying force, it's in just showing up...
To clarify, I'm not suggesting managers don't have value, and certainly don't believe there doesn't exist a spectrum between those in the position. Some people multiply force more than others. They know to ask "how can I unblock you today?". They know that Jim doesn't like to be bothered before 11AM. That Susan is more productive if she has a tight feedback loop. Or that Ron isn't as good as Pam at test coverage. They know how to find and exploit people strengths while also minimizing their weaknesses. This is valuable.
Even so I'd wager most of the time a manager's pay is calibrated such that they make more than those whom they manage regardless of the value these people (the people being managed) contribute and without any sort of rigorous appraisal of how much value they bring or how much force they multiply. How could you? The skills illustrated above can't easily be captured in a pay band...
Smart tech companies have two paths, the management and the engineer path. Where they both have certain expectations but there is no pay ceiling. Bad tech companies tend to disregard this and there is a point that you can no longer get a raise unless you "move up" and become a manager.
In my 25 working years, I've learned this is mostly lip service. Yes, there are ICs who make as much as a VP. But look at Amazon. There are maybe ten people in that company that are IC level making what VPs make. And thousands of VPs.
To be a VP, you have to be a really great manager. To get VP pay as an IC (ie. Distinguished Engineer), you have to be the best in the world in your field.
So yeah, it's possible to have equivalent tracks, but the reality is that you will never make as much as an IC than if you switch to the management track.
E.g., the 2nd/3rd-to-last rung of a FAANG IC ladder makes much more than managers and directors at most other companies in the USA.
This is significant because it's much easier to become a senior IC at a FAANG than to become a Regional Director at the typical company in the USA.
The manager level can result in entire teams quitting, failing to support each other or an atmosphere where catching each others' mistakes is discouraged.
Some jobs are paid based (roughly) on the value they bring and others are paid based on the threat/cost of large mistakes.
Managers don't generate defects. Developers do. Not to mention that a lot of the times it's much harder to reverse an engineering decision vs a managerial one.
Most outages are caused by developers and IT, not managers. This perception that there is higher risk as a manager is false. As a developer I make multiple decisions daily, interpret vague requirements, make judgement calls, request new technologies etc. My manager understands about 20% of the decisions I make. Here is the kicker since I work in DevOps, with a super heavy emphasis on the Dev side. 70% of my decisions have wide ranging effect, much wider than my manager's eight person team.
Finally note that no one really talks about 10x Managers, but people talk about 10x Developers. Why is that? Managers are glorified cheerleaders. Most managers are average, their value is vague but they are controlled by managers so its an endless loop till you hit the worker layer that get things done.
Yes, you're right that defects are made by developers. But you'd be hard pressed to find an example of a software defect that destroyed a company. Even if you as a DevOps engineer cause your company to be down for a day, it probably would have little effect on your company's bottom line.
I was in charge of Reliability for Netflix. Our whole site was down for Christmas Day one year. No one was fired, and it barely affected anything. That was a pretty major defect.
However, the way that management handled that outage had a huge effect on the company surviving that incident. Making sure we focused on the right problems to solve to prevent it from happening again. Creating entire new groups of engineers and then hiring them to solve specific problems of moving traffic between regions.
So yeah, management is really important, and a good manager is definitely more effective than a single engineer. And management decisions can destroy a company, but I doubt you can find even one example of a single engineer's decision that took down a company.
> Creating entire new groups of engineers and then hiring them to solve specific problems of moving traffic between regions.
Albeit admirable, like heck yeah that was a great outcome, it's not a manager decision. Most likely it was a VP or Sr Director decision. Perhaps a manager brought it up as an idea. So if we are talking about Sr Director's+ then yes, their decisions can absolutely bring down a business. Granted I am not familiar with Netflix's org chart so perhaps it works differently, from some basic reading it looks like Netflix follows a decentralized command of sorts.
My beef with the original poster was the implication of risk. Both managers and devs have risk with their decisions. It's not just a manager thing. In the end, when Netflix went down where did the mistake come from? A manager or an architecture decision? Probably it was both.
In that particular case it was an engineer making a mistake, but my point was that it wasn't anywhere close to a fatal mistake.
But more importantly, when a team had repeated technical failures, it was usually the manager who suffered the consequences. Especially if their failures were causing problems with other teams.
The manager had the higher risk job because they were blamed for their team's failures. Therefore they had to be compensated to account for that risk to their job.
It's the same reason CEOs get huge golden parachutes. Because their job is constantly at risk for not only their decisions but the decisions of everyone below them. So they get compensated for that risk.
The relationship between contribution and compensation is obvious. If you bring more value to the company, the company compensates you directly with a portion of that value.
But why does a position with greater risk necessitate greater compensation?
EDIT: Everything below here was in the original post. However, I re-read it and realized it had little to do with the relationship between risk and compensation.
I don't buy the idea that managers are liable for the mistakes of their reports. That would cause a snowball effect in large organizations, resulting in extremely high turnover for leadership positions.
Managers share some liability for their reports' mistakes, but they also share some reward for their reports' successes. Those liabilities and rewards are split across all of their reports, resulting in what are usually relatively stable positions within a company. A lazy manager can get along by just regularly pruning reports who produce more liability than reward.
There are various methods to address risk:
1. Avoid the risk
2. Reduce the risk
3. Transfer the risk
4. Accept the risk
When you buy insurance, you're doing #3. If you self-insure, you're doing #4. Either strategy requires putting some money towards premiums, the expected possible cost of the risk.
It's much cheaper to pursue #1 or #2. You're then saving an amount exactly equal to the premiums don't have to pay under #3 or #4.
Thus, you can pay a person to do #1/#2 a fraction of the equivalent cost of #3/#4 and still come out ahead.
> A lazy manager can get along by just regularly pruning reports who produce more liability than reward.
Yup, and the books will balance.
Of course anything is possible, but there is often a chain of managerial command (managers of managers) to catch mistakes. It's pretty hard for a single, middling manager to inflict costly mistakes anymore than an individual engineer. Also, I've seen management levels that are 0 - 1 subordinates deep (managers of none).
Employees are the first to get fired when a company struggles.
Managers are less likely to be fired, and when it happens they can have more savings as they salaries are higher.
CEOs quit failing companies with multi-million exit bonuses.
So no, salaries are based on power, and so is the ability to dodge risks and responsibilities.