A couple of years ago, I attended an onboarding session with Andela for their Student Ambassador Program. It was quite an intense two-day program that involved understanding Andelan values and deciding on the metrics that would show us how the communities we were building were growing. For the first time in my life, I had to keep in mind how my activities in the community impacted the company I was working with.
Both the company and the ambassadors had the same goal: to help grow the skills of the developer community. For us, as the ambassadors, the overall skill growth in the community was key. The company, however, was focused on getting more developers who could later be recruited into their fellowship program. That said, the biggest question for us as ambassadors was how we were going to make these goals a reality.
A key component of achieving our goal was to build great teams. Finding that dream team to deliver our ROIs became a critical mission.
I learned something during my onboarding sessions that has stuck with me over the past several years; I believe it could be the secret sauce to building out a great team and I am going to share it with you now.
There are three key roles you’ll need in your dev rel team:
With these three characters on your team, you will have the right mix to pull off some wondrous dev rel adventures. If you’re just starting out, you’ll probably need to perform all these roles yourself but as you look to grow your team, try to understand where your strengths lie and see how you can fill any gaps with people who can cover your weaker areas.
Next up, we’ll break down these three characters and see what they bring to the team.
Just as the name suggests, these are the people who stand on stages and preach to thousands of developers about a particular tool or product that makes building software worthwhile. They are the PR face of the company and attend various conferences and meetups to share information about a product, collect first-hand feedback and show off killer slides with memes.
It’s one thing to be on the stage and a totally different thing to hold the fort. Developers need the materials behind your product – from documentation to quick start guides. This is what facilitators and educators do; they provide the backbone support for developers to enable them to find their way around your product.
You’ll also find them running technical training events and speaking at workshops and meetups. They may not be the most outgoing of the bunch but their product knowledge and knack for making complex topics digestible is priceless.
These are the hardcore community folks; they know how to bring developers together. For some, it’s almost a science. They act as fuel to the community that you’re building around your product – maintaining peace and prosperity in the community, making sure that any issues raised are sorted out ASAP and rewarding the various great people in the community for their contributions.
Having the right mix of super technical personalities who can teach, and happy-go-lucky personalities can help bring balance to the team. This sets the pace for the kinds of activities that the developer relations department is often participating in which, according to Matt’s four pillars, includes:
As a community manager and organiser, you’ll often find yourself involved in outreach and community events, both offline and online. Alongside the community managers are the evangelists, who are also heavily involved in the community events, including the meetups and conferences.
Evangelists, however, also need to be very familiar with the product as they are the first point of contact for new developers and businesses that may want to integrate with it. They will often serve as part of the pre-sales section of the funnel. To complete the cycle of collecting live first-hand feedback and delivering the feedback to the product teams, evangelists get back to the community with answers from the product teams.
Developer educators, or rather, facilitators, end up working mostly online but can have offline interactions, especially with customers who are looking to train their developers on your product in-house. Most of the work involves maintaining the educational content around the product.
It’s easy to see how to structure your departments as well as how each role feeds into the core pillars of developer relations. Building a team around this can help make sure everyone understands what they need to do as well as setting the right metrics for each team or individual.
This article is written from my own personal experience and what I’ve seen in bigger teams than the one I belong to. We are a three-person team who exhibit these qualities; it’s clear to see how understanding our strengths and personalities has helped us align our goals and execute tasks effectively.
The real key to building a great team is finding people who understand one another. It might go too far to say that this is the golden ratio of building the ultimate dev rel team but it’s a place to start.
The next question we should answer is: how do you resolve conflict within dev rel teams? I’ll address conflict resolution as a team in the coming weeks.
Can you make good release notes by collating your commit messages? Eva Parish argues not.
Can negative feedback from customer satisfaction surveys have a positive impact on your developer experience?