DevEx

WHAT IT IS DevEx is the practice of treating the experience of building software inside your organisation as a product with users, measurements and a backlog. It covers time to first meaningful contribution, local development setup, the length of feedback loops, documentation findability, and the accumulated friction of the dozens of small obstacles nobody logs a ticket for. **Not this:** DevEx is not Platform Engineering: it measures and improves what using the tooling feels like and where it costs time, rather than owning and building the platform itself. WHY IT EXISTS Engineering capacity is lost in small increments that no single person escalates: a flaky local setup, a twelve-minute feedback loop, documentation that is wrong in one step. Individually each is a minor annoyance; together they are a substantial fraction of an organisation's output, and because nobody owns the aggregate, nobody sees it. DevEx exists to make that cost visible and therefore fixable. WHEN TO USE IT Adopt it when onboarding takes longer than anyone admits, when engineers maintain private workarounds for shared tooling, or when a platform investment landed and nobody adopted it. The last one is the clearest signal: a platform with low adoption is usually a DevEx problem, not a marketing one. WHO OWNS IT A developer-experience or platform team owns the measurement and the improvement backlog. Engineering leadership owns acting on what the measurement says, since most of the fixes compete with feature work for the same people. Every team owns the friction it creates for others. Where a platform team exists, DevEx is the function that tells /platform-engineering whether what it built is actually good to use. WHAT GOOD LOOKS LIKE Time from joining to a merged change is measured and tracked. Feedback loops — local test run, pipeline, preview environment — are measured at the percentile engineers actually experience. Friction is collected systematically through periodic surveys and not only through tickets, because the worst friction is the kind people stop reporting. Improvements are prioritised against measured cost rather than volume of complaint. Adoption of internal tooling is measured, and low adoption is investigated rather than mandated away. HOW TO IMPLEMENT Measure two things first: time to first merged change for new joiners, and the length of the inner feedback loop. Both are cheap to obtain and both are usually worse than assumed. Run a short, recurring friction survey and publish the results, including the items you are not going to fix. Fix the top friction item completely rather than five partially. Instrument adoption of internal tools. Treat documentation as part of the product surface, because a correct tool with wrong instructions is a broken tool. HOW TO ASSESS YOURSELF Ask your most recent joiner how long it took to ship something and what got in the way. Time your own inner loop. Ask how many engineers have a private workaround for an official tool. Take the scored self-assessment at /assess and sequence the gaps with /roadmaps.