From DevRel to Developer eXperience
At the time of writing this, the DevRel team at AxonIQ consists of four people (including me). We are two Developer Advocates, a Community Platforms Developer, and a Learning Experience Designer. The flat structure makes perfect sense at this team size. But our plans are huge, and four people can only cover so much ground. Clearly, the team needs to grow.
Instead of just rushing to hire a few more folks, I started asking myself how the team would look like in, say, two years from now? What roles and responsibilities are crucial and aligned with the company’s growth? How should those be organized? I like to have a plan. Even if only to change it later on. So here is one. And I’m going public with it. Perhaps it may help other folks facing the same challenge.
Understanding the domain
As with any project, I needed to fully understand the domain space I’m trying to model. I spent some time researching and thinking about it. The “What dev heck?” post I published earlier covers my findings and thoughts. Long story short, two things became apparent:
- Developer eXperience is the main domain
- If you have read my previous post, it should be obvious why that is. The consumers of the products and services AxonIQ provides are software developers. It is crucial to ensure they have the best possible experience. Our core principle, “We put quality first, always.” must also be applied to the interactions and processes developers go through.
- Developer Relations, Developer Education and Community, are the sub-domains
- While they all are crucial parts of the developer experience, each of those areas requires slightly different skills and mindsets. Organizing it this way helps understand the scopes and the relations between them. The diagram below may look like a corporate ladder, but it is not. It is merely marking the boundaries of the sub-domains.
The DX domain
The main Developer eXperience domain has one aggregate - the “VP of Developer Experience” (Yay! Corporate ubiquitous language 😉). Its primary responsibilities are around strategic planning.
The DevRel and Developer Education sub-domains have a lot in common, but no one can contain the other. Community is part of DevRel; as in our case, it fosters developer communities. The one around our products but also many related ones.
Here is what it looks like:
The DevRel sub-domain
Obviously, the most critical role in that scope is the “Developer Advocate (Java)” one. In my previous post, I have dived a bit deeper into what developer advocacy is. At the time of writing this post, AxonIQ’s offer serves best developers using Java or JVM-based languages; thus, the Java focus. As we evolve our support for other environments (like .Net for example), we’ll adjust the team accordingly. And of course, it is much better to have a relationship with people who speak your language and understand the local culture. Thus, we would love to have advocates in North America, DACH, and UK/Ireland regions (for a start).
The “Head of Developer Relations” is the same as “Developer Advocate” one plus the responsibility to plan and coordinate the activities of the whole team.
The Community sub-domain
The primary goal of the community team is to facilitate communication for 3rd party developers. Both among themselves and with the AxonIQ folks.
Two of the main tools in that space are the Discuss platform and a dedicated developer portal (still work in progress at the time of writing). The responsibility to keep those (and future ones) helpful and friendly lies in the “Community Platforms Developer” role.
Naturally, we provide the most incentives and amenities in the community around our products. But we understand all too well we don’t exist in a void. There are plenty of other communities and organizations our users belong to. We’d love to contribute to and partner with those to better understand the various contexts developers operate in. That is the scope of the “Communities coordinator” role.
Last but not least, we really like to show our appreciation to all the folks who help us. There are so many ways to contribute and support us. All valuable and much appreciated. The “Head of Community” role focuses on building and executing recognition and award programs. It also constantly monitors the community’s health and growth.
The Developer Education sub-domain
We have been investing a lot in training software developers. I don’t have the exact number of all trainees to date, but it’s in thousands. We also created AxonIQ Academy to bring the learning experience to the next level. To date, we have ~1300 learners there. We know from experience education is a big part of the developer experience.
Ensuring top-notch education programs is the “Learning Experience Designer” role’s ultimate responsibility. While the main focus is, of course, on the academy, it does not stop there. Everything, from reference documentation to tutorials to complete classes, falls in that scope.
I hope the “Technical Writer” and “Trainer” roles are self-explanatory. The only caveat is that we would like the trainers to share part of the responsibilities of the solution engineers (in other words, be a part-time solution engineers). Our learners appreciate practical examples and lessons learned from the battlefield. There is nothing like a trainer who can provide real-life context to a theoretical study.
What’s next?
Well, grow the team 😉. With that plan at hand, we are well prepared to search for and find the right people. Or so I hope.
By the way, if you can imagine a picture of yourself replacing one of those 
icons, do not hesitate to drop me a line at milen.dyankov[at]axoniq.io.
Why am I sharing this?
Two reasons:
-
it may serve as food for thought for other people building or growing DX or DevRel teams. If that’s what brought you here, please treat the above as inspiration, not a receipt. Consider the offering and the specifics of your organization.
-
It may actually help me find the right people. There is no way I could possibly explain all this in a job offer. My experience shows candidates have all kinds of different visions and expectations about the DX, DevRel, etc. Being transparent about it allows people to judge how our vision matches theirs. I do hope that will make the recruitment process a bit more efficient.