[madrox]

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.

[brightball]

Process over Outcome is something that I think would be easy for anyone to proscribe to a process that they didn't like.

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.

[p_v_doom]

The problem imo tends to be not that there are guard rails in place. It's that they are often build by people that only care about the guard rail part and completely forget that its supposed to be last barrier and that there are other things you can do before you get people to hit a guardrail

[jaredklewis]

I like your thinking about this problem.

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?

[madrox]

You're describing the GM (general manager) model, sometimes called the single threaded leader. This does work well in large scale organizations...especially ones where teams are built around projects and outcomes but exist for a finite time. Video game development tends to have this model.

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.

[Aeolun]

> I don't understand why there is so much disdain for it.

I do. It’s often done by people that become tyrants over their little fiefdom.

[madrox]

That's usually a consequence of bad incentives. Either leadership is selecting for that kind of behavior in managers or they don't know how to properly unselect for it.

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.