4 ms·
Silicon Valley used to have engineering managers who managed engineering. As the money got bigger we got more grifters / professional manager types. First thin
by ditonal 3y 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.
- charles_f 3y ago> 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.
- hx8 3y ago> 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.
- vegetablepotpie 3y agoMBAs 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.
- znpy 3y ago>> 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.
- Kbelicius 3y agoGP: "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."
- LarsDu88 3y agoI 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)
- tmn 3y agoCurious, can you expand on your jobs vs woz take. My impression is they were both A players with entirely different competencies
- marcellus23 3y agoI don't think "we all know" that.
- rib3ye 3y agoI think it's well-understood Jobs as an S-tier salesperson.
- psunavy03 3y agoA teams will crush A people every day and twice on Sundays. The lone wolf 10x dev myth needs to die. This is not 1994.
- gilbetron 3y agoThe 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.
- candiddevmike 3y agoThis 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.
- iamthemonster 3y agoWow. 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.
- oaiey 3y agoWell 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.
- gustavus 3y ago> 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.
- dilyevsky 3y agoFantastic 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
- mvncleaninst 3y ago> 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
- xorcist 3y agoThis 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.)
- null0pointer 3y agoThank you! I’ve been thinking this for a while but hadn’t quite found the right way to articulate it.
- SergeAx 3y agoOn 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.
- seanmcdirmid 3y agoThere 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.
- SergeAx 3y agoWhat 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.
- nrawe 3y agoI 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.