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.
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.
Only to the extent that a happy team delivers something of value. Teams can be happy doing things that will drive the company bankrupt. there is only so much unhappiness they can stand
If value can only be delivered by making a group of people miserable then maybe the definition of "value" is fundamentally wrong, like it was/is in the case of slavery.
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.
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.
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.
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 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.
Right, implementation od policy is equal to policy itself. If an org draws up a policy of maximized productivity with minimal staff, good is preventing turnover.
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?
I've been thinking lately a lot about this. What is it I do when I want to convince someone of something (i.e. "creating alignment" in corporate speak)? I listen to them, am empathic, ask meaningful questions etc. Afterwards, that opens a space for me to make a proposal that is well-received.
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??
Presumably you're talking about this - https://lethain.com/digg-v4/ - "Digg's v4 launch: an optimism born of necessity"
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!
> 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.
It's generally a symbiotic relationship though, as the workers grow their own resume while helping their boss grow theirs (and generally the boss is growing his own while helping his boss grow theirs and so on. Sometimes it goes all the way up where even the founder just wants that lifestyle subsidized by investor money and does not care to actually ever build a profitable product).
This kind of perverse incentive comes up when the rank and file has no meaningful way to profit off the company's success, and so it instead becomes more profitable (in future profits from the inflated resume, or kickbacks/favors from vendors, etc) to act against the company. Just like in security bug bounties, companies should reward their employees more than an external malicious actor would, otherwise they will choose the rational option.
Really sharp reasoning. This can be reversed to define an extra ordinary manager: don't care about your head count and just be a fucking grown up who's emotional state does not depend on his team's performance. IMHO this results in having a high head count and a team performing pretty well. Kinda stoic wisdom. Go and figure...
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.
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.
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.
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 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.
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.
Sometimes the real deliverable is a happy team
Only to the extent that a happy team delivers something of value. Teams can be happy doing things that will drive the company bankrupt. there is only so much unhappiness they can stand
If value can only be delivered by making a group of people miserable then maybe the definition of "value" is fundamentally wrong, like it was/is in the case of slavery.
Why misrepresent what someone else said to make your point?
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.
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.
taken from -
-- https://www.eiu.edu/armyrotc/docs/adp6_22.pdf
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.
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 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.
> whatever counts for good has to be contextualized within the culture and habits of the organization
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.
Right, implementation od policy is equal to policy itself. If an org draws up a policy of maximized productivity with minimal staff, good is preventing turnover.
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?
The article is giving me PTSD.
The job of EM is to be accountable for a team (or teams) which deliver(s) software. A software engineer’s job is to develop software.
Every skill eventually boils down to empathy, alignment is just being empathic
I've been thinking lately a lot about this. What is it I do when I want to convince someone of something (i.e. "creating alignment" in corporate speak)? I listen to them, am empathic, ask meaningful questions etc. Afterwards, that opens a space for me to make a proposal that is well-received.
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??
Presumably you're talking about this - https://lethain.com/digg-v4/ - "Digg's v4 launch: an optimism born of necessity"
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!
This really taints the article for me. Maybe I should evaluate the article on its own merits or whatever, but to justify the Digg fiasco...
> 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.
> 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!
For many workers, working towards the goal of making the company profitable would be an improvement.
Many workers primarily work towards helping the boss grow their head count, or helping the middle-manager with their emotional state.
It's generally a symbiotic relationship though, as the workers grow their own resume while helping their boss grow theirs (and generally the boss is growing his own while helping his boss grow theirs and so on. Sometimes it goes all the way up where even the founder just wants that lifestyle subsidized by investor money and does not care to actually ever build a profitable product).
This kind of perverse incentive comes up when the rank and file has no meaningful way to profit off the company's success, and so it instead becomes more profitable (in future profits from the inflated resume, or kickbacks/favors from vendors, etc) to act against the company. Just like in security bug bounties, companies should reward their employees more than an external malicious actor would, otherwise they will choose the rational option.
Really sharp reasoning. This can be reversed to define an extra ordinary manager: don't care about your head count and just be a fucking grown up who's emotional state does not depend on his team's performance. IMHO this results in having a high head count and a team performing pretty well. Kinda stoic wisdom. Go and figure...
> helping the middle-manager with their emotional state.
Hah, this is hilarious. So very "The Office".
That's not the only reason why businesses can exist. It's the most common reason in US culture, but there are other reasons and cultures.
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.
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.
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.
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.
The executives are supposed to, even if they aren't doing so.
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.