The AI builder/non-builder split is a measurement failure, and there’s data

Somewhere in the last two years, a line got drawn down the middle of the org chart, and a lot of us found out which side we were on during an all-hands.

On one side: builders. Software engineers, hardware engineers, the people who make the thing. On the other side: everyone else. TPMs, PMs, the supporting functions. I’ve heard that speech exactly once, from one VP, in one room, and then spent the eighteen months since watching the same sentiment turn up everywhere I read, in the confident register of people explaining what AI means for org design. The logic is always clean enough to fit on a slide. AI makes engineers faster. Faster engineers are more valuable engineers. Therefore builders go up, and everyone else. Nobody ever finishes that sentence out loud. Every non-builder in the room finishes it privately, and we all finish it the same way.

It’s a logical step. It’s also wrong, and the reason it’s wrong matters a lot more than the reason it’s appealing.

AI is very good at code. Code is structured, it has verifiable outputs, there are enormous corpora of it, and the feedback loop is tight. If you sat down to design a domain for a language model to eat first, you’d design software engineering. And the research holds up in real organizations, not just demos: three field experiments at Microsoft, Accenture, and an anonymous Fortune 100 electronics manufacturer, pooled across 4,867 developers, found a 26% increase in completed tasks.¹ Real firms, real work, proper design. I’m not going to wave that off.

So the premise is sound. The step from premise to conclusion is where it breaks.

Because if your builders do go faster, the work of pointing them in the right direction does not become less important. It becomes harder, more consequential, and considerably more urgent. You now have less time to catch a mistake before it’s shipped, integrated, and load-bearing.

One scoping note before I go further. I’m making this case about the technical coordination roles: technical program managers, technical product managers, and systems engineers. We get lumped together on the wrong side of the line, and we belong together on the right side of this argument, because we share the thing that matters here: we sit inside the technical system. We read the designs. We write and negotiate the engineering requirements. We hold the dependency graph across teams. We own whether the integration actually lands.

I’ll say TPM throughout, because that’s the seat I’m sitting in now. I’ve done the product side, but not in the AI-empowered version of it, and enough has changed in two years that I’d rather not narrate a chair I’m not currently in. Read TPM as covering PM-Ts and systems engineers wherever it fits, which is most places. Plenty of this generalizes further still, but it’s sharpest here, because what AI is accelerating is precisely what these roles are positioned between.

One more note, about the evidence itself. There’s a lot of it below and it is not all equally good, so I’d rather rank it myself than leave you to assume it’s uniform. A handful of these findings I’d defend to the last: large samples, measured outcomes instead of self-report, and nobody involved with a commercial interest in the result. Others are vendor telemetry where a dramatic percentage sits on a thin correlation, or a benchmark that only approximates the thing I care about, or, in one case, a piece of control theory that is rigorous about control loops and merely suggestive about organizations. I’ve said which is which in the footnotes as I go. If you want to take this argument apart, go at the load-bearing ones. The weak citations aren’t holding anything up, and I’d have written the same post without them.

What happens when the code gets faster

When builders go faster, more features go out. That is good, and I want to be unambiguous that I think it’s good.

It also means more decisions about whether those are the right features. More requirements to define well. More rollout plans. More customers to tell what’s changing and when. When you accelerate one stage of a pipeline, you don’t accelerate the pipeline. You relocate its constraint, and the constraint lands on whoever was already holding the next stage.

Faros AI instrumented more than 10,000 developers across 1,255 teams. Developers using AI heavily merged 98% more pull requests and completed 21% more tasks. Alongside that: review time up 91%, average PR size up 154%, bugs per developer up 9%, and lead time for change got longer.² Twice the code, in chunks two and a half times bigger, arriving at a review process that was already the slowest thing in the building.

That’s not an AI failure. It’s the most predictable queueing result there is. You sped up the cheap step and dumped its output onto the expensive one.

DORA has found the same shape two years running. The 2024 report concluded that AI adoption “negatively impacts software delivery stability and throughput” even while raising individual productivity.³ In 2025 throughput flipped positive, which isn’t a point against me. It’s the point. More is going out. Whether it’s the right more is the entire question. Stability, meanwhile, still hadn’t flipped: AI adoption “not only fails to fix instability, it is currently associated with increasing instability.”⁴ Their framing is the line I’d put on the all-hands slide myself: AI doesn’t fix a team; it amplifies what’s already there. An amplifier doesn’t care whether the signal is any good. It just makes it louder.

The thing that predicts whether your software breaks is not your software

This is the study I wish everyone shouting about AI had read, and it was published in 2008, which is what makes it useful. Nobody wrote it to win this argument.

Microsoft Research took 3,404 binaries from Windows Vista, north of 50 million lines of code, and tried to predict which would fail in the six months after release. They ran the usual suspects: churn, complexity, dependencies, test coverage, pre-release bugs. Then they built a model out of nothing but organizational metrics: how many engineers touched a component, how many had since left, how deep the ownership chain ran, how many separate orgs contributed meaningful edits.

The organizational model won, and not narrowly. Of the components it flagged as likely to fail, 86% actually did. Of all the components that really failed, it caught 84%. The best code-based predictor was churn, at 79% and 80%. Test coverage was the most lopsided. Usually right when it flagged something, but it missed nearly half the real failures.⁵

On that product, the best available predictor of whether software would break was not a property of the software. It was a property of the org chart wrapped around it. That’s one product, at one company, in one year, and I’d want it replicated before I called it a law. But once you’ve seen it, you start seeing it everywhere you work.

So which of those metrics does an AI coding assistant improve? Churn, maybe. Complexity, sometimes. Coverage, often, and that’s a real and underrated win. It does not improve how many organizations are editing this component, or whether ownership is clear, or whether the four teams touching this interface hold the same understanding of what it does. Those were the variables that predicted failure best, and no volume of generated code touches them.

They also happen to be the job description of the people who just got moved to the wrong side of the line.

Two other studies point the same direction from different angles. Herbsleb and Mockus pulled thousands of change requests out of a large telecom software organization and sorted them by one variable: did this change stay in one location, or cross sites? Same-site changes took about 5 days; multi-site changes took 12.7 days. The mechanism wasn’t distance or time zones, it was that distributed changes require more people.⁶ Cataldo and Herbsleb later measured the thing underneath that across two industrial projects, defining socio-technical congruence as the gap between who needs to coordinate given the technical dependencies and who actually does. Closing that gap was associated with an 18.6% reduction in estimated failure probability.⁷

The detail that stopped me cold sits in that same paper: engineers faced roughly three to five new coordination requirements every month out of twenty-five to twenty-seven total, and more than half of the new cross-team ones involved people who hadn’t needed to coordinate the month before. The map of who needs to talk to whom churns constantly, and a good fraction of each month’s edges are new. That is not something you solve with goodwill and a Slack channel. Somebody has to hold that graph.

Now speed everything up. More features, across more of the system, in bigger changes. What did you just do to participant count per change? To the number of components under simultaneous modification? To the odds that Team A’s integration lands in the same window as Team B’s, when neither planned for the cadence they’re now moving at?

In my corner of the industry the failure mode isn’t a bad sprint. I work on systems that run fulfillment. If we change how a building behaves and don’t tell the operations teams who run that building, we don’t ship a bug — we can take the building down. People don’t get their packages. Google’s SRE team has long held that roughly 70% of outages come from changes to a live system;⁸ that’s Google asserting its own internal number, so weight it accordingly, but it matches everything I’ve watched for a decade. The change is the risk.

Requirements aren’t overhead. They’re throughput.

There is now a clean measurement of what good requirements are worth to an AI.

Start with how common the problem is. When OpenAI built SWE-bench Verified, human engineers audited the original benchmark and flagged 38.3% of samples for underspecified problem statements. The issue description didn’t contain enough information to know what a correct fix looked like. These are real issues, filed by real maintainers, on real repositories. More than a third of them didn’t say enough.

Filtering the benchmark took GPT-4o’s resolve rate from 16% to 33.2%.⁹ I’d love to hand you that as a clean measurement of what clarity is worth, and it isn’t one. They also filtered out samples with unfair tests, which were flagged more often than underspecified ones, so the doubling isn’t attributable to specification quality alone. What the audit does establish cleanly is the prevalence: underspecification is not an edge case, it’s a third of the corpus.

For the causal version you want an experiment that changes only the specification, and Google ran one on test generation. Agents made to state preconditions, postconditions and undefined behavior before writing anything caught 63.2% of real bugs against 53.4% for the baseline, across 90 historical bugs from Google’s own issue tracker.¹⁰ Worth knowing the effect only separates from noise once you let the agent try a few times; on a single attempt the two are indistinguishable. Cleaner evidence still is coming a section from now.

I lived the pre-AI version of this. Ten years ago, on a team surfacing data into Salesforce, we started writing our integration specs directly in JSON, wired into the codebase instead of describing it from a distance. New APIs went from a multi-week cycle to days plus QA. Call it a 50–75% cut, and a bigger cut in back-and-forth, because the spec we agreed to internally was the spec our customers integrated against. Nothing left to mistranslate, using 2016 technology.

The lesson holds up: it is cheaper to be precise early than to be precise late. That was true in 2016. AI didn’t change it. AI just raised what you get back for doing it.

Which makes feeding a model vague tickets and then concluding that coordination roles add no value a fairly remarkable piece of circular reasoning. You took away the thing that makes it work. Then you measured it working badly.

The questions stopped coming

Here’s the shift I’ve noticed on my own programs, and it shows up in no dashboard anywhere.

I get fewer deep, specific questions from implementers than I used to.

Think about what that loop was. An engineer picks up a ticket, starts reasoning about how to build it, and hits the place where the requirement runs out. What happens when this field is empty? Does this need to be idempotent? You said “notify the operator”: synchronously, or can it queue? Those questions arrived on day one, and every one was a defect caught before it existed. That was distributed, unpriced requirements review, performed by everyone who touched a spec, and it worked because a human cannot write code without first building a mental model, and building a mental model surfaces gaps.

Models don’t do that. Not because they can’t see the gap. Because seeing it doesn’t make them raise it.

Cornell researchers ran ten models across three families against a thousand questions. Asked directly to judge whether a question was ambiguous, most models caught 60–80% of the ambiguous ones. Left to answer on their own, they asked a clarifying question almost never. Clarification rates cluster near zero, and the most inquisitive family tops out around 5%. And the finding that should worry us: giving the model more context improved its accuracy and further suppressed what little clarifying it did. Better informed, more confidently papering over what it didn’t know.¹¹

In software specifically, Carnegie Mellon built a benchmark that hides information from coding agents. Claude Sonnet 3.5’s resolve rate fell from 59.52% with full information to 37.94% with it withheld. A third of its performance, gone, on exactly the input a human implementer would have pushed back on. In fairness to the models, that gap is closing: Sonnet 4 fell only from 67.24% to 60.82%, so newer models cope with underspecification considerably better.

The part that doesn’t close is the behavior. Force the agent to ask clarifying questions and performance comes back. For the Claude models, 80–89% of full-information performance, though weaker models recover as little as half of it. The questions demonstrably work. And yet, in the researchers’ words, models “almost never interact, even for severely underspecified inputs.”¹² They can recover. They just don’t reach for it on their own.

And it fails silently, which is the problem. The old failure mode was a question you had to answer. The new one is plausible, confident, well-structured code resting on an assumption nobody stated, which survives review because it looks fine in review, and surfaces in integration, or production, or a building.

Everyone’s local win, nobody’s system win

But implementation questions are the small version of this, and I’ve come to think the big version is the actual story.

Since moving into management I’ve been working across multiple generations of systems in a way I wasn’t as an IC. In two months, the pattern I keep finding is greedy algorithms developed in isolation. Algorithm A tunes KPI 1. Algorithm B tunes KPI 2. Both teams ship. Both teams report a win. The gains cancel, and the net system moves sideways or backwards.

Some of that is incentive design. When goals are set per workcell, you get workcell optimization, and that’s a whole separate post. But some of it is a straightforward absence: nobody has set a hierarchy of KPIs for the system, with acceptable ranges and explicit guidance on trade-offs, so teams have no shared mental model of how the system is supposed to behave or where their component sits inside it. Absent that, every team optimizes the only thing it can see.

This is not a new failure. It’s just newly fast.

Control theory has the rigorous version, and it’s worth being precise about it because the precision is the interesting part. Pair your inputs and outputs badly in a coupled system, specifically on negative steady-state RGA elements, and you can tune each loop independently, have every loop stable, have the assembled system stable as tuned, and still be carrying a latent instability that shows up the moment one loop saturates or gets taken out of service.¹³ Not every coupled system does this. But when it does, every dashboard is green, every team is right about its own loop, and the failure lives in how the pieces were paired rather than in any of the pieces. And note what that isn’t: it isn’t incompetence, and it isn’t bad faith. Every loop was tuned correctly, by someone doing their job well, inside the boundary they were given.

And the experimentation literature has measured it directly, which is the part I find hardest to argue with. Microsoft’s experimentation team put it plainly after a run of large Bing experiments: “Local improvements are easy; global improvements are much harder.” In one, an ad background color change moved ad revenue −12%, a large and unambiguous move on the owning team’s metric, while the user-level system metric didn’t budge (p = 0.83). Each of the others in that group ran the same way, with component metrics swinging hard and the system metric flat.¹⁴

Google published the sharpest version. Increasing mobile search ad load produced significant short-term revenue gains. The ads team’s metric, up. Modeling how users actually learn and adapt, the long-term revenue effect was essentially zero. The harm had a roughly 60-day half-life, meaning it was invisible on the two-week horizon a team typically reads. Google’s response was to cut mobile ad load by 50%, and they estimated the user response would be strong enough that even long-run revenue came out ahead.¹⁵ The local metric said win. The system said zero. The correct move was the opposite of what the local metric implied, and it paid.

My favorite illustration is the simplest, from the team who built Google’s experiment infrastructure: two parameters, one setting a page’s background color and one setting its text color. Blue is a valid value for both. Set them independently and you can land on blue-on-blue, and the page is unreadable.¹⁶ Two individually correct choices. One broken system. Now picture those parameters owned by different teams, which is the situation the paper was written to solve.

Those are all web-scale consumer examples, and if you work on physical systems you may be about to dismiss them. Don’t. The shape is identical and the blast radius is larger. The escalation I’m in right now is exactly this: a set of algorithms, each defensible on its own, that I’m working through to find where they conflict with each other, where one is being called at the wrong layer of the planning stack to be useful, where we’ll miss a balance point, and where system variables go unhealthy in ways nobody intended once it’s all running together. Nobody wrote a bad algorithm. Everyone tuned theirs correctly. That’s the problem.

Then there’s the base rate underneath all of it. Only one third of ideas tested at Microsoft improved the metric they were designed to improve. That one is Microsoft measuring itself. The same paper relays a figure of around 10% for Google and Netflix’s own working assumption that 90% of what it tries is wrong, both secondhand, so hold those more loosely.¹⁷ Even taking only the first, most confident local changes don’t do what their authors believe, before you get anywhere near interaction effects.

Is AI making this worse? The honest answer is that nobody has measured it directly, but the proxies point one way. GitClear’s analysis of 623 million code changes found cross-file function connectivity, meaning code calling into other code, down 35% since 2023, with duplicated blocks up 81% over the same window and refactoring down about 70% against a 2022 baseline. Their reading: “New code is less and less woven into the existing codebase. Instead, it is isolated in self-contained files.”¹⁸ DORA found teams with tightly coupled architectures see little AI benefit at all. And in multi-agent AI systems, where you can watch this happen in miniature, a Berkeley-led taxonomy of why they fail puts 37% of failures down to inter-agent misalignment and a further 42% to specification and system-design issues. Between them, four failures in five are about how the pieces were briefed and how they talk, not about the pieces.¹⁹

So here’s the class of question that used to get asked, and increasingly doesn’t:

Does this change affect my customers, and how? What else is landing in the same window, and does it interact with this? Does this need an experiment, or are we shipping on conviction? What metrics tell us whether this worked at the system level, not just at my service boundary, and which of those need to exist on a dashboard before we ship, not after we’re paged?

That last one has a number attached. In a study of 152 high-severity incidents at Microsoft Teams, 42% of the incidents that monitoring failed to detect involved failures in dependency services.²⁰ Monitoring is built per-component, by the team that owns the component. The largest category of what it misses is failures crossing a boundary, because nobody instruments the seam. Nobody owns the seam.

That’s the job. Not status reports. Holding the system whole while everyone else, correctly and in good faith, optimizes their piece of it.

Better instruments, not a different job

There’s a tempting response to all of this, and it’s a trap: fine, AI lowers the barrier, so TPMs should just become builders too. Follow that far enough and the line disappears because everyone crosses it.

I don’t want that, and not out of modesty about what I can build. I want the division of responsibility to hold, because the division is doing work. The vantage point is the value. A person reviewing whether four teams’ integrations will land coherently cannot also be heads-down inside one of the four components. Go back to the Vista study. What predicted failure was ownership fragmentation and the number of separate orgs editing a thing. A TPM who becomes another editor of the component doesn’t fix that variable, they add to it. The reason I can see the seams is that I’m not standing inside any of them.

Retool’s CEO David Hsu has the honest framing of where the line falls: “AI has dropped the bar to prototype, but the bar to ship hasn’t moved.”²¹ Exactly. The prototype bar dropping is enormously useful to me. The ship bar staying put is why production engineering is still a distinct discipline with distinct accountability, and I don’t want to blur that. I want engineers who own their code, can diagnose it at 2am, and are answerable for it.

So what AI changed for me isn’t the job. It’s the instruments. Three kinds, all firmly on my side of the line: tools that make me and my teams faster at our own work; prototypes that make a requirement concrete or de-risk a decision before anyone commits engineering time; and analysis instruments that let me hold more of the system at once than I could unaided.

That third one changed my month.

I recently walked into a system performance escalation that had been running for months, in a product area I hadn’t touched in seven or eight years, armed with a long historical paper on how features had rolled out, a lot of latent architectural knowledge, and no realistic way to hold all of it in my head at once. Over two to three days, working alongside AI, I built a full architecture diagram of the system as it exists today: every algorithm in it, how they interact, where they balance against each other, where they trade off. I’ve wanted something like this maybe ten times across my career and built it two or three times. Those were flatter, less explorable and less useful than what I have now. Either I didn’t have the time, or my own perfectionism turned a two-week task into a six-week one. The old versions existed mostly to prove to myself that I understood the system, and then to teach it to other people. This one does considerably more than that.

The diagram isn’t the deliverable. It’s the instrument. I’m now running it against the current feature plans and weeks of program reports to work out whether the integrated plan holds: whether we’ll miss balance points, whether algorithms will fight each other, whether some are called at the wrong layer of the planning stack to be useful at all, whether system variables go unhealthy in ways nobody intended once it’s all running together.

That’s the counter-optimization problem from the last section, and AI is what made it tractable in days instead of never. None of it is production code. None of it should be. It’s a TPM doing TPM work with a far better instrument than I had two years ago. The output isn’t a merge commit, which is precisely why nobody’s dashboard will ever count it.

The study nobody has run

The strongest evidence against me is that MIT/Microsoft/Accenture experiment: 26% more tasks completed, thousands of developers, real firms.¹ The famous GitHub Copilot 55.8% speedup²² is flimsier than it gets quoted as: 95 freelancers, a toy HTTP server, vendor-run. But the enterprise result is real and I’m not dodging it.

There’s also a genuine counter to the coordination case, and it’s one I’d want thrown at me. DORA looked hard at external approval gates: change advisory boards, sign-off from a senior manager outside the work. It found no evidence that they lower change failure rates, while organizations using them were 2.6× more likely to be low performers.²³ If your answer to anything in this post is another review committee, the evidence says you’ll make it worse. The Cataldo and Herbsleb result points somewhere different: what helps is congruence between who needs to coordinate and who actually does. Embedded and technical, not procedural.

Two more objections are worth answering, because they’re the ones I’d raise.

“Fix the architecture, not the org.” This is the strongest form of the disagreement, and it isn’t wrong so much as incomplete. Decouple the services, sharpen the boundaries, invest in the platform, and you do need less coordination, and DORA’s own data says loosely coupled teams capture the gains. I’d take that deal. But two things survive it. Somebody has to decide where the boundaries go, and that decision is precisely the systems judgment I’m arguing has become scarce; you don’t get to treat it as free. And in my world the deal isn’t fully available at any price. A fulfillment center is a system of systems. However elegantly you architect the software, a tote still leaves one machine and enters another, a robotic field still hands off to a pick station, and the building still has to behave as one thing on a Tuesday in December. You can refactor a service boundary. You cannot refactor a physical handoff out of existence. In cyber-physical systems there is a floor under how much integration surface you can design away, and we are nowhere near it.

“You’ve just described something you can automate.” Fair, and I’d push back on the shape of it. The checklists and templates and instrumentation defaults are the output of the judgment, not a substitute for it. A checklist encodes the failure modes someone already understood, and knowing what belongs on it, when it applies, and when it has quietly stopped being true is itself the skill. The harder half doesn’t distribute at all. Asking the right hard question requires holding the system model and standing outside every component in it, and that vantage point is not a template. You cannot ship it as a form.

Let me state the claim in the form that could actually be wrong, so you can hold me to it.

The acceleration isn’t the question. It’s happening, it’s real, and I want it. AI multiplies my output too, and my own week is proof of that.

And I should be straight about something rather than hide behind the part I can evidence. Yes, I do think this is partly a headcount argument. Somebody has to do the upfront work. If your integration surface is widening and your concurrent change is climbing while the number of people who can hold the whole system stays flat, that work does not happen. It doesn’t get squeezed in. It gets skipped, and you find out later. I believe that, I’ve watched it, and I can’t prove it to you. No study I can find has tested it, which is the point of this section. What I’m not going to do is claim I only believe the half that comes with a citation.

Here is the half that does.

The only way I have ever seen anyone reliably convert faster building into faster system-level results is to spend the systems analysis and the requirements work up front, before the code exists, instead of spending it later, at escalation prices, once the algorithms are already fighting each other in production. Skipping it doesn’t remove the cost. It moves the cost to the most expensive place you could possibly find it, and somebody is holding the building on the afternoon it comes due.

Now let me head off the objection I’d have made myself a year ago, because “invest up front” sounds like a pitch for waterfall and it isn’t one. This is not a case for big design up front. We do not need to know everything before we start, and pretending we do is how you get a sixty-page document nobody reads attached to a plan that’s wrong by March.

The work I’m describing is deciding what to resolve first. Which unknowns carry the most risk. Which ambiguity is cheapest to kill with a prototype instead of an argument. Where the low-hanging fruit is. How to phase the thing so each increment teaches you something before you commit to the next one, and then building the requirements and the plan incrementally as you learn, which means the analysis is continuous instead of a gate you pass through once.

That ordering is a skill. It is most of what a good TPM does, and it is the thing I most consistently do not see engineering teams doing on their own. Not because they can’t. Because when you’re inside one component, the risk ordering that’s visible to you is your component’s risk ordering, not the system’s. You can only sequence what you can see.

That’s falsifiable, and I’d rather say it out loud than have it found: if organizations start consistently landing coherent system-level outcomes without investing in that upfront work, I’m wrong.

So there are two claims here and they deserve different weight. The coordination work becomes more valuable. That one the evidence carries, and I’d defend it hard. That it also takes more people is what I believe, from nine years of watching what happens when it doesn’t, and it’s the one I’m asking you to take on my experience instead of on a citation. Those are not the same standard and I’d rather label them than blur them.

But sit on that gap, because I think it’s the most interesting thing here.

We’ve spent three years measuring how fast individual developers write code with AI. Randomized trials at Microsoft and Accenture. Benchmarks refreshed quarterly. Telemetry across tens of thousands of engineers.

What we have barely measured is whether organizations can absorb that acceleration. There’s some. DORA’s stability findings and the Faros telemetry above are both gesturing at it, which is why they’re in this post. But I can’t find a single study that takes the obvious next step and asks whether organizations that invest in coordination capability absorb AI-accelerated output better than organizations that don’t.

That’s not a neutral gap in the literature. It’s a direct readout of what the industry considers worth measuring, and it maps exactly onto the line drawn at the all-hands. We measure what builders produce. We don’t measure whether the system can take it. Then we look at our measurements, notice only one category of work shows up, and conclude the other must not matter.

Meanwhile what I see on the ground isn’t ambiguous. More integration surface than two years ago. More teams moving at cadences nobody synchronized. More features arriving faster than the decisions about whether we want them. The escalation I walked into didn’t come from anyone writing bad code. Every thread I’ve pulled so far leads back to a system nobody had held whole for long enough. The coordination bottleneck isn’t a hypothesis I’m defending. It’s my calendar.

The study is easy to specify: take organizations with comparable AI adoption and materially different investment in technical coordination capability, then measure delivered system outcomes instead of merge volume. Somebody should run it. That nobody has, while we all re-benchmark autocomplete, is the argument.

What to actually do about it

Being right about this is worth little on its own, so here is what I think it cashes out to. Four things, in the order I’d do them.

Start with the name. Stop saying non-builder. Tech has a few labels built out of absence, like non-technical and non-engineering, but this is the only one I’ve watched become load-bearing in how an organization decides who matters. Nobody staffs a team around the non-designers. The word does the argument’s work before the argument starts. It establishes that there’s a real thing, and then the negative space around it, and once you’ve accepted that vocabulary you’ve lost the debate you thought you were about to have. I’m not claiming the distinction is fake. It isn’t. We do different work and deliver different value, and pretending otherwise helps nobody. But name us for what we contribute instead of what we lack.

What I’ve landed on saying is connective tissue. It is not pithy. It will never fit on a slide, and I’ve watched people wait politely for me to finish saying it. I’ll take that trade, because it is accurate and the short options aren’t. Connective tissue is what holds separate structures in position relative to each other, transfers load between them, and is completely invisible until it tears. That is the job. If somebody hands me a better word that keeps all of that, I’ll use it happily. Until then I’d rather be a mouthful than be a negation.

This is the cheapest item on the list and I suspect it’s the highest leverage, because everything below it is harder to argue for while the vocabulary is still doing the arguing.

Then find where the need actually is. Not every team needs a TPM or a PM-T, and spreading us evenly across an org is how you end up looking like overhead. Work out where your integration surface is widest, where the dependency graph churns hardest, where the seams have no owner. That’s where to put people. The Vista and congruence findings are useful here as a diagnostic, not just an argument: fragmented ownership and high cross-org edit counts are measurable, and they tell you where the risk already is.

While you’re there, look hard at your coordination-to-engineering ratio, because almost nobody has revisited it. Whatever number you landed on was calibrated against a world where writing the code was the expensive part. That premise is the one thing everyone agrees has changed. If engineering throughput is up meaningfully and the ratio hasn’t moved, you haven’t held staffing steady. You’ve quietly cut coordination capacity per unit of output, at exactly the moment each unit carries more integration risk. I’m not claiming to know the right ratio. I’m claiming that yours is currently an artifact of an assumption you no longer hold.

Then change the question you’re asking us. This is the one I care most about. The default framing for TPM work is where do we need mechanisms and schedules? That produces status reports, and produces the version of this job that deserves the reputation it has. The better question is where do we need someone asking the hard questions, to go faster and actually deliver? Those two framings staff differently, hire differently, and promote differently. One of them is administrative overhead. The other is the thing this entire post is about, and if you only change one item on this list, change this one.

Then train for the mental models. Asking the right hard question is not a personality trait, it’s a learned skill built on a systems mental model: knowing how the pieces fit, where they trade off, what a healthy variable range looks like, and which questions are load-bearing at which layer. Most TPM training I’ve encountered teaches process. Almost none of it teaches this. That’s a gap, it’s fixable, and it’s several more posts than I can fit here.

And then give the judgment away. Everything above concentrates the hard questions in a small number of people, and if that’s where it stops, I’ve described a new bottleneck and given it a nicer name. It doesn’t scale, and it shouldn’t.

So the last piece, and I think the most important one over any horizon longer than about two years, is building the tools and mechanisms that put this judgment within reach of builders of every flavor: software, hardware, firmware, all of them. Not review gates. Not us in the room every time. Things that make the right question surface at the moment someone is making the choice: checklists that have earned their place, templates that ask what else is landing this window, instrumentation defaults that make somebody name the system-level metric before they can ship, design reviews built around trade-offs instead of status. And explicitly teaching the skill itself: how to spot a gap in a requirement, how to notice that your optimization has a neighbor, how to ask the question that saves three weeks. We barely emphasize any of this today. It is going to matter enormously.

Because here’s where this ends up, and it’s the thing I’d most want the people drawing lines on slides to sit with. The old distributed quality loop is thinning out. Every implementer building a mental model, hitting the gap, asking the question. No amount of TPM headcount replaces something that used to happen everywhere at once. The replacement has to be distributed too. We cannot sit behind agents that are writing code and call that ownership. Somebody has to own what is actually being built and every implication of it, and at the volumes we’re now moving, that somebody has to be a lot of people, deliberately equipped.

What I’d say to that VP

You were right that AI changes the value of the work. You got the direction backwards for half the room.

When building gets cheap, the scarce thing isn’t the building. It’s knowing what to build, in what order, across which interfaces, on whose timeline, measured how, and what happens on the floor when it lands. Faster, bigger, more ambiguous builds need more connective tissue, not less: more people holding the system whole, more calibration across teams, more requirements defined well enough to survive an implementer who is never going to ask you a question about them.

Nine years of this has taught me that when the connective tissue is thin, it doesn’t show up as a missed sprint. It shows up months later, as a system performance escalation with a very long paper attached.

The hard questions used to get asked for free, by everyone who touched the work. They don’t anymore. Somebody still has to ask them, and somebody still has to hold the system together while everyone else builds their piece of it. That’s a real job, it’s getting harder, and it’s the one I’d bet on lasting.

Obligatory Note
All thoughts, opinions, and experiences are my own, and do not reflect the opinions or stance of my employer. 

References