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

When a team is doing work they’re not uniquely qualified for, DevEx might consider doing it for them. How do we decide when to do so?

DevEx can do the work if the effort for us doing it across N teams is the same as for 1 team. Another way to say it: when the repository is heterogenous, then we have an economy of scale.

In addition, DevEx has more motivation to use a robust, future-looking solution since many teams depend on it working. We can also put in the effort needed to develop Version-delta knowledge — what changed between releases, deprecations, migration path. In fact we can even afford to write custom compiler plugins to produce correct codemod transforms to automate refactoring when needed.

Let’s look from a managers point of view. DevEx has performance reviews tied to doing this sort of work, and can show much more impact for spending time on it than a product engineer can. Work worth centralizing is precisely what a product manager ought to discourage their own engineer to do.

Since DevEx is the only place in the org where these investment is rational, the idea of “push it back” pushes work to the one place structurally incapable of doing it right.

A proactive posture — seek out toil, don’t guard the door

DevEx should watch metrics that lead us to discover when engineers are toiling. We can actively solicit more of this work when it meets our economy-of-scale threshold.

“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.

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

It’s mid-2026. Previously dev infra stayed in its lane because we aren’t fluent in the product code’s language and patterns. Learning an unfamiliar language or codebase well enough to safely refactor is genuinely expensive. But now AI agents give us much easier understanding of unfamiliar code and do an excellent job of predicting how migration work can break assumptions. Parachuting into an unfamiliar stack for a mechanical-but-context-sensitive refactor is now hours, not weeks.