Lessons I learnt from my first year of building a DevEx Team
I've been running a DevEx team all of 2025, and I really wished I had some sort of guidebook when I started. And then last week, Nicole Forsgren and Abi Noda published Frictionless. A handbook for starting a DevEx team. Where were you at the start of the year?! At least I can compare notes. Here's my attempt at trying to process everything I learnt about DevEx this year.
The need for DevEx is super clear
Starting the year I knew DevEx was important. I don't think I realised how important. When I started the team, our goal was to reduce developer friction in their day to day workflow. The theory was reducing friction equals happy devs. And happy devs are less burnt out, more satisfied in their role, innovate faster and deliver more.
Now that my company, and seemingly every tech company, has adopted AI the need for good DevEx is even greater. With AI tooling, devs are able to create faster than ever. But this results in problems elsewhere. Sure you can push multiple PRs, but do you have people to review them? Do you have confidence that your changes aren't going to break production? How fast can you even deploy the multiple PRs you're pushing? It's clear that writing code was never the bottleneck in the first place.
My takeaway from the year is that I'm doubling down on the need for DevEx. By improving DevEx we improve so many other parts of the company. As hard as it is to quantify. Forsgren and Noda say it best:
Poor DevEx creates a competitive disadvantage that compounds over time.
Defining what DevEx owns is hard
Even after a year I'm not sure I have a good answer to this question. Reducing friction for a developer could come in many forms. From low level infrastructure changes, like setting up a staging environment. To high level component library to help devs build UI's faster. Where does a DevEx team sit in this range?
The best answer I've come up with is that DevEx should be an organisation. It should have multiple teams specific to certain developer workflows e.g. CI, Monorepo tooling, Language upgrades or tooling, and best practices & learning. It should also build on top of infrastructure tooling created by Platform Engineering teams.
Frictionless also touches on the relationship between platform engineering teams and DevEx. Platform engineering builds the infra, shared tooling, and services that enforce best practice and abstract away complexity. While DevEx teams take a broader view of friction across the entire developer lifecycle. A DevEx team may address problems that no platform solution can solve.
In my experience, I find this boundary not as clear cut. Especially as a growing company, platform or DevEx teams may not have the capacity to take on particular projects. And some projects that should’ve been on one team get started on a different one. This is where the lines get blurred. We do our best, is my current answer around ownership.
DevEx should operate like a product team
Devs are our customers. As an internal team, it feels strange to force product thinking. But I've found that having a strong product roadmap and vision for DevEx gives us more guidance and flexibility into the solutions we build. Instead of fighting fires across multiple dev teams we can think about solutions that work long term. We fix what the dev is really asking us to fix.
Also a note from an Overcommitted podcast episode with Kate Holterhoff. There is a wide range of “developers”. Or more specifically, people that use DevEx solutions. From feature teams, to quality engineering aka quality assurance teams, to even non-technical folks like designers or PMs. Treating DevEx like a product gives us space to think about different personas.
It also means, we need to stay close to our customers. For our team, we focused on talking to devs, observing them use the DevEx tooling, and surveys to gather feedback. I have noticed that if there’s some friction a dev will most likely try to solve it by themselves and move on. So it can be hard to know that something is actually wrong until you go talk to them.
Finally, it should go without saying, but a DevEx team should never adopt an us-versus-them mindset.
Staffing DevEx is an interesting challenge
I started this year thinking that DevEx team should consist of full stack developers. Boy was I wrong. My assumption was that our devs are full stack so we should have a team of full stack devs to support them. But it turns out there's so many parts to DevEx, that we need specialists. And that can be hard to hire for.
Something our team has started doing is offering rotations from feature developers. We work together to come up with a project that they're interested in, and something they can finish during the rotation. The idea is that they're getting to fix a pain point in their workflow, while also being able to affect change across the engineering organisation. And the DevEx team gets to tackle a feature that devs are asking for and can maintain this feature in the long term. Win Win!
There's a lot I'm still figuring out. Like, how much abstraction is too much abstraction? Or what are the right metrics to gather? Or what is the process of telling devs about DevEx changes (Slack sucks for announcements)? Still, it's been a fun year on the DevEx team. Lots of highs and lows and lessons along the way. If I could take one thing away from this experience, it's that I love working with devs. These are my people.