Some work belongs to DevEx — and pushing it back undermines our own value proposition

I’ve recently encountered the philosophy that Developer Experience / Dev Infra teams should guard the scope of their committed systems by disclaiming brokenness owned by product development teams. I think this is wrong and want to tell you why!

Why we staffed a DevEx team to begin with

At the inception of software projects, the engineers write code, then build it, test it, and deploy it themselves. They create a simple VCS location to share commits. I like to think of this early phase as villages: they’re self-sufficient, and every member needs to walk to the well with a bucket to refill their water supply.

As our org grows from a village to a town, and then to a city, we delegate infrastructure to a group of experts. They maintain a municipal water supply, with water towers that give reliable pressure to the faucet in your house. Dev infra exists for the same reason. Some work is undifferentiated across teams, and centralizing it frees product teams to spend their valuable attention on what they’re expert at.

As soon as the DevEx team claims to own and maintain the git repo and a GitHub remote for push/pull operations, we have taken on a burden, but one that serves the org well. However users can (and will) do whatever is expedient for their jobs. If they create an automation that creates 10 git tags per second, eventually that’s going to cause too many refs that slow down git status and other operations. So it becomes DevEx’s job to decide how to meet their KPIs in the face of user-supplied workloads they wish had been more carefully considered.

Some DevEx engineers think we can push work to product teams

As our systems scale, both in size and number, my “too many refs” example proliferates. DevEx struggles to keep good KPIs and then has to resort to reactive firefighting mode.

  • The number of top-level folders in a repo exceeds 1000 and now GitHub won’t render them.
  • Someone merges a compilation error to ‘master’
  • A very flaky test causes false-positive red PRs
  • Deploys get really slow as the artifact grows with unneeded bytes
  • A spaghetti of dependencies prevents modularizing the codebase into libraries that can be built/tested in isolation

How do we deal with this? I’ve heard “DevEx scales by pushing work back to code owners and product teams.”

Of course, this can be the right answer some of the time. DevEx cannot commit to be a permanent on-call for tech debt it didn’t create – we’d never be able to staff this, and it sets the wrong incentives next time the product team considers taking a shortcut.

However, taken to its conclusion, “push work back” is an argument for un-inventing dev infrastructure. Every increment back toward total vertical ownership is just a retreat from our founding charter.

The question was never “how do we avoid work” — it’s “which work is differentiated vs. not.” And like municipal water supply engineers, we should appreciate our ability to do unglamorous work that lets our company ship working software faster.

4. The economy-of-scale test — anchored in the React upgrade

  • The crisp test: does solving this once keep it solved, vs. N teams re-solving it worse with no regard for durability?
  • React major upgrade as the marquee example. Two kinds of knowledge:
  • Version-delta knowledge — what changed between releases, deprecations, migration path. Identical across every team, expensive, currently learned N times.
  • Local-code knowledge — what this specific code does and why. Per-team.
  • The orthodoxy co-locates the upgrade with local knowledge, forcing N engineers to each learn the React delta from scratch. Should co-locate the upgrade with the scarce, expensive knowledge instead.

5. The incentive asymmetry

  • The work worth centralizing is precisely what a product manager will never authorize their own engineer to do.
  • Accurate refactorings, real guardrails, durable migration tooling — exceed what any product team’s manager is comfortable owning. Not capability; it’s invisible on their roadmap and the payoff lands on other teams.
  • DevEx is the only place in the org where that investment is rational. So “push it back” pushes work to the one place structurally incapable of doing it right.

6. The proactive posture — recruit toil, don’t guard the door

  • Flip the posture entirely. Not selective intake — active solicitation.
  • “We’d love to take that toil off your plate so you can focus on shipping.”
  • DevEx marketing its own surface area, the opposite of defensive door-guarding.

7. The skills barrier that justified the boundary — and why AI just expired it

  • The honest, unstated reason dev infra stayed in its lane: infra engineers aren’t fluent in the product code’s language and patterns. Learning an unfamiliar codebase well enough to safely refactor is genuinely expensive.
  • “Not our code” was partly a rationalization of “not our language.” Be honest that this was a real constraint that made the boundary rational — not just empire-protection.
  • The turn: AI agents dissolve this. Parachuting into an unfamiliar stack for a mechanical-but-context-sensitive refactor is hours, not weeks.
  • Callback to React: the only reason you couldn’t hand the upgrade to one person before was that they lacked the local-code knowledge. That’s the barrier that just fell. The scissors close.

8. The psychology throughline

  • Org norms outliving the constraint that produced them. The old ownership model was shaped by a human limitation (cost of learning unfamiliar code); people built principles to justify the workaround; the limitation is lifting faster than the principles update.
  • “Push it back” feels principled, scalable, defensible in a planning meeting — the locally rational move for a team protecting capacity. But it externalizes cost onto people with less context and weaker incentive to make it durable. The org pays N times for a worse result.
  • The reflex optimizes for the team’s legibility, not the org’s actual cost.

9. A better heuristic + close

  • Replace the blunt rule with a decision rule: push back work that’s domain-specific or doesn’t centralize; recruit work with high economy of scale and durability payoff.
  • Tie back to the series theme: effective infra is about understanding incentives and human behavior, not clean ownership boundaries. The wrong mental model produces locally sensible decisions that are globally expensive.

Possible names to coin (series tends to name the pattern): the “feels-scalable-but-isn’t” trap in §8; the two-knowledge “scissors” in §4/§7.