Single-Threaded Ownership

Why the wall between PM and EM is coming down, and what it takes to lead on both sides of it

A few years ago I sat in a sprint planning meeting where two things happened back to back. Our PM walked through a feature spec that, halfway through, my engineering lead realised was technically impossible without rewriting a service nobody had touched in two years. Twenty minutes later, an engineer asked a question about why a particular flow was designed the way it was, and the answer came from the EM, not the PM, because the EM had been the one in the customer call where it came up.

I remember thinking: the artefact passed from one side of the room to the other wasn't carrying the actual decision. The decision lived inside the heads of people who already understood both sides. The PRD, the architecture doc, the Jira ticket — they were ceremony around something that two people had already worked out over coffee.

That meeting stuck with me, because it was a small example of something I now think is the dominant story in how product and engineering teams will be led over the next five years. The boundary between Engineering Manager and Product Manager was always a coordination tax on the same underlying problem: building things people want, that actually work. AI is making that tax visible, and then expensive, and then optional.

I want to write about what I think is happening, why I think it's happening, what the honest trade-offs are, and most importantly, what skills the leaders who thrive in this world will actually need. I have opinions, and they are forming in real time. Take them as a snapshot of someone who is in the middle of figuring it out, not the finished view from the other side.

Why we split the roles in the first place

It's worth remembering that the PM/EM split is not an ancient feature of how software gets built. It hardened over the last twenty or so years, and it hardened for good reasons.

Writing code was expensive. Most of an engineer's day was spent producing it, and the cost of producing the wrong thing was very high — you could spend a quarter building a feature that turned out to be the wrong feature. So the field invented a role whose entire job was to make sure the right thing got built. That role needed to be in front of customers, in front of data, in front of the market. It couldn't also be in the code.

At the same time, managing engineers was its own discipline. Hiring, coaching, performance, technical strategy, on-call, incident response, architecture review. The list is long and most of it is invisible from outside the team. So we built another role to do that, and to translate between the customer-facing layer and the engineering reality.

The two roles produced different artefacts — PRDs and roadmaps on one side, design docs and architecture diagrams on the other — and a third class of artefact existed to glue them together: Jira tickets, sprint plans, OKRs, status updates. Those artefacts were the connective tissue. They were how a PM's understanding of "what customers need" got compressed into something an engineering team could act on, and how an engineering team's understanding of "what's actually possible this quarter" flowed back the other way.

This system worked. It worked well enough that an entire generation of careers, ladders, conferences, books, and orthodoxies grew up around it.

What changed

Three things changed at roughly the same time, and they happened to change the underlying economics that made the split necessary.

The cost of prototyping collapsed. An EM today can take a customer problem and have a working prototype in front of that customer the same afternoon. Not a mockup. A thing they can click. That used to require pulling a designer, a PM, and an engineer together for a week.

The cost of cross-domain research collapsed. A PM who didn't grow up in code can now sit down with a service they've never seen and, with help, actually read it. Not just nod through the architecture review — read it, understand it, ask sharper questions. An engineer who has never run a customer interview can be coached through one in twenty minutes by a tool that knows how to do it well.

The cost of synthesis collapsed. The PRD, the spec, the design doc, the meeting notes, the customer call transcript, the support ticket trend — all of that used to require a human to read, digest, and reconcile. The bottleneck wasn't the information. It was the time it took one person to hold it all in their head. That bottleneck is now a thirty-second problem for most questions you'd want to ask.

When you put those three changes together, the case for two separate roles gets weaker. The handoff was the expensive part. The handoff is now the cheap part. The thinking — judgment, taste, customer empathy, technical instinct — is what's left, and it's exactly the kind of thing one well-equipped person can hold.

The pros, honestly

When you collapse the roles, or even just blur them, you get a few real benefits that I've seen play out on my own teams.

Decisions get faster, because they get made by fewer people who have more context. The whole class of meeting that exists so the PM can explain the customer to the EM, and the EM can explain the system to the PM, just stops happening.

The reasoning gets higher fidelity. You stop losing nuance in translation. The person making the call on a trade-off is the same person who heard the customer say what they actually meant, and the same person who can read the code and tell whether the proposed solution will hold up.

Politics get smaller. A lot of internal politics in product orgs are downstream of role ambiguity — who owns the roadmap, who calls the shot on scope, who's accountable when something slips. When those roles compress, the questions get easier to answer because there are fewer seams to argue across.

And people learn faster. The PM who is closer to code gets sharper about what's actually feasible. The engineer who is closer to customers stops building things in the abstract. Both of them become better at the part of their job they were always supposed to be good at.

The cons, also honestly

I don't want to pretend this is all upside. There are real costs, and anyone who is thinking about leading this way needs to take them seriously.

The first is burnout. The PM/EM split exists in part because doing either job well is a full plate. When you combine them, you do not magically get a half-plate version of each. You get the same total surface area, with a single human accountable for all of it. AI tools help, but they don't help linearly. Some weeks the customer side is on fire, some weeks the system is on fire, and the person who owns both will feel it.

The second is the loss of depth. There are PMs who are world-class at quantitative analysis, market positioning or pricing strategy. There are EMs who are world-class at distributed systems, hiring senior engineers or incident response. A merged role is, almost by definition, less deep in any single one of those things. For teams that need that depth, the merged role is the wrong answer.

The third is that the model is hard to hire for. The current talent market is built around the split. Recruiters search for PMs and EMs. Universities train people for one or the other. Career ladders inside companies rise on one track or the other. If you decide to hire for someone who can span both, your candidate pool shrinks quickly, and you'll need to grow most of them internally.

And the fourth, which is the one I think about most, is that not everyone will want this. Some of the best PMs I've worked with deeply do not want to manage people. Some of the best engineers I've worked with deeply do not want to write a positioning doc. The merge is real, but it isn't universal, and forcing it on people who don't want it is a fast way to lose them.

The skills that actually matter

This is the part I most wanted to write, because I think the skills conversation in this space has become very abstract. People say things like "be a generalist" or "have a builder mindset" without saying what to actually practise. Here is what I think is concrete and learnable.

Taste. This is the one I'd put first if I had to pick. Taste is the pattern-match that tells you, in five minutes, whether a design is good or whether a customer's request is the real problem or a symptom of something else. You cannot be deep in everything when you span both sides, so taste is what you fall back on. Taste is built by reps — by seeing many examples of good and bad, and by having someone you trust tell you the difference. The fastest way I know to build it is to write down your judgments before you find out the answer, and check yourself.

Prompting as a management skill, not a developer skill. This is underrated. The leaders I see succeeding right now are the ones who have made AI tools into a daily reflex for compressing their own ramp into the unfamiliar. When a PM in this mode needs to understand a system, they don't ask the engineer to explain it — they read the code with help, form their own view, and then ask the engineer sharper questions. When an EM in this mode needs to understand a market segment, they don't book a meeting with marketing — they pull the data themselves and form a draft view. The asymmetry between leaders who do this and leaders who don't is already large, and it's growing.

Customer fluency. AI does not replace customer contact. It amplifies the leverage of leaders who have it and exposes leaders who don't. You need to be in the calls, reading the support tickets, talking to the sales team, looking at the actual product as a user. The reason this matters more in a merged role, not less, is that you are now the single point of failure for "did we build the right thing." There is no PM next to you to catch it.

Systems thinking, applied to both stacks. The ability to hold the architecture of the product and the journey of the user in the same mental model. To see how a backend change ripples into a sales conversation, or how a pricing decision constrains an engineering trade-off. This was always the most senior skill in either role. It is now table stakes.

Writing. I cannot overstate this. Distributed teams run on writing. Merged roles run on writing even more, because there is no second human to catch your ambiguity. The skill is not "writing nicely". It is writing that drives a decision. One page that, when someone reads it, makes the next step obvious. If you cannot do this yet, practise it harder than anything else on this list. It compounds.

Comfort with being a generalist in a room full of specialists. You will sit in a meeting where you are the worst person in the room at any single sub-discipline. The pricing person knows pricing better. The staff engineer knows the system better. The designer knows craft better. Your value is that you are the only person who sees how they fit together, and that is a real value, but it requires real psychological comfort with not being the smartest person in the room on any one axis. Many strong individual contributors find this miserable. Knowing whether you are one of those people is itself a skill.

Coaching over doing. When you can do both sides, the temptation is to do both sides. This is the trap. The job of the merged leader is to use the breadth to make better decisions and to coach the specialists, not to take their work. The first six months of doing this role badly looks like a hero who does everything. The first six months of doing it well looks like a quiet person whose teams are getting visibly better.

A high-trust network of specialists. Because you can't be deep in everything, you need a small set of people you can call, who will tell you the truth fast. Some inside your company, some outside. A staff engineer who will tell you the proposed architecture is wrong. A senior PM who will tell you the positioning is off. A designer who will tell you the flow is broken. These relationships take years to build and are worth every minute. The merged role does not work in isolation.

If I had to compress that list into one sentence, it would be: the merged leader's job is to have enough breadth to ask the right question, enough taste to recognise the right answer, and enough restraint to let the specialist execute.

How I see this playing out

I don't think the words "Product Manager" and "Engineering Manager" are going to disappear in five years. Titles are sticky. I do think the work behind them will look noticeably different.

I expect a slow compression rather than a sudden one. More companies will quietly stop opening separate requisitions for each role on small teams. Senior PMs will be expected to read code. Senior EMs will be expected to own outcomes that used to belong to product. Job descriptions will get longer. Career ladders will start to reward the spanning skill explicitly. A few companies will rebrand the role outright — some version of "Product Engineer" or "Team Lead" or whatever the market settles on. Most will not, and will just let the role drift.

The biggest tell, the thing I'd watch for, is what gets rewarded at promotion time. When companies start promoting people who span both, more than people who go deep in one, the merge has happened in practice whether or not the org chart shows it.

What I'd tell someone starting out

If I were starting in this field today, I would not pick a side. I'd pick the team where I could see both, and I'd invest hard in the skills above — taste, writing, customer fluency, prompting as a daily habit. I would not optimise for the title. I'd optimise for being the person in the room who can hold the whole problem.

And if I were already deep on one side, which is closer to where I actually am, I'd be looking honestly at the other side and asking which of those skills I'm weakest at, and getting deliberate about closing the gap. Not because the old role is going away. Because the leaders I most admire in this moment are the ones who long ago refused to be only one thing.

The wall is coming down. It's worth thinking about what you want to be standing on when it does.