I’m confused what kind of software engineer jobs there are that don’t involve meeting with people, “aligning expectations”, getting consensus, making slides/decks to communicate that, thinking about market positioning, etc?

If you weren’t doing much of that before, I struggled to think of how you were doing much engineering at all, save some more niche extremely technical roles where many of those questions were already answered, but even still, I should expect you’re having those kinds of discussions, just more efficiently and with other engineers.

> I’m confused what kind of software engineer jobs there are that don’t involve meeting with people, “aligning expectations”, getting consensus, making slides/decks to communicate that, thinking about market positioning, etc?

The vast majority of software engineers in the world. The most widespread management culture is that where a team's manager is the interface towards the rest of the organization and the engineers themselves don't do any alignment/consensus/business thinking, which is the manager's exclusive job.

I used to work like that and I loved it. My managers were decent and they allowed me to focus on my technical skills. Then, due to those technical skills I'd acquired, I somehow got hired at Google, stayed there nearly a decade but hated all the OKR crap, perf and the continuous self-promotion I was obliged to do.

It seems that to some number of folks, "engineering" means "writing code."

> I’m confused what kind of software engineer jobs there are that don’t involve meeting with people, “aligning expectations”, getting consensus, making slides/decks to communicate that, thinking about market positioning, etc?

I'd suspect the kind that's going away.

In my case

* meeting with people, yes, on calls, on chats, sometimes even on phone

* “aligning expectations”, yes, because of the next point

* getting consensus, yes, inevitably or how else do we decide what to do and how to do it?

* making slides/decks to communicate that, not anymore, but this is a specific tool of the job, like programming in Java vs in Python.

* thinking about market positioning, no, but this is what only a few people in an organization have agency on.

* etc? Yes, for example don't piss off other people, help custumers using the product, identify new functionalities that could help us deliver a better product, prioritize them and then back to getting consensus.

In a lot of larger organizations there is a whole stable of people whose job is to keep stakeholders and programmers from ever having to talk to each other. This was considered a best practice a quarter-century ago ("Office Space" makes fun of it), and in retrospect I concede it sometimes had a point.

Ime a team or project lead does that and the rest of the engineers maybe do that on a smaller scale but mostly implement.

Well that’s why AI will not replace the software engineer!