In the end, engineering management basically requires you to counter-balance whichever of the four pillars your team needs most: Product, Process, People, and Programming.
- Too few people? You'll work on scope to make the deliverables meet reality. Since there's not much communication overhead, you'll be able to program.
- No PM? You now own the product pillar entirely. This takes a lot of your time: You'll need to validate features, prioritize the roadmap, and even talk directly with clients. None of the rest matters if your team is shipping features with no user value.
- Too many people in the team/company? Say goodbye to programming. You'll be responsible for careers, making everyone work cohesively, and navigating the org to get the right resources and support for your team.
- Reporting close to the CEO? You'll handle the bridge between sales, operations, client communications, and other functions.
The common thread is that your focus constantly shifts based on where your team's bottlenecks are. The key is identifying which pillar needs attention and adapting accordingly.
I always told people I’d plunge the toilets myself if they were preventing the staff from working. I feel like the closer you get to top leadership the more your job becomes identifying and executing on whatever is highest value that you have the skills for.
There's a hidden assumption there though, that you CAN actually do that. At least management skills mostly stick over time but even a year away from hands on technical work is going to leave you likely stranded and unable to execute on the technical aspects. Which is why I continue to push back against suggestions technical managers shouldn't be engaged hands on. Apart from being incredibly hostile to their own interests (it will be central to you getting hired to any future role), it also impairs one of the most strategic aspects of the role which can drastically affect the value you can deliver internally in the future as well.
This is a lot closer to a literal interpretation of "shit rolls downhill, so a good manager will be a shit umbrella to protect their team" than I thought I'd ever see.
Leadership is timeless, humans have always organized themselves in groups with leaders, and we instinctively play the part of leader or follower according to the situation. Being a good leader just means allowing the group to accomplish something that would be less likely without one's guidance. Being a good follower is mostly a selection role, where one exercises judgement in choosing a leader to follow.
The mechanism for dealing with bad leaders has also changed relatively little: stop giving them your own resources, and put distance between you and them. In the workplace this is asking to switch to another team. You can dress it up with fake reasons, like you are interested in another project, or you aren't learning enough, whatever. The important thing is that it takes a resource (you) away from a bad leader and gives it to a better one. Iterate this process enough, and the incompetent leaders are outed through their inability to maintain personnel.
People don't do this enough, it's an easy way to signal to upper leadership who in management is bad at their job, without a direct accusation.
The fad is non-technical management, and the result is a general crisis in leadership that you can see everywhere across tech, politics, entertainment, whatever. Top leadership is out of ideas and just looking around for others to copy, or cruising on extraction/exploitation of value-creation that came before. It's a slow-motion disaster that's been picking up speed, which is why consumers, workers, and constituents are all pissed off. Seems like the shareholders will be effected soon, so then maybe it starts to change.
With companies at least there is direct feedback via company performance - companies led by people who know what they are doing do better than those that aren't.
And well led companies tend to attract and retain more talent.
The feedback in politics is much much slower - in part because often the people you are voting for are not really the people setting policy - that's all done by the party machine ( 20 somethings with no real world experience working as advisors ) - so changing the 'leader' often doesn't make much of a difference.
ie one of the things that is really annoying the electorate is it's really difficult to actually vote in leaders or policies you want because of the way the party system works - leaders change yet everything stays the same.
I mean in the US - who really though Kamala was the best candidate to run against Trump?
My suspicion about why this is the case is rooted in the responsibilities engineering shares with product and design at the management level. In an environment where very little unilateral decision making can be made by an EM, it is difficult to know if an outcome is because the EM is doing well or because of the people around them. I could be wrong, but once you look high enough in the org chart to no longer see trios, this problem recedes.
The author really got me thinking about the timeless aspects of the role underlying fads. I have certainly noticed shifts in management practice at companies over my career, but I choose to believe the underlying philosophy is timeless, like the relationship between day to day software engineering and computer science.
I worry about the future of the EM discipline. Every decade or so, it seems like there is a push to eliminate the function altogether, and no one can agree on the skillset. And yet like junior engineers, this should be the function that grows future leadership. I don't understand why there is so much disdain for it.
In my younger years, I was very cavalier about my approach to programming even at a larger company. I didn't particularly want to understand why I had to jump through so many hoops to access a production database to fix a problem or why there were so many steps to deploy to production.
Now that I more experienced, I fully understand all of those guardrails and as a manager my focus is on streamlining those guardrails as much as possible to get maximum benefit with minimum negative impact to the team solving problems.
But this involves a lot of process automation and tooling.
What if teams were integrated groups of engineers, designers, and product people, managed by polymaths with at least some skill in all of these areas. In this case, do you think it would be easier to evaluate the team’s (and thus the manager’s) performance and then higher levels of management would care less about processes and management philosophy?
I tend to believe in this model because when I've seen it in action, bad GMs are quickly identified and replaced for the betterment of the project.
It can be challenging to implement for a few reasons.
- It is difficult for a GM to performance manage across all disciplines. This model works best when you aren't interested in talent development.
- It's bad for functional consistency. GMs are focused on their own outcomes and can make the "ship your org chart" problem worse. It requires strong functional gatekeepers as a second-order discipline.
I do. It’s often done by people that become tyrants over their little fiefdom.
If a bunch of crap code gets shipped, it isn't always because the engineers are bad. Often it's because they were given a bad deadline. Same with EMs.
> Leadership is the process of influencing people by providing purpose, direction, and motivation to accomplish the mission and improve the organization.
taken from -
if we are to learn anything from the US military, it is twofold
1. You can absolutely create a self-reproducing tradition of absolute conformity while retaining ample capacity for local decisionmaking, if you have enough money and time. (In the case of the US army, approximately 150 years, and more money than any other organization in the history of man)
2. Segregating the staff into "officers" and "enlisted" is still gonna get a lot of "officers" killed dead, and even more "objectives" un-taken, because it spreads their incentives too far apart.
Software has something, which no engineering discipline has. Encapsulation. If you are building a car, a plane or a train everything affects everything. Management exists, for the sole reason of creating anything in such a world. What the corporation wants from an engineering manager, is someone who solves that communication problem, what the engineer wants from his manager is someone who figures out what is happening in the rest of the organization.
In other engineering disciplines, a lot of work goes into preventing everything from affecting everything. You overbuild a bridge so that you don't have to consider oscillation magnitudes (other than to conservatively figure out the maximum you need to support, and that maximum will be a worst case specifically so you don't need to consider the interaction of everything else.) Any time you're adding a safety margin, you're removing from consideration all of the things that could go wrong but not wrong enough to exceed the margin.
Within and outside the organization.
A "good" manager during a time of mass recruiting uses a very different skillset to a good manager during times of mass layoffs.
I suspect we won't really know what a good manager in the era of AI tools looks like for another 5 years or more.
Knowing what these goals are, is just as difficult or even harder, than achieving those goals. Most of these goals are not the ones that are written in big font.
I also completely disagree with you. I’ve watched people scream at a room until they got their way. It was awful.
this guy didn't write a blog post, he wrote the preface material for a training module to be sold to the least-competent HR execs he can find
it is generally a bad sign when you set out to taxonomize all possible productive behaviors. in this case, possibly a worse sign is that this guy has two "clusters" making up eight "foundational skills." for perspective, when Immanuel Kant set out to taxonomize all possible human experiences, he came back with four "clusters" of four "skills"
apparently engineering management encompasses the same complexity as half of all possible human experiences, from tabula rasa. good to know, i guess
(perhaps obviously, i did not read the essay any further than the introduction of "eight foundational skills" in "two clusters." at that point clearly I am being sold nonsense, and I feel free to stop reading and just poke fun at the author instead.)
Institutional rhetoric at high levels is always meant to manipulate labor markets, financial markets, popular opinion. This is basic worldly-wisdom. The question is how does one (who is not at a high level) survive the recurring institutional changes? There seem to be two approaches to an answer: Do one's professional best regardless of change, or try to anticipate changes and adjust with the wind. For the first, gods may bless you, but it is folly to think your bosses will respect you. For the second -- good luck, you're running with bulls. Either way, the pill to swallow is that most employees including managers are grist to the mill.
Businesses exist to make money. If you want a commune instead, join one!
Many workers primarily work towards helping the boss grow their head count, or helping the middle-manager with their emotional state.
A lot of the bad behavior in corporate America comes from signalling (for above) and posturing (for below), not from finding ways to make money
(Communes often have the same signalling and posturing problems, but they don't have to additionally worry about shareholders and bonus payments)
Is this everyone's experience nowadays? Personally I haven't experienced such a big shift at all.
Our C-suite is irrationally pushing AI-everything and eng culture is suffering a bit from not fully figuring out how to integrate new tooling safely, but nothing as fundamental as the mentioned changes are taking place so far.
Basically, in addition to the irrational AI-everything initiatives in spite of customers not wanting or using those features, as an engineer I’m being asked to basically run my own business unit doing everything from user interviews to product/design, engineering, QA, support, and reporting. There are no EMs anymore, everyone reports to the founders.
I think the author’s post could be boiled down to: in the ZIRP era the engineers had leverage and were treated well, and in the post-ZIRP era the tech companies have the leverage and are squeezing everything they can out of engineers to the point where you’re basically doing the job of a founder within someone else’s startup.
Like the comment you're replying to, I've also have NOT experienced this shift in EM skills. In my experience, they are still about making the team happy and productive, and definitely NOT coding or designing software (though I'll concede most seem technically minded and understand the details well enough to ask relevant questions and push back against bad takes).
But coding? Nope. EMs are still about the team, careers, hiring, alignment, etc.
C-levels forcing AI on everything, whether it makes sense or not, is definitely a symptom of the times.
The author then postulates some guidance for how to survive in organisations more generally, working above these strange social structures largely unique to silicon valley. It wasn't the purpose of the article, but I wish he was a bit more critical of these structures in general.
Did you read the title of that post and not the actual content? Because it's a fantastic insider's war story about one of the most infamous product launches in our industry's history.
Here's the conclusion, which you can count as justification if you like but seems like a very interesting piece of insight to me:
> Digg V4 is sometimes referenced as an example of a catastrophic launch, with an implied lesson that we shouldn’t have launched it. At one point, I used to agree, but these days I think we made the right decision to launch. Our traffic was significantly down, we were losing a bunch of money each month, we had recently raised money and knew we couldn’t easily raise more. If we’d had the choice between launching something great and something awful, we’d have preferred to launch something great, but instead we had the choice of taking one last swing or turning in our bat quietly.
> I’m glad we took the last swing; proud we survived the rough launch.
> On the other hand, I’m still shocked that we were so reckless in the launch itself. I remember the meeting where we decided to go ahead with the launch, with Mike vigorously protesting. To the best of my recollection, I remained silent. I hope that I grew from the experience, because even now I’m uncertain how such a talented group put on that display of fuckery.
I can't imagine how reading that could make you think they were less rather than more credible as a source of information on engineering management!
So who is supposed to do it? Because executives sure aren’t.
Personally, I find a lot of appeal in having the expertise and influence to be more than a small cog, even when working as a generic staff engineer at the leaf level of my organization. I don't think there are many professions where that is possible, or at least nowhere where that degree of influence is near as feasible (apocryphal stories about janitors coming up with the next breakthrough product notwithstanding).
