Two threads showed up in our team channel this week. Different topics, same question underneath: whose job is this?
The first was about MFU variance in nightly training tests — 3% absolute difference across runs, discovered by a researcher staring at Poseidon charts by hand. They wanted automated monitoring. Datadog alerts, the whole thing. The second was about building a Claude agent to auto-analyze CI test failures on Condor — a researcher asking if DevEx could wire it up for their regression test workflow.
Both are reasonable asks. Both are clearly useful. And both required someone to say: that’s not us.
The easy version of scope
When people talk about platform team scope, they usually draw it like this:
- DevEx owns: CI/CD pipelines, build systems, developer tooling, test infrastructure
- Product teams own: Their tests, their features, their domain logic
Clean line. Textbook answer. And it works for maybe 60% of cases.
The MFU monitoring request? Easy call. DevEx can own the pipeline — getting data from Poseidon into Datadog. The test-owning team owns what to monitor and when to alert. We build the pipe, they decide what flows through it.
The auto-analysis agent? Also pretty clean. We’d already built ai_fix_failure.yml for main branch CI health. A researcher wanted the same thing for team-specific rocket regression tests. We said: we don’t own that, but here’s the reference. He took it, built his own version, shipped a PR in a day. Platform model working as intended.
So where’s the problem?
The middle ground teams
Between “DevEx” and “product team” there’s an entire layer of teams that don’t fit either category. AI infra. Training infra. The people who manage GPU clusters, NCCL configuration, container runtimes, data loading pipelines.
These teams are building infrastructure. They’re not product teams. But they’re also not DevEx — they’re domain-specific infrastructure for ML training workloads.
And the requests that come from this middle ground are the hard ones. Because they sound like DevEx work. They involve CI. They involve agents and automation. They involve Datadog. But the domain knowledge required is deep — MFU benchmarks, CUDA driver interactions, distributed training failure modes.
Here’s the question I keep hitting: when a middle-ground team asks DevEx to build something that runs in CI, uses our tools, and touches our infrastructure — but requires their domain expertise to be useful — who owns it?
Hard lines vs. soft lines
I think there are two kinds of boundaries.
Hard lines are the ones you enforce even when it’s awkward:
| Hard line | Why it’s hard |
|---|---|
| DevEx doesn’t own team-specific test suites | Even if the test runs in our CI system |
| DevEx doesn’t interpret domain metrics | Even if the data flows through our pipeline |
| DevEx doesn’t build bespoke agents for individual workflows | Even if it’s “just a few prompts” |
The principle behind hard lines: if only your team has the domain knowledge to maintain it, you own it. DevEx can’t debug why MFU dropped 3% — we don’t know what healthy MFU looks like. That’s not a skills gap, it’s a scope boundary.
Soft lines are the ones where you help, but you don’t own:
| Soft line | What it looks like |
|---|---|
| DevEx provides reference implementations | “Here’s ai_fix_failure.yml, use it as a template” |
| DevEx builds the mechanism, not the policy | “We’ll get data into Datadog, you set up the alerts” |
| DevEx consults on shared infrastructure | “This is how you wire up Slack notifications from a workflow” |
Soft lines are about making teams self-sufficient. You hand them the LEGO bricks, not the assembled model.
The escalation rule
One heuristic I’ve been testing in my head:
One team needs it → they own it. Three teams need the same thing → it becomes platform.
Dan needed auto failure analysis for rocket regression tests. That’s one team. He owns it.
If three different teams all need auto failure analysis on Condor, and they’re all building their own version from the same reference — that’s a signal to platformize. Extract the common parts, make them reusable, and then DevEx owns the shared layer.
The mistake is platformizing too early. You build the general solution before you understand the specific use cases, and you end up maintaining something nobody asked for.
Where it gets genuinely hard
The two-thread examples were the clean cases. The hard cases look more like this:
The Condor log access problem. Claude can’t access Condor logs directly from CI because they run in containers with no host access. Three approaches were discussed: upload to GitHub artifacts, install Claude Code on runners, or collect logs with a post-failure step. Each approach has different ownership implications. The log collection step? That’s in the team’s workflow. The GitHub artifact upload mechanism? That could be shared. The Claude Code runner installation? That’s definitely DevEx.
A single request, and the ownership is fractal. Different pieces belong to different teams.
The Poseidon → Datadog pipeline. DevEx can build the data extraction mechanism. But someone has to define what data to extract, what format to use, what Poseidon endpoints to hit. That domain knowledge lives with the training infra team. So the “mechanism” we’re building requires input from people who know the domain. It’s collaborative, not clean.
The “just make it work” gravitational pull. When you’re the team with the CI expertise, every automation request feels like it should be yours. You could build it faster. You know the systems. And the requesting team often can’t distinguish between “I need you to build this” and “I need you to show me how.” The temptation is to just do it. And then you’re maintaining it forever.
What I actually think
I don’t think there’s a bright line between DevEx and everything else. I think there are three questions:
- Can this team maintain it without us? If yes → provide the reference, step back.
- Would three teams benefit from this being shared? If yes → platformize.
- Does this require our domain knowledge or theirs? If theirs → they own it. If ours → we own it. If both → we build the mechanism, they configure the policy.
The middle ground teams — AI infra, training infra — will always generate ambiguous requests. The skill isn’t drawing a perfect boundary. The skill is having a framework for deciding quickly, explaining it clearly, and not feeling guilty when the answer is “that’s not us, but here’s how you can do it.”
The Dan Ji thread is actually the best proof that this works. He asked. We pointed him to the reference. He shipped in a day. Everyone’s happy. The platform didn’t need to grow — it just needed to be usable.
That’s the goal. Not a bigger platform. A more usable one.