Every time I answer a question more than once I look at it as an opportunity to write a blog. Unfortunately, in this extended March 2020 we continue to live in, we are probably about 8 or 9 times past this point. But I digress.
Last fall I opened a position "Full Stack Engineer, Developer Experience" which got a fair amount of traction from people looking for their next (or first full time) full stack engineering position.
Nearly every candidate seemed to completely ignored the "Developer Experience" component of the job title, the most critical component. (I should also mention many neglected to read the job description and were surprised the initial scope of work included build pipelines.) Sometimes it's because they didn't understand (and didn't want to ask) and other times it was because they were so focused on the "full stack" piece it didn't seem to matter what they would be working on specifically. This made for awkward interviews where candidates seemed to be confused, asked the same questions over and over again throughout the interview cycle and I knew we need to make a change.
I appealed internally to change the title to "Developer Experience Engineer" and suddenly we were having more pointed discussions and questions about Developer Relations (DevRel) and Developer Experience.
I don't expect otherwise qualified candidates to have experience with DevRel or Developer Experience, but I do expect them to ask questions and have a passion for helping people. More on that soon.
How did I get to enablement?
Let me take a step back and link you to some of my favorite resources on the topic of DevRel:
- https://www.marythengvall.com/blog/2019/5/22/what-is-developer-relations-and-why-should-you-care
- https://developerrelations.com/what-is-developer-relations
- https://www.samjulien.com/what-is-developer-relations
I've had many roles within Developer Relations, let me list them in order for that sweet street cred:
- Community Manager
- Developer Advocate
- Senior Developer Advocate
- Director of Developer Relations
- Head of Developer Experience
What these roles don't tell you is I've always leaned more toward the Developer Experience and enablement side of DevRel, helping developers, but now I have this nice title that makes that apparent. More about that breakdown between DevRel and Developer Experience from my manager @mary_grace in another one of her blogs.
My focus in the enablement space stems from this deep passion to (hopefully) prevent developers from going through what I went through earlier in my career. You see, prior to finding DevRel and Developer Experience, I was a full-time engineer, but even that was a bit skewed because I almost immediately found a role where I could help (enable) other developers internally. I had a high tolerance for hacking together solutions and tenacity to fight tools that we had no decision in adopting but had to make work.
Not everyone has the personality and drive I do and not every organization can enable a person or team to devote hours of their time to not only making something work but turning around and telling the rest of the organization how to make that thing work efficiently. It's why consultants are paid hoards of money and agencies charge a premium for training. And at the end of the day, you should be asking yourself "is there an easier tool to work with that does the same thing?" Because the answer is probably yes. But sometimes the choice is not up to you and you have to, yes, make it work.
Enter Developer Experience
With a focus on enablement, the goal is to craft excellent experiences for developers when working with your tool/product/framework etc. No fighting, seamless onboarding, and quality educational content to get that done.
Developer Experience is to developers as User Experience is to users.
Some of the most meaningful work I've done in my career is handing a developer a code snippet and watching them be enabled. It's magical.
Developer Experience includes:
- documentation
- best practices
- guides and tutorials or how-tos
- SDKs, API wrappers, client libraries
- code snippets
- developer tooling & recommendations
- open source ecosystem enablement
- turning community feedback into action
But internally, what you may not see is Developer Experience also includes:
- goals around reducing support tickets (How Do I or one-touch tickets)
- internal enablement
- technical writing reviews
- comprehensive UX feedback
- developer tooling infrastructure
- product roadmap influence
- trying not to explode from hoards of feedback and tech debt (lol... but seriously.)
Developer Experience at Camunda (My Team)
Just like with developer advocate roles, you'll see each job description for Developer Experience looks wildly different. Some of these roles fall in product management, engineering (mostly internal developer experience teams), DevRel, or even marketing (product marketing mostly).
My team sits in DevRel so my scope and items I listed out above may be different than the what you'll find in a team seated in marketing or (internal) engineering.
Currently my team includes a Technical Community Builder, Technical Writer, and me. We are hiring a Developer Experience Engineer, which prompted this blog. My goal this year is to scale out the team to support large company initiatives, which is a vague way to say we have too much work on our plates to be as focused as I'd like us to be right now.
The really cool thing about Developer Experience is the needs of the community and company are always going to be changing, which means the work you do quarter by quarter or year over year will be different.
My current hiring need closes an existing gap today - finding someone to own documentation infrastructure (pipelines, build process, framework plugins, etc.) and give it the focused love and attention it needs. As hard as I try, I'm wearing too many hats and my time is too fractured so this actively takes work off my plate.
But just like I mentioned, things are always going to change. Once we get some really good attention on the docs infrastructure, then we can look at other Developer Experience enhancements like better integration with dev tools like VS Code, Postman, GraphiQL, and other things developers honestly expect when working with new products or frameworks.
All of this to say, if you are interested in directly making an impact on the lives of developers, Developer Experience is a great place to be. Consider it for your next role if you are looking to still write code but also expand your reach, leadership, and product knowledge.
So maybe now I can stop answering the same question over and over again just link to this blog. 😅
Title photo by John Schnobrich on Unsplash
Top comments (15)
Great post! I started in DevRel ~ 1.5 years ago. This post is very accurate, especially around sharing community feedback!
Like you mentioned, I have noticed some "Developer Experience" teams (often in the enterprise) focus on supporting their internal dev teams instead of the outside world.
A lot of the activities are similar (demos, office hours, gather feedback) but focused on an internal community instead of an external. Do you find yourself doing both in your role?
Yes! How I usually try to frame things for myself and my team currently is that anything we do internally we should approach with the idea we will take it external in some capacity.
Sometimes the internal enablement piece is a critical component of "winning" priority or helping the company understand the business reason or value.
That's really helpful!
Hey, I really like how you went full-send with this post. Currently, I am focusing on the usual full-stack engineering but, I feel I can provide value as an advocate (not particularly a devrel) somewhere in the future, mainly because it appeals to me and my communication skills are reasonable considering my background. Although, I currently lack professional experience with teams/organisations. You've broadened my view , in one post. Very thankful for this.
Full-send is pretty much 100% aligned to my personal brand. Thanks for your comment!
This is great. Adding to your list! DevEx should also include designing and battle-proofing workflows, and striving for creating a unified experience, that is, standardizing and making it easy to do the right/secure thing
Hey, how would you convince the management of a company that is quite new to development to create this position and allocate budget to it?
Big ask! Is this for internal or external?
Either way I would start by presenting a data-backed case.
Would be for internal
You can use what I mentioned above along with sprinkling in projects with the current dev team, but be super careful with scoping - "we can do this with x time and x people, but if we had y time and y people we could do this much more".
Hello from Austin
👋 What's up! Stay warm this week!
I was just having a conversation about this exact topic and specifically, the differences between developer experience and developer relations! Now I can link this blog instead :) Haha. Great post!
I would have rambled less but I hope it helps!
Hi amara! Would like to connect with you about your experience in DX!
Would you be open to a quick 20 min chat next week?