TL;DR PO, QA, security, DevOps, and plenty of others. Job titles that barely existed twenty years ago. Now hired and promoted as if they always had. Each names a real skill. None ever needed a seat that could only do that one thing. On my team, the tech lead absorbed product ownership on top of the technical expertise he already had — one field report, not a template for every org. The bigger claim: heading into 2027, an AI-native team can't afford the coordination a seat was built to sell. Skills have to remerge into whoever already holds the accountability.
Somewhere in the last decade, a set of skills got promoted into a payroll line.
Product Owner. QA engineer. Security engineer. DevOps engineer. And plenty of others. None of these existed as separate seats twenty years ago. Now most engineering organizations hire and promote for them as if they always had. Each one names something real: product judgment, test judgment, security judgment, operational judgment. None of them ever required a person who could only do that one thing.
Development and architecture went through a version of the same move. Some organizations peeled off a Solution Architect title from the senior developer who used to hold both. But that pairing mostly resisted the split. A tech lead, by default, already carries the development judgment and the architecture judgment. That was never the piece that needed its own seat.
Somewhere between the first Scrum certification and the fortieth dedicated Slack channel, the other skills got seats instead. The seats started acting like the skills needed protecting from the rest of the team.
This is a field report. It's about what happens when you put the seat back where the skill came from. It worked on my team.
I don't think the specific shape is universal. The tech lead absorbing product ownership on top of expertise he already had — that's what happened here. A security-heavy fintech team would land somewhere else. It should.
What generalizes, heading into 2027, is the diagnosis. The seat, not the skill, is what a fast organization can no longer afford. If you are running on AI-native throughput, the org chart you inherited is now the slowest thing you own.
A title bought coordination. It rarely bought the judgment it was named after.
What the decade actually built
I want to be honest about the history before I argue with it: the cynical version is also the lazy one. Three things happened at once, and only one of them deserves the accusation.
The first is real. Complexity grew faster than any one engineer could hold. Security surface, cloud topology, regulatory traceability — each got deep enough that a generalist skimming all three did worse than a specialist owning one. At least at a given team size.
The second is real too. Once an organization outgrows a room everyone fits in, someone has to do cross-team integration. That work is genuinely full-time past a certain scale. Frameworks built for that moment — the Scaled Agile Framework, for one — publish entire role catalogues: Product Owner, Release Train Engineer, Solution Architect. The honest answer to a real coordination problem, at hundreds of engineers.
The third is the one I'm actually arguing with. Those same catalogues got installed at teams a tenth that size. The seat survived long after the coordination problem it solved had shrunk back down.
Nobody planned it that way. It happened one restructuring at a time, each one locally reasonable. A promotion needed a title. A title needed a scope. A scope needed a headcount line to protect it.
The result reads, from where I sit, less like specialization and more like a piloting layer. A seat whose main output was status, not judgment. Its existence let the people doing the work stop feeling responsible for the parts the seat now covered.
That reading is mine. No framework I'm about to cite makes it for me.
Team Topologies gets closest to a citable version of the mechanism. But it argues something narrower than my claim. Cognitive load is finite, so a team should shed every hand-off it doesn't need.
DORA's own research backs the same instinct from the systems side. Elite performers are measurably more likely to run a loosely coupled architecture. Precisely because it removes cross-team dependency from the critical path.
Neither one argues for merging PO, security and domain expertise into a single person. What they argue is simpler: every hand-off has a cost. An organization that keeps adding seats without asking what hand-off each one adds is paying that cost blind.
That argument gets sharper once agents are in the loop. They absorb most of the relay work a seat used to justify. What stays scarce is not production. It is the finite cognitive load of whoever still has to decide. Every seat still standing after its coordination need has shrunk is a claim on that same limited budget.
The clearest real-world precedent for actually collapsing a seat — not just reducing its hand-offs — is the disappearance of a dedicated "operations" title. Werner Vogels described it in 2006. Giving Amazon's developers operational responsibility for what they built raised quality on both sides of an old wall. The wall between building software and running it. The two halves of that judgment — build it well, run it well — never actually needed two different people.
Netflix wrote the same move up a decade later, as "full-cycle developers." Separate SRE and test-engineering seats, folded back into the person writing the change.
Testing and security are living through the same move right now. It's called "shift left." Instead of a QA seat catching what a developer missed downstream, or a security seat gatekeeping a release at the end, the skill returns to whoever is already closest to the change when it's made.
One field report, not a template
On Solstice*, I'm the tech lead for the engineering side of a hospital ERP. I've spent enough years in this domain that I already knew the ins and outs of the patient journey — identity management, its edge cases — before I ever touched a backlog.
The tech lead title already meant I owned the architecture judgment and the development judgment. That was never in question. It's not what changed.
What changed is the third one: business judgment. Reading what a hospital actually needs, and turning it into a priority. That usually sits with a separate PO.
From the start of the Solstice project, product responsibility was mine. We built a deliberately small team, with no separate PO. I make product decisions myself, in the same conversation where I make the technical call. The weekly workshop ends with the tickets already written — because the person deciding what we build, and the person who understands why the certified module handles retention a certain way, are the same person. Same meeting. Same moment.
Naming why this setup holds together matters more than the fact that it exists. The relay work a separate PO would have carried — feeding the backlog, formatting tickets, chasing status for a steering committee — is exactly what agents absorb, as I described in an earlier post.
That absorption isn't this post's argument. It's the precondition for it. It frees enough hours in a week for one person to hold product judgment and domain depth at once, without doubling their workload.
Before agents did that packaging work, fusing the two roles meant one side went shallow — product or technical. Now it doesn't have to.
I want to be direct about what doesn't generalize here. It worked because I already had ten years in this domain before I added the product skill on top. I wasn't asking a generalist to become an expert in two things at once. I was asking someone who already half-owned one of them to formally own both.
"Promote your best engineer to also run the backlog" is a recipe for burnout — if the second skill isn't already half-built. It's a bus-factor problem if that person becomes the only one who can translate domain nuance into a technical constraint.
Past roughly fifteen to twenty engineers, or more than one product surface, I'd expect this exact shape to break. The fusion becomes two full-time jobs wearing one badge. Not one job with better ergonomics.
What generalizes isn't "make your tech lead do this." It's this: stop assuming a skill needs its own seat, before checking whether it already lives next to the accountability you need.
This sharpens something I only got half right
I wrote, two posts ago, that product judgment survives and diffuses across roles. The engineer making micro-decisions hourly. The PM steering by delivery numbers. The PO feeding context through the workshop.
That's still true at the scale that piece was describing: a multi-role team, the wall between product and engineering dissolving from both sides at once.
What I didn't say clearly enough: diffusion has a shape. And the shape depends on how small the team gets. Spread thin enough — a squad small enough for one person to already hold the full context — diffusion doesn't stay spread. It collapses to one name.
That's not a failure of the earlier argument. It's what that argument looks like once there's only one person left to diffuse to.
I'm naming this directly, because a reader of the series will notice the shift before I point it out. The earlier post argued judgment shouldn't consolidate into one role — not without a named answer to who signs, and how juniors learn it. Both answers get harder, not easier, when the role is one person instead of four.
I don't think that makes the fusion wrong. I think it makes the honest section below non-negotiable. Not optional.
Judgment did not move to a title. It moved to whoever was already accountable and had room left in the week.
Where the seat still earns its keep
None of this argues for fewer people. My team grew this year, interns and apprentices included. The hours a merged title frees don't disappear into a smaller headcount line. They go to discovery, domain depth, and regulatory work — the things every post in this series has already argued were underfunded. Same logic as the DORA piece: the value is in reinvestment, not extraction.
Some of what a seat did isn't overhead at all. It's a legal fact about how regulated software has to be built. No title redesign changes that. On Solstice*, the person who writes a safety-critical change can't be the sole reviewer of its own verification. That's not a management preference. It's the segregation of duties an auditor checks for, by name. Independent security review stays independent.
A junior or apprentice still needs someone to shadow, and a seat to grow into. Collapsing a title doesn't collapse the need to teach the skill to someone who doesn't have it yet.
And past the team size where one person can hold the full context, product management as a function stops being optional. It becomes genuinely full-time again. I wouldn't try this shape at ten times my team's size. I'd be wrong to recommend it there.
The honest list, stated plainly: independent verification on anything safety- or security-critical. A named, accountable signer for every decision chain. An on-ramp for whoever inherits the skill next. None of those three survive being merged away. Everything else on the org chart is a candidate.
Two ways to get the timing wrong
Merge too early and quality drops on both sides — the same failure mode a shallow generalist hits. Never merge, and the hand-offs keep running out of habit — even the ones the team no longer needs. The window between the two is narrow: it opens once the second skill is already half-built, not before.
Read the rest of the series: The SDLC Is Dead — why the process was always waste. Coding Was Never the Job — what the engineer becomes when syntax disappears. The Backlog Was Never the Job — the post this one sharpens: judgment diffuses across roles, until the team is small enough that it doesn't. Doctrine Compounds. Models Don't. — where the rules that outlive a merged role live. The Tests Passed. Nothing Happened. — the other skill that stopped needing its own seat. DORA Just Confirmed What My Team Already Lived — the reinvestment logic this post reuses.
Sources
- Scaled Agile Framework — Glossary: Product Owner, Release Train Engineer and Solution Architect are named, official SAFe roles. Cited for the role catalogue's existence, not as an endorsement of the scaling model itself.
- Team Topologies (Skelton & Pais, 2019): the cognitive-load argument for shedding unnecessary hand-offs at the team level. It argues for restructuring teams, not merging individual roles — I am extending its logic further than the authors do, and say so above.
- DORA — Loosely coupled teams: elite performers are measurably more likely to run architecture that removes cross-team dependency from the critical path. About systems, not job titles — the analogy is mine.
- Jim Gray, A Conversation with Werner Vogels (ACM Queue, 2006): the origin of "you build it, you run it" — Amazon developers taking on operational responsibility for what they built.
- Full Cycle Developers at Netflix (Netflix Tech Blog, 2018): Netflix folding separate SRE and test-engineering seats back into the developer, a decade after Vogels.
- Solstice* — the workshop cycle and the team-size figures come from the team's own practice. Internal, no link: the codename is fictitious and the real project, its products and its vendor are anonymized.