DevEx teams that report into infra build tooling. DevEx teams that think like product managers build leverage. The difference isn’t headcount or budget. It’s whether you see engineers as users.
The infra framing
When DevEx lives inside the infra org, it inherits infra’s mental model: reliability, scalability, standardisation. These are the right goals for infrastructure. They are incomplete goals for developer experience.
Infrastructure optimises for the system. Developer experience must optimise for the person using the system. A deployment pipeline can be technically excellent — fast, reliable, observable — and still be painful to use because it requires engineers to understand its internals to debug failures.
Your engineers are your users
When I set up the Developer Experience charter at slice, the first thing we did was run discovery sessions with engineering teams — the same way a product team runs user research. We weren’t asking “what tools do you need?” We were asking “where does your day get harder than it should be?”
The answers were specific. Onboarding a new service required touching seven different config files in three repositories. Test environments took 40 minutes to provision. Deployment failures showed error codes that required reading internal wiki pages written in 2021 to interpret.
These weren’t infra problems. They were product problems — specific friction points with specific users experiencing them.
The golden path
The most valuable thing a DevEx team builds isn’t a tool. It’s a golden path: the opinionated, well-supported way to do the most common things. New service scaffolding. Standard deployment workflow. Observability defaults.
When the golden path is good, engineers follow it without being told to — because it’s genuinely the easiest option.
Building a good golden path requires the same work as building a good product: understanding user needs, iterating based on feedback, measuring adoption, and treating low adoption as a signal that something is wrong with the path — not with the engineers.
The shift that changes everything
The structural question that determines DevEx output: when an engineer files a complaint about tooling, does it become a support ticket or a product signal?
In infra-framed DevEx teams, it becomes a support ticket. Someone fixes the immediate issue and closes the ticket. In product-framed DevEx teams, it becomes a data point. Three engineers reporting the same friction is a roadmap item.
The best DevEx investment isn’t more tooling. It’s more listening.