What I think developer enablement actually is

I wrote this in work slack in June 2025 and I think it's worth repeating on my blog, and so that's what this post is!

My role at work is within our "developer experience" team (which we call "developer foundations") and I feel the idea of "devEx" is a bit of a suitcase concept (what it means is determined by the person reading the word much more than any kind of real common concrete definition). I feel it's a similar problem that "devops" as a concept has in our industry (something I did for around 8 years before I managed to find my way back to application development).

The way I see it is we are enablement for application developers, which means we have custodianship over:

• Ensuring application developers work in an environment where they are productive and have the ability to grow as developers
• Ensuring that the default and accessible approach to application developers results in code that ages well (velocity comes from rarely revisiting code that is already considered "done")

With an approach that is human centric rather than technology centric, as the goal is to grow engineers far more than it is about hiding challenges from developers.

And we have at our disposal

• Supporting developer's curiosity and passion for making infrastructure better (frameworks, tests, tooling, etc)
• Advocating for better processes
• Advocating for better design practices
• Setting the general technical direction
• Assisting with feature-adjacent code migrations (i.e. we want developers to fix things as they go, but sometimes you do just need people who are dedicated to cleaning up things like linter violations)
• Working on the tooling (I feel people often mistake this point as the entirety of devEx as opposed to only one part of it)

It's not our place to decide what the code does, it's our place to steer how the code works and ensure that changes in the moment don't result in preventable headaches in the future, and also to ensure that foreseeable headaches in the future get resources and attention well before they become very difficult to resolve.

We also have a boundary with other enablement teams like platform and general IT support. Where we can be a bridge that guides developers on how to use the work those teams provide and let those teams decide the technical details of how those things work.

In a sentence, the way I see it is anything development based that distracts a developer from getting a feature across the line (tech debt, tooling/CI inefficiency, tooling deficiency, dependency management, framework design, code re-use, linter configuration, human processes, documentation, general developer practices) are foundational and part of our focus.

We aren't here to hide those challenges from the developers, but we are here to provide developers with the support they need to focus on the tasks they are given.