I have a long held belief that engineering managers are mostly a scam, and are actually just overpaid scrum masters. This is from working at some top companies
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.
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.
You're working with the wrong people.
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.
> 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.
You: "And oh boy, infrastructure was not his core competency."
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)
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.
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 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 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.
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
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.)
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.
A good engineering manager shouldn't be there to herd engineers. A good engineering manager is there to protect their engineers from the organization, ensure they have the resources required to do the work, and to make sure their organizational goals, development, and wellbeing are being advocated and cared for. Scrum masters shouldn't care about that. Managers should.
In work, always selectively take time off when it's somewhat important. So your skills aren't taken as the norm.
-Complete technical tasks at the minimum of a senior engineer level if not staff/principal
-Train the <senior engineers on a weekly basis
-Project Management
-System Design, to the point that I am willing to put my name on each and every design as the architect
-Understand all the projects my team owns to the level that I can answer extremely explicit technical questions from other teams line engineers immediately in that meeting and not need to refer to my team's expertise
-Be on call 24/7. This isn't asked explicitly, but I am told that I need to be available to support my team for every on call event, which funnily enough means I cover 100% of the on 24/7 call schedule my team has
-People Management
-Employee growth
-Vendor Management
-more I am probably forgetting
I am not super incensed about this because the total comp has kept increasing as the expectations grow, but I am now 3 jobs in a row with companies expecting this combination of perfect high level engineer and perfect MBA accredited business leader in one role. If you have engineering managers that legitimately seem like overpaid scrum masters you should probably look to join a more mature software company.
Also if you're at a FAANG or close to FAANG startup and still feel this way, odds are that you have no idea what goes into 90% of running a team in an well running business and think that the company is making bad decisions because they don't dump 90% of their revenue into feature development instead of stupid choices like fulfilling government mandated regulation.
Edit: Also I've worked on teams with Scrum Masters. Its been more than 7 years since I last came across someone with that title. My Scrum Master equivalent planned tasks equate to less than 6 man hours total a week and 5 of that is the standup set for 15 minutes for 4 engineers a day that we normally end 5 minutes in
IMO, my modus operandi as an engineering manager is to body all the work that I can handle for a team that lets the team stay focused on the engineering work and be more productive.
With tens of billions in the bank, who will be dancing on the graves of highly effective startups
Which is why people still work for "bad" companies
Most come from non technical backgrounds, or we're in a technical role for a short time.
That’s mgmt for you
My manager filters my email. And tells me what the new priority is.
Two levels up is a director. Above that is a department head. Out of 100 people there are about six that truly build, ship, accelerate the goal arrival.
The rest of us make waves allowing the divers to have a soft landing.
2.) Be even better at leetcode.
3.) Interview during a downturn, when everybody's stock is in the toilet and all the companies that are about to go bankrupt aren't hiring.
4.) Get multiple competing offers.
5.) Play them off against each other. Turn them down if you have to.
6.) Get as much stock as you can in the counteroffer.
7.) Wait for the upturn, where the company's stock goes parabolic.
8.) Profit.
#3 and #7 are the most important. Timing and luck are better than skill. But you usually need #1 and #2 to accomplish #4 during #3, and you need #4/5 to get #6, which is what really makes you the big bucks in #7.
What are the JDs of "Engineer Managers" ? And what are their REAL responsibilities.
Their responsibilities are basically improve and maintain the performance of whoever they "manage" . But for some reason we decided that shitty engineers that decided they dont want do do development are the ones looking for management positions. And they get good at playing the politics game.
My wife works in a non tech position and had a manager, who studied for people management and understand in the long term what makes people perform (hint, it's not keeping them sad, overworked and getting all the shit politics).
Good managers filter the shit from you. Push back on stupid deadlines and double drippings, and act on your needs as a person.
And they may not know shit about the technical side of things, but they trust you do your job.
I think Industrial Engineers with some specialization in people management make the best managers for Software Dev.
I don't think feedback in a corporate setting from someone you have power over can be relied on.
Just like home inspectors...failed contractors
For some reason I can only find the heavy workload manager jobs. It’s different work than being an IC (I’ve gone back and forth) but I wouldn’t call being a manager easier.
I have worked at orgs that have chains of middle managers. Each one of them asking for updates on the same shit.
My manager filters my email. And tells me what the new priority is.
Two levels up is a director. Above that is a department head. Out of 100 people there are about six that truly build, ship, accelerate the goal arrival.
The rest of us make waves allowing the divers to have a soft landing.