One of the most important things about great performers in any discipline is to be adaptive. This also applies to engineering managers. I think the article is correct that it identifies that fads shifted. Great people were able to both adapt to new expectations while all the while adapting their approach to individual situations and people. If you are a one-trick pony sometimes your trick is in line with fads and expectations and you will do well. Sometimes it’s not in line and you will struggle. If you are adaptive you will do well in a changing landscape.
This is a good article that is critical of narratives around behaviour within organisations. I particularly enjoyed his criticism of the 'morality tale'.
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.
> The conclusion here is clear: the industry will want different things from you as it evolves, and it will tell you that each of those shifts is because of some complex moral change, but it’s pretty much always about business realities changing. If you take any current morality tale as true, then you’re setting yourself up to be severely out of position when the industry shifts again in a few years, because “good leadership” is just a fad.
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.
I think my takeaway from this is there is no objective standard for good engineering management - whatever counts for good has to be contextualized within the culture and habits of the organization.
There is no absolute description of good leadership. But there is a relative one. It's about the degree of alignment with goals at the moment, at team level, and org level and being able to convince people about the achieved alignment.
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.
And more broadly, goals/interests/skills can align really well with company needs and priorities at a time--and then they don't. You may be able to adapt but when the whole reason you were hired basically goes away, maybe it's not a great fit any longer.
A manager’s job isn’t to guide the company, it’s to make sure his team does the tasks they are assigned. Likewise, a worker’s job isn’t to “think about the big picture” and come up with a strategy for the organization.
So who is supposed to do it? Because executives sure aren’t.
Make sure you get as far as the four core management skills and the four growth management skills, which are very clearly explained and make a ton of sense to me.
I also hear that middle management is being cut from all companies. Some kind of management is necessary though, no? Otherwise people will get misaligned an all that. I'm not sure what is the point of the article. I guess a good manager doesn't need a bullet list to be able to function so why this person is writing a new one?
This is about software and management for software. But software developers have no engineering culture, they have a craftsmanship culture, favoring things like individualism and "taste". The article pretty clearly demonstrates this, as this is not how any actual engineering organization or any actual engineer thinks about management.
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.
It isn't good leadership/management that is a fad. What is a fad is what that looks like to the C-suite and how that is measured. There is no substitute for ability no matter how many management courses or frameworks you know. What is constant is the higher-ups ignoring this and going for the latest management philosophy.
I worry a lot about fads in engineering management. Any time you proscribe process over outcomes you create performative behavior and bad incentives in any discipline. In my observation, this tends to happen in engineering because senior leaders have no idea how to evaluate EMs in a non-performative way or as a knee-jerk to some broader cultural behavior. I think this is why you see many successful, seasoned EMs become political animals over time.
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.
I read more of the author's blog posts and it's actually insane to me that he not only was involved in one of the worst product deliveries in internet history (Digg v4), but he still justifies it somehow??
The question of leadership is much larger, more general, and more timeless than the last 15 years. I invite those curious about it to look into the American Army.
> Leadership is the process of influencing people by providing purpose,
direction, and motivation to accomplish the mission and improve the
organization.
The American army, the origin of the term "fragging." (to wit, making sure your commanding officer has a close, and final, encounter with a piece of ordnance, such as a frag grenade)
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.
If you're talking about the relationship of engineering management with senior management, the most important "core skill," though I wouldn't really call it a skill, is alignment. Thing is, you won't get alignment without being closely aligned with product management, and if product management is weak, acting just as a features accountant, you're screwed no matter how good an engineering manager you are. You have no support to disagree with or shape senior management inputs. Everything else is nice and correct but not determinative the way that alignment will be.
I think there is this troika of "Leadership", "Management" and "Followship". You don't have to be an engineering manager to be a leader, and just because you are a leader doesn't mean you have any "followers". As someone who's been a team lead, a tech lead, an EM, and a C-level, I feel the goal is to hit that balance between those three. You want to embody a leader by actually being technically great, visionary, empathetic, and leading by example; but you also want to manage people and expectations; and ultimately you want people to follow you - to basically say "I love working for/with this person". Finding this triangulation is essentially what makes you timeless and relevant no matter the fad.
>Then think about our current era, that started in late 2022(...) We’ve flattened Engineering organizations where many roles that previously focused on coordination are now expected to be hands-on keyboard, working deep in the details
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.
There are components of management culture which are fads, like the idea that one could be an effective manager, while not understanding what one's reports are doing, through some management-foo learned from books and blogs.
The success of that fad is no doubt partially due to the economic climate.
People want the tech industry money, but don't have the tech industry skills.
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.
Well, I can see your point, but this assumes that engineers only care about their career and or personal relationships. But I know that many engineers care deeply about a project's success and project goals enough to endure bad leadership for very very long times, because they know from experience that the average leader is mediocre, so switching teams or companies is a gamble, and not all life situations allow people to gamble with their lives.
I've worked as an EM at four different companies, from large enterprises to small startups, and I think "the role of engineering manager" is a myth. Your role varies wildly from one company to another. In every company I've worked at, my job has never been the same:
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.
At least in small companies, my experience is that being adaptive like this applies to ICs as well as managers. Although to be fair the environment I'm thinking of doesn't have any full time managers.
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.)
27 comments
[ 5.6 ms ] story [ 33.6 ms ] threadThe 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.
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.
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.
So who is supposed to do it? Because executives sure aren’t.
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.
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.
> Leadership is the process of influencing people by providing purpose, direction, and motivation to accomplish the mission and improve the organization.
taken from -
-- https://www.eiu.edu/armyrotc/docs/adp6_22.pdf
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.
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.
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.
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.
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.)