[coffeefirst]

I actually don’t think the author wants to become a real manager, he wants to play a video game where he sends NPCs around to do stuff.

Real managers deal with coaching, ownership, feelings, politics, communication, consensus building, etc. The people who are good at it like setting other people up to win.

[elevatortrim]

As a manager who is trying to do all the things you listed well, I would love it to be more like a game sending NPCs around. Ignoring the macro implications of AI, even if very successful at or resistant to it, I’d think there would be very, very few people who are actively seeking people drama. Educating kids can be fun, but educating adults in the business domain is almost always a drag as in any given professional room, you would be very lucky to find one person who is genuinely there out of curiosity rather than obligation or fomo.

[coffeefirst]

Huh. Can’t speak for everyone, but big, messy cross functional problems where you need 5 different types of experts to build a shared mental model is my jam. Maybe it’s a culture thing but I rarely encounter technologists resistant to learning how other teams work.

[Avicebron]

I think you might have missed the point

> I’d think there would be very, very few people who are actively seeking people drama

Theoretically as a manager you get the bump up the power dynamic ladder (and probably pay ladder) because you are taking on the responsibility of "people drama". Being a good manager is antithetical to treating living, breathing human beings as NPCs in a game.

[xXSLAYERXx]

Do you have a different take on winning then me?

In engineering the only teams that win are the teams that ship code. Dealing with coaching, ownership, feelings, politics, etc, should all arrive at the same outcome: ship code.

[berkanunal]

Perhaps they have a different take on engineering than you.

Shipping code is not the end goal of engineering. In fact, more code you ship more liability you have. Main goal is solving problems.

> Engineering is the practice of [...] solve problems within technology, increase efficiency and productivity, and improve systems. [0]

[0] https://en.wikipedia.org/wiki/Engineering

[xXSLAYERXx]

I agree with what you're saying and I didn't mean to insinuate I believe that we should ship just for the sake of shipping. I don't. But thats not the reality I've participated in. I think about story points a lot. Whats the point? So leadership has insight into what the dev team is doing. And they can plan, based on point size, what will be shipped. Not all the time does the release include solved problems. A lot of times it is fluff that does create new liabilities. How many of us have shipped and had to maintain a feature that the customer never even wanted? I definitely have.