The author is very cynical on this series for businesses but I think there is a lot of truth in those writings. There is something fundamentally broken in the way we govern software products. From the interview process to the evaluation of the individual.<p>No engineering organisation can survive with just engineers. For many reasons. This limitation requires some roles to be there to support this process.<p>I think that most businesses practice process management. A person is there to make sure the team is compliant with the way the CEO, the board, the VPs etc, want to run the business.<p>What if we ban the term "manager" completely and instead focus on self organising teams and naturally elected leaders. Those leaders will go down with the team or be rewarded with the team. What if we treat product development like a well organised heist! The mastermind, the hacker, the explosives expert etc. will equally split the profits if this is job done well.
Fun read, but this is needlessly cynical and overwrought. Engineers compartmentalize because it's impossible to hold the entire system in your head. Companies parallelized the tracks because people finally figured out the best engineers do not always make good managers.<p>Is there a better system? Probably. Is this a grand conspiracy? No.
In my opinion, engineering managers should still spent at least 20% of their time contributing to the code base, hunting bugs and optimizing code.<p>And I see many reasons for that.<p>First, to avoid discouraging engineers to take the role.
Second, to maintain respect on a technical level from the team.<p>And finally, to stay in contact with the reality of the product, because in our field, spreadsheets are maps the territory is code.
> they are the gatekeepers to your advancement while you aren't on a critical path to theirs,<p>That's not true. In organizations that have these kinds of parallel tracks, advancement for managers is DIRECTLY tied to their ability to promote engineers on their team.<p>It's an aggregate effort. If you can't promote engineers that report to you either have
* Limited soft skills
* Inability to attract quality engineers
* Inability to take ownership of projects of significant complexity<p>In any of those cases, how can you promote a manager like this?<p>Managers are ABSOLUTELY incentivized to advance the careers of their reports (the good ones at least, but should this not be merit-based?)
Quite enjoyed this post and the one in <a href="https://defmacro.substack.com/p/how-to-get-promoted" rel="nofollow">https://defmacro.substack.com/p/how-to-get-promoted</a> (HN thread on it: <a href="https://news.ycombinator.com/item?id=24618707" rel="nofollow">https://news.ycombinator.com/item?id=24618707</a>).<p>This post is definitely a breath of fresh air considering all the blog posts (and posts by engineering managers elsewhere) on having separate career tracks for technical and management work and on how they're equal but clearly the perks and rewards are more biased towards one of those.
Alternative theory:<p>There are people with money/power, their primary skill is knowing how power/money works and knowing other people who also have this skill.<p>There are regular people, their skill is learning to do whatever people with power/money decide is important.<p>The reason managers get to decide salaries, who gets promoted, etc, is because managers mimic the power/money class, engineers mimic regular people.<p>That's all that's happening here. Feel free to replace money/power people and regular people with aristocrat/pleb, master/slave, clergy/believers, cult leader/cult follower, ubermensh/human, etc.<p>It's really all incredibly boring because regular people who graduate to money/power, quickly adopt money/power beliefs and the cycle continues.<p>(Author of this article should read a little Karl Marx, he's re-inventing Das Kapital)
I’m not sure the comparison with a surgery team is that compelling. A surgeon is basically repeating the same procedure and the objective is to perfect execution. The teams are small and the craft is the most important component for success. Similar things can be said about an orchestra or a scientific research team. For larger teams with a high coordination component, you need the leaders to be good at coordination. Being proficient at the craft helps in decision-making, but ultimately it’s about driving consensus, taking smart risks, and delivering results. That doesn’t necessarily indicate that managers as defined today are optimal. For example, a manager doesn’t necessarily need to define personnel compensation and performance to function, but some level of authority in decision making when consensus is not possible is valuable. The best managers I’ve seen, catalyze the emergence of the right answers among their team- they need some degree of domain knowledge, but again it’s a means to an end.
I don't get this. My manager is directly incentivized to keepe happy and get me promoted. Failing to do those things, across enough reports, will result in my managers performance suffering.<p>I provide feedback on my manager, and sure their manager could ignore it, but that's true in any hierarchical system. Unless you are the most powerful, someone can overrule you.<p>The conclusion about turnover is false. 20% turnover doesn't imply 20% redundancy. It could mean companies failed or run over capacity. It could mean to engineers moved companies 800 times. What it almost certainly does not mean is that every firm is running with 25% benched firmware engineers to take over the "useful" work when someone quits.<p>There's all kinds of wrong conclusions about salary. Having a floor on salaries doesn't actually imply his conclusion. Nor do I buy the idea that 100x productivity differences exist between employed engineers who are meeting expectations (hence the whole "floor"). And of course salaries can be higher in certain cases. The five data points from levels.fyi does not an argument make.<p>So what does management do? Help delegate, resolve conflict, and manage people in various capacities. I want to build shit. I don't want to spend my time reviewing people's performance and understanding their career goals.<p>I'm happy to delegate and mentor people, but that isn't everything someone needs. Not to mention stuff like hiring new people and such.<p>Sure that could "all" be done by engineers, but eventually those engineers run out of time to do anything except manage people. I've seen this with every manager I've ever had. They all want to do minor engineering work to stay fresh, or even want to TLM, but eventually the other aspects of work dominate.
The author has a zero sum view of how companies function: everyone is pitted against everyone else for a larger slice of a fixed pie. I find Neils Pflaeging's positive sum three network model more accurate and more actionable, see <a href="https://www.hrps.org/resources/people-strategy-journal/fall2020/Pages/linking-theory.aspx" rel="nofollow">https://www.hrps.org/resources/people-strategy-journal/fall2...</a>
> many of them ran the machines themselves, but there came a time when they've traded their role as craftsmen for the management track<p>That is a tremendous misunderstanding. Being engineering manager means the ability to craft MUCH MORE value in the same time. As a single engineer I can write and debug this much code per day. As a leader of team I have Nx capability, if I could figure out all the communication quirks.
Add more tracks.<p>Program Manager
- Project Manager
- Product Manager
- Architect<p>Define the capabilities and responsibilities expected of each. What does a "Principal Project Manager" do? How do they enable a team to deliver more predictably? What would you do with a project manager with 20+ years experience?<p>Same for each of the others.
In my observation the main privilege that shows management is higher status than engineering is that in larger companies the latter are never on-call and if they do get paged you can rest assured an engineer is going to bear the brunt of the consequences.
> Otherwise they disappear into meetings with people who have nothing to do with your product or team, presumably for very important reasons.<p>Why do managers spend 70% of their time on mysterious external meetings? What are they actually doing?