Amara GrahamEvery 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
