Parallel Tracks | Hacker News Reader

Parallel Tracks

defmacro.substack.com

109 pointsgringoDan62 comments

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.

No engineering organisation can survive with just engineers. For many reasons. This limitation requires some roles to be there to support this process.

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.

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.

The real reason for parallel tracks is to prevent people from becoming managers. Not to encourage it. The challenge before parallel tracks was common was that every engineer assumed the only way to get ahead was to stop coding and manage people.

The parallel tracks more or less has the same level constraints as you go. Namely, you cannot have 5 L4's on a team with 5 people, and one L4 manager.

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.

Is there a better system? Probably. Is this a grand conspiracy? No.

It isn't a conspiracy, it's an emergent system.

"Why did all major software companies settle on parallel career tracks? To keep engineering managers from developing loyalty to engineers."

I think your tone here implies intent

You're right. When I talk about complex systems I generally mean "this behavior emerged because of pressure to optimize for property X", but it's awkward to keep repeating that so I anthropomorphize them for simplicity. Should clarify that at some point.

This is a great clarification. I'd even argue that systems and organizations can have an independent intent, though we don't often use the word in that context.

> I'd even argue that systems and organizations can have an independent intent

You're not the only one: http://slatestarcodex.com/2014/07/30/meditations-on-moloch/ (If section I seems a bit slow - it's busy establishing that there is a problem in the first place - skip to section II.)

I see a lot of people, myself included, who dreaded the way company works. I'm outside the field now, and having seen my own failures to create software / group / work. I tend to believe that I was very much partially blind. I also see a lot of younger people speaking like me, disgust of the system, laudable desires to make great work for less, but failing to make a dent (at best) or going like me, spinning in ideals.

All this to ask, can we adjust the emergent system just to improve it ? can we describe better what are the reasons behind the links between different groups so new generations don't have to question them ?

In my opinion, engineering managers should still spent at least 20% of their time contributing to the code base, hunting bugs and optimizing code.

And I see many reasons for that.

First, to avoid discouraging engineers to take the role. Second, to maintain respect on a technical level from the team.

And finally, to stay in contact with the reality of the product, because in our field, spreadsheets are maps the territory is code.

Would love it if my manager would validate bugs in the code base, grasp the technical requirements and the assign it properly

And to feel a little bit of the pain if they're leading the team down a bad path.

> they are the gatekeepers to your advancement while you aren't on a critical path to theirs,

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.

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

In any of those cases, how can you promote a manager like this?

Managers are ABSOLUTELY incentivized to advance the careers of their reports (the good ones at least, but should this not be merit-based?)

Never heard of this at all. Managers are weakly incentivized. The way it works in my FANG company is you put in your rankings of your reports with one top contributor. HR uses their model to spit out customized compensation. I know because I assisted HR in developing the model. At a high enough management level it’s possible to raise all boats but the article covers that as L6+ manager ie upper management.

L6 management isn't "upper" management. L5 is the first level you can manage engineers. At L6, you may, or may not, be managing another manager or two.

Semantics and not true of all FAANG companies, eg check https://www.levels.fyi/?compare=Google,Facebook,Microsoft&tr.... Historically, the org levels pull from military enlisted/officer E1-7 vs O1-7 splits so actually would lean towards our definition more.

Levels.fyi supports what I said. Amazon, Facebook, and Google have L6 as the second level of management. (Facebook sometimes uses the "L" indicator, and M1 is L6). There is no company where "L6" means upper management.

> Historically, the org levels pull from military enlisted/officer E1-7 vs O1-7 splits so actually would lean towards our definition more.

I don't think there's reason to believe this. Google, for example, doesn't have a split. Nor does Amazon. Facebook does, but it only resembles the military rankings by coincidence, since it likely took more from Google's leveling system originally (and afaik there are still leftovers from that).

To the main point, while the compensation methodologies work differently at every company, I expect that the "rising tide" effect is always present.

Even if what you describe is true (which varies from company to company), it doesn't mean that engineers make the decision about whether their manager gets promoted, which is what TFA is talking about ("they are the gatekeepers to your advancement").

Managers will fight for status quo, its their only thing. If you can not resolve conflict with the manager, quitting is the only right answer.

Or you go to their manager and to your HR department. Good companies provide more than one escalation path.

> Or you go to their manager

From the managers manager perspective its too much work to oversee people at 2 levels. If the manager gets the job done, that idle for him/her.

In my experience HR department always sides with the most people who have most power. This is not surprising, they don't have any direct contribution and have much less power.

how do they work ?

is it human feel driven (through months of meetings, observing initiative, quality of conversation) or quantitative (throughput, commit count, bug count) ?

Quite enjoyed this post and the one in https://defmacro.substack.com/p/how-to-get-promoted (HN thread on it: https://news.ycombinator.com/item?id=24618707).

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.

You might enjoy the writings if Michael: https://michaelochurch.wordpress.com/2020/03/06/techxit-part...

Thanks for the suggestion! I'm quite familiar with his writings for some years now. :)

Alternative theory:

There are people with money/power, their primary skill is knowing how power/money works and knowing other people who also have this skill.

There are regular people, their skill is learning to do whatever people with power/money decide is important.

The reason managers get to decide salaries, who gets promoted, etc, is because managers mimic the power/money class, engineers mimic regular people.

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.

It's really all incredibly boring because regular people who graduate to money/power, quickly adopt money/power beliefs and the cycle continues.

(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.

The problem is that humans come in a lot of varieties, all assembled slightly differently, and without a service manual.

Diseases also come in unpredictable variants, and tend to develop in unique enough ways.

So no, surgeons don't polish a single canonical scalpel dance that works for everyone; they have to custom-tailor the surgery to every incoming patient, often under pretty severe deadlines (literally).

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.

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.

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.

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.

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.

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.

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.

Google has TLMs (tech lead + manager). It doesn't force parallel tracks.

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 https://www.hrps.org/resources/people-strategy-journal/fall2...

> many of them ran the machines themselves, but there came a time when they've traded their role as craftsmen for the management track

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.

Program Manager - Project Manager - Product Manager - Architect

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?

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.

Why do managers spend 70% of their time on mysterious external meetings? What are they actually doing?

pointing at charts and reciting acronyms

> Why do managers spend 70% of their time on mysterious external meetings? What are they actually doing?

usually they're either trying to get there team politically important work or to get out of politically unimportant work. If things have gone really wrong in some it's time spent not getting stuck with whatever giant sack of shit is rolling downhill at that moment.

I can only speak for myself, but the meetings that previously seemed mysterious when I was an IC, are those around organisational objectives, resourcing, budgets, supplier management, alignment with other departments (Product, DCO, Infosec, Legal), catchups with my direct reports, technology department objectives etc.

I would love to see everyone answering to a manager present at his performance review. Even if it is just that some are worthy of a standing ovation.

Its a good read. The author suggested that maybe its time for change, which makes me curious about what new model does he/she have in mind.

Author here. I'm not entirely sure, I'll try to work it out. One thing I am sure of is that we need to get rid of the professional engineering management class. It's a parasitic institution.

Let's be real here for a moment. Software engineering, in general, is the most thing-oriented profession available. It attracts people who are incredibly thing-oriented. Most lack the want or ability to manage other people. This double track is specifically to give prestige to people who are amazing engineer but also can't look strangers in the eye.

Linus is as aspy of a nerd as it gets, and he did fine. You don’t need the thing you think you need.

To be honest, he did fine given the context, but Linus had some issues that would have quickly jeopardized his managing career in almost any companies.

That's a problem with the companies not with Linus.

In recent years, even Linus realised that it was a problem with Linus and took steps to fix it.

There's no way in hell any of us would be ok with our managers treating us the same way Linus treated other engineers. It worked because he's a genius and he controls the Linux project. You had to play by his rules or not at all. Google doesn't have the same advantage - it's not the only game in town.

I do not think this is true at most big companies. I have had plenty of managers who are as disagreeable as Linus. At least Linus is usually correct, not true of many managers who no longer understand the technical details.

I am not intimately familiar with Linus beyond his product Linux and his famous rants, so I can only grant you his aspy-ness.

I think Linus's handling of the Linux kernel is an excellent example of stellar technical leadership in a parallel track. It is what technical companies should look like. Engineers do their thing without worrying about administrative tasks like HR bullshit, salary negotiations, hiring, firing, and fights over who makes the coffee.

To be fair, the majority (vast majority?) of people who get paid to work on the kernel do in fact have to endure HR bullshit, salary negotiations, etc.; they're just doing it with Intel HR or Qualcomm HR rather than Linux Foundation HR.

Managing a team is not easy and it requires skills that are not automatically found among people who are good at engineering.

At the same time, a lot of managers (more than half in my book) are bad at managing people.

Most engineers are bad at engineering too. That's just the natural distribution of all professions. Managers are not special, their incompetence is just felt more directly and viscerally.

that is definitely something I have felt in the past (as an engineer having to deal with parasitic managers)

I have since found that like there are good and bad engineers, you can have good and bad managers.

I now find myself thinking about management as if it were the command chain in an army, and I would be hard pressed to imagine how an army composed of a general and thousands of privates, with no layers in between, would ever be able to accomplish anything.

You don't abolish the chain of command. You abolish management as a separate organization with its own incentives. For example, Linus is a leader but he is not a manager. In engineering this is what you want.

The only way it changes is if someone gains enough power to make the change. And almost by construction engineers do not have that power. So it would take an exceptionally self-less manager. I Or else an engineer who agrees who by luck or skill gains extraordinary power, implements this new power structure, and achieves such astonishing success with it that firm owners have no choice but to take notice and demand similar reforms at their firms. Or some third way I'm not seeing.

A.k.a. nothing like what the blog envisions is likely to happen.

That would imply that the balance of power never shifts, which clearly isn't true over the long term.

Assuming the structure produces better products and better incentivizes the team, it should have a competitive advantage. Build a startup based on similar management principles. If multiple startups attempt it, a few may succeed and serve as an example to follow.

How about if an engineer founds a startup and dictates that this is how it'll be done there, and the startup ends up succeeding? That would fit your second scenario: "an engineer who agrees who by luck or skill gains extraordinary power, implements this new power structure". I think we have seen cases of engineer founders who were in a position to do that kind of thing.

The blog post links to a story about Larry Page "firing" all the project managers; while they didn't exit the company, they were moved to another organization, and it seems Page got his wish of "no managers" in his organization for some time, until there were problems and complaints and "eventually" they started hiring more managers. If he had a fully workable approach in mind, it seems he could have implemented it for long enough to demonstrate its success.

> How about if an engineer founds a startup and dictates that this is how it'll be done there, and the startup ends up succeeding? That would fit your second scenario: "an engineer who agrees who by luck or skill gains extraordinary power, implements this new power structure".

Yes, arguably this is how we got to the current state of affairs, particularly thanks to Larry and Sergey, and the cross pollination and following-on of their approach. What I question is the likelihood of someone with this viewpoint reaching that level of power.

what do you think about rotating regularly between management and IC work? I'm thinking of Charity Major's concept of an Engineer/Manager Pendulum, specifically: https://charity.wtf/2017/05/11/the-engineer-manager-pendulum...

Would have to test it and see how it works, but this (or something like it) is my favorite solution so far.

I would say the top business leadership is to blame. The CEOs for example. They permit the engineering management class to be mediocre-performing parasites, they don't really understand how to measure their performance or the performance of the teams under them.

It's the cluelessness of the top management that enables this horrible principle/agent problem. It's as if you had a stock broker who would give you reports every month about how well he's doing, but you aren't capable of understanding whether your assets are increasing or decreasing, and you don't know how to add up the numbers for yourself or care to learn how. And it's their own fault for, in tech organizations, not caring enough to be taught how to manage their managers better.

Note: it may even be that some things are difficult to measure, but I don't see even a reasonable attempt to vet the engineering management class.

Another note: I'm not sure top leadership looks for any qualities in "management" other than "seems like someone with a rough attitude that will push people hard", even if they're pushing people hard without knowing what the people are even doing. It's a "whip-holder" role rather than any kind of attempt to make work more efficient.

I’ve been a manager for 2yrs and it’s awful. I could go back to IC work but I’m OK at best.

Reply on news.ycombinator.com