Hacker News new | ask | show | jobs
by ditonal 976 days ago
Silicon Valley used to have engineering managers who managed engineering.

As the money got bigger we got more grifters / professional manager types. First thing they do is rebrand middle management as “leaders” and the other thing they do is make management non technical.

This has even bled into making higher level IC engineering roles being “above” coding. “Staff engineers don’t code, they set high level architecture “.

This is toxic to an engineering org in many ways. Firstly you now have a bunch of highly paid technical employees completely removed from how things actually work. But what’s worse is you created a culture where you’re incentived to follow - a senior engineer who wants to get promoted should write less code because coding is associated with being a low level employee.

The fundamental root cause is a misunderstanding of code as low level factory work and not intrinsically tied to the design and architecture. But it’s one of many ways in which traditional business structures and software engineering do not mesh and you need an extremely strong engineering leader to keep software culture on track, which very few organizations have.

11 comments

> As the money got bigger we got more grifters / professional manager types.

That. Same for all the decorative functions with low value added.

> make management non technical

This is a big flag to me. I know this is a devisive opinion, but I don't think you can do a good job at managing people without knowing their core business.

> making higher level IC engineering roles being “above” coding.

There is little that revolts me more than people working in technical companies, and seeing themselves as above the technical layer. I don't mind people not being software engineers, a lot of them are great, willing to learn a bit of context in order to do their job efficiently and facilitate mine. The same way I learn about the other functions. But I've worked with quite a number of managers, PMs and TPMs who talk down to me the moment I tell something even remotely technical, like I'm some sort of amateurish geek only tolerated at the adult's table. I do my best to stay away from these folks.

MBAs succeeded in making management a distinct discipline that has been divorced from the work, only connected through metrics and KPIs. If you cannot talk to them on their terms, they are happy to impose sanctions on you.

They’re very effective at solving first order optimization problems. Increasing revenue and reducing costs can all be done in a spreadsheet. This is the value they contribute.

If you’re dealing with problems that are closely coupled, are non-linear, or have emergent phenomena, their contributions are not just ineffective, they’re counterproductive and destructive. You need creative, skeptical, and technical people for these problems. Closing feedback loops and building fault trees help you more than a Gantt chart and flashy buzzwords.

>> make management non technical

> This is a big flag to me. I know this is a devisive opinion, but I don't think you can do a good job at managing people without knowing their core business.

I have mixed feelings about this.

I used to have a manager (who later became vp) that was technical, and it’s been the worst. Of my professional life so far. He would dictate the technical solution and shut down every initiative, making people below him mere executioners. No room for dissent, he had the last word on everything.

The problem being, this person worked for like ~5 years as a developer, then became a manager, then got in charge of infrastructure.

And oh boy, infrastructure was not his core competency.

So prod infrastructure was essentially at a hobbyist level (everything in the same subnet, some dev stuff along with prod stuff, no network segmentation, a number of things implicitly relied on virtual machines not being rebooted or getting the same ipv4 if rebooted, dns was a patchwork etc). In all this he avoided solutions that he wouldn’t understand (no matter if people below him would understand them). Oh and he would have the console access to cloud services and the authority to do all the testing he wanted, we did not (hence perpetuating some thoroughly artificial knowledge gap).

So yeah… having a technical manager can be awful.

GP: "This is a big flag to me. I know this is a devisive opinion, but I don't think you can do a good job at managing people without knowing their core business."

You: "And oh boy, infrastructure was not his core competency."

> But I've worked with quite a number of managers, PMs and TPMs who talk down to me the moment I tell something even remotely technical, like I'm some sort of amateurish geek only tolerated at the adult's table.

You're working with the wrong people.

Problem is, there are many many wrong people on management positions out there.
I'm a terrible judge of character, that's for sure
Wow. You've also just described oil and gas Operator engineering departments perfectly. It's got to the point in oil and gas operating companies, where even the simplest piece of technical work is outsourced, and even if you wanted to produce quality engineering deliverables yourself, it's hard to hunt down someone who is willing to review and sign them off because so few have that competency themselves. Of course nobody admits to that, so they're just slippery and try to reassign or deprioritise any work that involves actually doing a calculation.
I moved over to Silicon Valley fairly late (in 2018), and I was immediately shocked at how frowned upon... even disincentivized technical knowledge was at the management level.

To the extent that people started removing hard numbers from their presentations and replacing them with smiley faces.

Needless to say, I left and that company TANKED.

I think Steve Jobs said something about A people versus C people... well he was right (even though he was bullshitting, b/c as we all know, Wozniak had the A team at Apple, and Jobs at the C team)

Curious, can you expand on your jobs vs woz take. My impression is they were both A players with entirely different competencies
A teams will crush A people every day and twice on Sundays. The lone wolf 10x dev myth needs to die. This is not 1994.
The A/B/C quote isn't about lone wolf devs, but is "A players hire A players, B players hire C players". Meaning really good devs want to work with other really good devs, but mediocre devs want to work with crappy devs to make themselves look better.

I still think it is kind of full of bunk, although it has some truth. A players do typically want to work with A players, but a lot of "B" players just want to have a mildly interesting job where they don't kill themselves and are happy to hire and be around other B players with the same attitude.

I've worked in software and I've flown jets off an aircraft carrier. Egos are not an unfamiliar concept. And while there are "A" players, there are also arrogant prima donnas who think they're "A" players, which is why I'm skeptical of sentences like this.

In my previous life, there were plenty of people who could water your eyes in the jet, but who couldn't mentor or bring along new folks to save their lives. Which made them useless in the long term because they couldn't train their replacement.

The real gold are the "A" players who can mentor "B" players into becoming "A" players. Because in any field, there are three kinds of people. The natural freaks of nature who need no help, the vast middle, and the incompetent who shouldn't be there. Organizations who crush it understand that they need the best team players out of Group 1 to mentor the crap out of as much of Group 2 as they can, and they only need to fire Group 3. But the prima donnas of Group 1 make it sound like they can carry an organization . . . and they largely can't.

I don't think "we all know" that.
I think it's well-understood Jobs as an S-tier salesperson.
This is how you get the Office Space "I have eight different bosses" environment. And they all play "hide the problem, fluff the status" games so the leaders above++ have no idea how big of a shit show the ground level is.
> As the money got bigger we got more grifters / professional manager types. First thing they do is rebrand middle management as “leaders” and the other thing they do is make management non technical.

God I hate this, having to attend all of these "brown bag" meetings where we get talked down to by these grifter types about "devops mentality" or whatever or BS they've latched onto

Who gave these people the right to wave their hands in the air and talk about bullshit all day? Where do these people come from? Is it nepotism or something?

To be frank, I'd rather trade some money to never have to interact with these fuckers ever again. They're literally a disease. Or at least, unionize, but don't demand money, demand that these people shut the fuck up, permanently, or gtfo

This is true for every tech company outside of Silicon Valley as well.

I doubt the process is even specific to tech companies. Code is work, and the one thing that signals moving up the social ladder is not having to work. That has been true for a large part of history.

Programming is often a bit of a special case when in the context of work because we it so completely isolated from the physical process of work. Programming fundamentally is describing processes at multiple abstraction levels all at once, and therefore inseparable from software architecture. This is also why it can be hard to humans to learn.

(This, incidentally, is also why I despise each and every one using the term automation in a programming context. Running a command and clicking a web interface is conceptually identical, one is not more automated than the other.)

Fantastic comment. Btw the same dynamic also exists in other areas such as other engineering disciplines, finance, etc, as Im told. Software was probably an outlier until people realized you could make a good career out of it
Well with size comes management. Management of money and architecture.

I am also not a particular fan of excessive management structure, but as an architect I have to completely reject your proposition that non-coding roles are toxic or excess. I work with highly brilliant minds, with coding and non coding architects and one thing is very clear: the non coding architects are contribute more value to the end product than the coding principle engineers. And why not: they are a specialization which focus on one part of the engineering while a traditional coder focuses on another part.

> I have to completely reject your proposition that non-coding roles are toxic or excess. I work with highly brilliant minds, with coding and non coding architects and one thing is very clear: the non coding architects are contribute more value to the end product than the coding principle engineers.

I reject your rejection. In my experience any architect/staff/whatever high level ivory tower guy worth anything will look for every technical opportunity they can and will often bemoan the fact that at their level most of their day involves meetings and powerpoint when they'd really like to be digging into the code.

If a sr. technical leadership position seems happy to have their day full of PowerPoints and committee meetings the most they are ever going to contribute to their field is an amusing/horrifying story on TheDailyWTF.

I think you're right on the money, with a single exception: there is a value to engineering managers being trained in professional management skills.

Honestly, most of the dysfunction I see in orgs is as a result of "senior" (read: tenured, not skilled) engineers being put in charge of teams/work without having the competencies needed to be successful.

On the other hand, manager writing production code is a terrible footgun for the team. Time/resource conflict between helping a team and shipping code has no good outcome, either I let team down by decrease their productivity, or I let team down by slacking behind.
There is this new role called TLM that combines being a manager and a tech lead. Not sure how that is supposed to work at all.
What I saw is that role isn't working either way. TLM don't have manager's power (can't reward and cannot punish) and at the same time expected to churn out production code, carving continuous focus hours out of manager's schedule.
Thank you! I’ve been thinking this for a while but hadn’t quite found the right way to articulate it.