Today is my last day as a Developer Experience Engineer at Camunda. I'm moving on to something different, which I'll share at the end of this article.
This is the only job I've had working in "developer experience" and I want to share a retrospective of what I've learned.
What even is a Developer Experience Engineer?
When people would ask me about my job for the last few years, I found myself having to explain more than any previous job I've had.
Beyond having to explain "developer experience" as a field, "developer experience engineer" means something different everywhere. There aren't many of us out there — but every one I've met did something different than me. Some work on docs (like me), some work on SDKs, some work on developer tools, some work on infrastructure, some attend conferences and give demos and talks.
My flavor of "developer experience engineer" was documentation focused, especially on infrastructure and the collaboration experience. To be honest, I would title my role as Documentation Engineer more than anything else. My boss and I talked many times about things I might someday do outside of docs infrastructure. Whether through self-selection or through selection by the massive amount of documentation support our team does, I rarely did work that didn't eventually trickle into the documentation.
Maybe this inconsistency doesn't matter much. It definitely illustrates a field that is young, and very certain about its importance, but very uncertain about how to describe itself. Like developer relations...but usually not under the marketing umbrella, so probably less volatile.
This inconsistency also means that one job description for a Developer Experience Engineer (or similar) is vastly different from another. I'd describe it as each role having different targets for "developer experience." Maybe this isn't different than any other role — a "product" engineer could work on a lot of different things — but the angle of it seems different, and I think it actually represents an improvement in how we think about job descriptions.
If I'm looking at Product Engineer jobs, the differences are usually a matter of (1) what's the industry, and (2) what's the tech stack. The consistency across all of them is that I can write code.
For Developer Experience Engineer jobs, the differences are mostly which surface you will be impacting, which is already more interesting to me than industry or tech stack. Beyond that, the consistency across all of them is that I have interest and skills in removing friction, increasing efficiency, and working directly with users.
I may be assuming that consistency based on my opinion of what it means to be a DX engineer....but it's a really helpful framing of a job description. I'd love it if more job postings described in more detail things like culture and values. DX roles I think do this better than most, because the role inherently requires certain values that I am drawn to.
Developer experience is glue work.
Here's a fun story about the (formerly-named) Developer Experience team at Camunda.
At an all-hands in-person event, in the span of one day, I observed each individual member of our team do the following:
- Notice something out of place that no one else had noticed. A pair of glasses sitting on an empty table; a dropped sweatshirt; a hotel key left on the counter where a conversation was just walking away.
- Immediately adopt the misplaced item as their personal responsibility.
- Not rest until they had found the owner of the misplaced item.
After I realized I had noticed every one of us do this same thing, I laughed. This was 100% exactly who the Camunda DX team was, 100% who each member of the Camunda DX team was, and 100% the essence of developer experience work. Every little thing that gets dropped or left behind — we notice it, we're watching for it, we're trying to help fix it.
Developer experience is focused on identifying where the seams are, how things will fall into those seams, and how much impact this will have on the person it happens to. It's glue work.
As Tanya O'Reilly describes beautifully in that linked talk, glue work is unrecognized, unnoticed, and unrewarded. No one notices it when it's happening; everyone notices when it's not.
I am passionately drawn to glue work. I've definitely been unrecognized, unnoticed, and unrewarded because of this passion, though obviously less impacted because of my gender.
When I started at Camunda, I convinced myself that having "Developer Experience" in my job title was rewarding me for glue work. I had a title that said I get to do glue work every day, and get paid for it!
I'm not going to say this isn't true, but I will say that it doesn't exempt this work from being unrecognized, unnoticed, and unrewarded. It's still glue work. Within my team, obviously we see each other doing this kind of work and we value each other. Outside of our team, that seemed less the case.
Are we engineer or are we product manager?
In my time as a DX Engineer, I felt like I was as much a product manager as I was an engineer. This might be more a statement about our team culture than about developer experience itself.
I've never had as much autonomy as I had at Camunda. We subscribed to the DRI (directly responsible individual) concept, and it was more effectively implemented than anywhere else I've worked. The phrase "disagree and commit" meant more than "disagree and argue until everyone commits to the loudest idea," as I have experienced elsewhere. Because of this autonomy, I learned to manage my backlog ruthlessly.
On the bright side, this gave me good practice prioritizing (and reprioritizing) my work. I learned to identify when I was working on the wrong thing, to shift quickly to work on the right thing, and to communicate my priorities and status outwardly and upwardly.
Related, I learned to plan for interruption. Not just sometimes, all the time, and regardless of project size. It was critical for me to identify the milestones and waypoints ahead of time, and to keep an exit handy at all times. This was only attainable through effective breakdown of work. I think I went into Camunda pretty good at breaking work down into smaller pieces; I came out of Camunda significantly better at this. This is the most important set of skills I'm taking away from this experience.
Another positive is that my backlog proved to be an effective tool to track my successes. Writing a performance self-evaluation has never been so easy. I had a literal list in GitHub of accomplishments over the previous 6 months. At a personal level, this literal list of accomplishments is also helpful for curating a brag doc or my ego-feeding browser start page.
The negative side to "owning my backlog" is the confusion I felt about my role. Was I an engineer or a product manager or something in between? Probably something in between....and that is great, for the skills I built owning my own backlog....but it also felt like it detracted from my engineering skills at times.
Documentation requires a lot more SEO work than I expected.
Even today, with Google effectively hamstringing its search product, and LLM-based search providing a better experience than traditional search engines, documentation SEO is critical for a stuck engineer who needs a relevant search result.
During my time at Camunda we experienced the worst possible outcome of mismanaged docs SEO: complete removal from the Google search index. As recently as two weeks ago, I was reviewing redirect rules to preserve URLs of documentation that had moved. I spent a non-trivial amount of time in the past few months working on URL validation.
I have learned enough about SEO in this job to recognize that I do not know very much about SEO. I'm not sure how transferable that is, but it is interesting, and it weirdly scratched an "obscure trivia" itch for me.
What am I doing next?
I'm taking a few days of funemployment to visit my college roommate. This year marks 30 years since we met each other in Watson Hall in Stevens Point, and it felt like a good time to visit him. Here's a print I made to bring him — he's a fish guy.
Next week, I start as Lead Full Stack Engineer at LeanScaper. I'll be working with some old friends. Among other product engineering efforts, I'll be teasing out design system direction with the design team. I'm excited to work with a team that I've watched crush the startup game for years, and get back to building things.
I've been asked if I would do developer experience work again. I would! But I also think I have lots of developer experience learnings and principles that I can apply to product development, and I'm excited to see how that goes.