I've received a ton of inbound requests to share my expertise in the Developer Experience (DX) space. It's clear that this has emerged from the DevRel space as a key component of a successful DevRel program and continues to become more mainstream.

To date myself a bit, it feels similar to what was happening in UX ~10 years ago or even agile with large corporations hiring agile coaches. As an industry, we (the royal we) realized it was easier to have a dedicated person or team to lead the company in adopting a focused mindset on these topics, even if the goal was to have it deeply engrained in the company culture. Keep that last bit in mind as I continue.

What Product Engineering Teams Do (and maybe don't do)

Would it be a blog of mine without some sweeping generalizations?

In the DX space, much of this work fell (falls, honestly) to the product management and engineering teams (aka product engineering for simplicity), which inevitably creates some tension with different motivations.

Engineering teams could (broadly) fall into two camps - just get it done or get it done empathetically. Empathetic approaches may be slower, require more analysis and testing, but that doesn't make them worse than the just get it done approach. It makes them different. It could even possibly prevent end-user visible tech debt.

Going back to the UX example, you can have engineers who are passionate and knowledgable about UX, but they may just not have time or support to view the UX at a more holistic level. Your UX may still miss the mark.

Product management (PM) teams want to make the biggest impact with the least effort to land (the biggest or most plentiful) customers. It's not exactly fair to boil down all PMs motivations to this, but again, they have my not have time or support to view this at a holistic level, particularly at companies with many PMs across many products.

Using agile as an approach, if every team does agile in a different flavor because it works best for that team, it's no wonder you have inherently siloed teams, despite each team being iterative.

DX teams can take the more holistic yet focused approach, using empathy to drive priorities across all three of these teams.

Would it be ideal to bake this kind of thinking into product engineering teams? Absolutely! But these teams do SO MUCH these days already. They may do a great job for their product or with the high-level details, but the finer details can get lost and developers will pick up on that! And they will drag you for it.

How I Think About Developer Experience (DX)

All of this leads me to the three questions or areas of focus I like to use when thinking about DX:

1. Are developers getting what they need?

2. Are developers getting what they need efficiently?

3. Could you optimize the efficiency?

Product engineering teams may be very good about doing the first item, but 2 & 3 become challenging if a culture of DX doesn't exist. Additionally and the bigger point I want to drive home is team are busy and may have conflicting motivations to evaluate these items while still doing all the other things required of them in their day-to-day.

Item 3 really embraces iteration and fits nicely into an agile mindset, but only after we have a handle on items 1 & 2. So in that sense, these areas of focus build off of each other.

How I Put This Into Practice Today

In my current role at Camunda with my existing team, we are firmly in the first item with some signs we can move to item 2 - we are identifying gaps in documentation, gaps in API reference expectations, gaps in contributor experience, and ease of use of projects in our surrounding ecosystem. This is a lot! A lot of gaps! And we have a fantastic culture that includes product and company values around developer friendliness. And we still have gaps!

I hope to spend time later this year exploring how we get to item 2 & 3. Does that include growing the team? Does that include specific themes to drive clearer progress? Or does that simply require acknowledging where we are at in the product lifecycle? Personally, I really enjoy the challenges that come with 2 & 3 and I'm eager to get there. But the gaps!

How Could You Put This Into Practice Today?

Whether you are on a dedicated DX team or not, these focus areas give you opportunities to incorporate DX practices into your day-to-day activities, but again, you may not have the time and support to fully embrace them. And that's ok!

As a developer or product engineer, having this mindset should never be considered a disadvantage just like having a UX-mindset or a security-mindset is encouraged and makes you a more well-rounded developer.

Building or designing an API for example without considering the end-user (a developer!) will inevitably result in rework, or worse, breaking changes further down the line. Taking a DX-minded approach can help future proof and avoid tech debt. And wouldn't a world without tech debt be nice?

But If Everyone Everyone Adopts This Mindset, What Happens to DX Teams?

Raise your hand if your company actively requires you to do security training but you are a security-minded company.

Raise your hand if your company embraces a UX-mindset but you still have a UX or design team.

I'm not terribly worried about this, and if anything it makes my job easier but doesn't necessarily change the workload.

If everyone is in a DX-mindset, they can handle item 1 and I can exclusively focus on 2 & 3, which again I really enjoy. DX teams can switch from gap addressing execution mode to full R&D and bleeding edge mode. Then maybe I'll stop complaining about GraphQL and figuring out how to train developers from SOAP or REST backgrounds. Because, you guessed it, it's a gap!

Photo by Stefan Cosma on Unsplash