"If your team has developers, you have a Developer Experience."

Whether or not that experience is a pleasant one, where happy developers get their best work done, that is something you can influence.

April 6th a panel discussed the topic of DX, at the Container Solutions offices in Amsterdam:

• Sarah Gruneisen, Director of Engineering at Novoda and founder of Avagasso Coaching, whom I know mostly as one of the (former) organizers of Devopsdays Amsterdam.
• Janna Brummel, SRE senior engineering manager at WeTransfer, Co-organiser of the Site Reliability Engineering NL Meetup group, former Engineering Manager of QA at NS (Dutch Railways) and former Chapter Lead of SRE at ING.
• João Martinelli, Scrum Master and Senior Software Engineer at bol.com.
• And finally the host, Cari Liebenberg, Cloud Native Engineering Lead at Container Solutions.

DX is reading the room

While IDPs (Internal Development Platforms) and solutions like Spotify's Backstage play a role in developer experience, it does not DX make.

• DevEx is about removing friction, appropriate and smooth access management, about promoting the golden path.
• DevEx is about empowerment, Engineers knowing their impact, understanding why they're working on a story. Understanding the business' objectives gives them autonomy.
• DevEx is seeing the engineers as end users and prioritize their experience like you would your customers'.

DevEx ultimately is reading the room.

Roles and responsibilities

"We set up a DevEx team, why are you not happy?"

DX is a subset of DevOps, according to Sarah. And like with DevOps, there's a misguided focus on tools. That said, EMs (Engineering Managers) should totally act when tools are holding their teams back. When they don't have budget, they should instead signal their leadership.

You don't need a Designer of DevEx, just like you don't hire a DevOps Engineer (although, many of you do, but you're wrong). DX is a shared responsibility, but someone in the team should step up to support the effort. "You can't just appoint a person to henceforward care about DevEx."

Installing a separate team for DevEx signals that the company takes the topic seriously, but risks it becoming an ivory tower. Sarah prefers a hybrid model, and Janna would like for everyone to "have their DX glasses on". "Scrum masters can get together as people with the same "guild" (or: community of practice), but are otherwise embedded in their teams", says Sarah.

Measuring DevEX

A metric for DX is retention (or: quiet quitting as one attendee mentioned). Internal surveying whether employees would recommend your company as a great place to work, and continuing to measure that so you have a benchmark, is another way.

The DORA metrics are indicative of DX, according to Janna, or: when someone not from her team can help another engineer find workflows, or ask specific questions because the general knowledge is there.

Looking at onboarding, Time to First Commit could serve as a measure. How long does setup take, how prepared are you for a newcomer joining your team? Do they get their device prior to starting?

One attendee mentioned that using open source components over commercial tools can speed up that time to productivity, since there's an abundance of support online (community, StackOverflow, etc...). Which... maybe, but I don't want to start a rant rn.

What's next?

Leaving the meetup, a colleague and I compared notes. He, an Engineering Manager, mentioned: "I can listen to my developers all day, but at a certain stage of your company the stuff they're going to complain about is systematic - issues bigger than any one team: tech debt, CI pipelines taking too long, inconsistent code quality... I need to understand how to convey DX to SLT (Senior Leadership Team) in a way that it can compete with all the other priorities."

Maybe DX needs its own flurry of business books and conferences that made DevOps mainstream?