What’s a Developer Advocate? 10 questions to Guillaume Faas, DA at Vonage
Developer Advocate, does this sound familiar to you? You might have encountered this job title in Tech companies, but you didn’t figure out the whole picture and the main missions. To get answers, should we not directly ask our questions to a Developer Advocate? We did that with Guillaume Faas, DA at Vonage, a company providing a cloud communication platform.
Hi Guillaume, could you introduce yourself in a few words?
Sure! My name’s Guillaume, and I’m a .NET Developer Advocate (DevAd) at Vonage. I’ve been in the Software industry for almost 15 years, all of them in the .NET ecosystem. However, if I had to pick one milestone from my career, it wouldn’t be a role or a project but the acknowledgment of Software Craftsmanship. As such, we released open-source content around Craft (XtremTDD), such as a workshop and a knowledge base with my buddy Yoan Thirion. Nowadays, I still appreciate coaching and mentoring during workshops or ad-hoc events, even if it’s not written in my job description.
Let’s dive into the topic. What are your main missions as a Developer Advocate at Vonage?
Developer Relations (DevRel) is a specific field in tech where boundaries are only sometimes clear. There’s not a single & unique definition for a DevAd; the role may vary from one company to another depending on their needs. Our goal is to improve the developer’s experience regarding a platform or technology. We act as a bridge between engineering and the developer community. One thing is clear, though: we’re not Sales or Marketing. Developers are our top priority.
Being a DevAd at Vonage means I’m, first and foremost, a developer. I’m part of the “Tooling” team within the DevRel department which focuses on providing SDKs to facilitate the use of our communication APIs for developers. Of course, I’m working specifically on the .NET one. So, my role focuses heavily on engineering and coding. Our SDKs are open-source and open for reviews and contributions. On top of that, I also have to produce public content (talks, workshops, blog posts, documentation, etc.) to show what we do and how we do it.
How does working on an SDK differ from working on a product?
It’s a different context with different challenges and priorities. However, we still have to apply similar thinking to our SDKs since thousands of people use them in production builds.
For example, an SDK being “just a library”, we don’t have to handle a production environment. But, on the other hand, we can release whenever we want and as often as we wish to (#continuous). Our customers can then decide whether to upgrade or not.
We have to focus on different things. Developers use our SDK, so we have to ensure code quality, clarity, and readiness. The SDK should be enough to use our APIs, and the documentation should be helpful for more specific details. Also, we must be super careful with breaking changes since a single change could impact several thousands of developers worldwide.
Overall, I put my hands on a smaller stack but with more substantial attention and care.
It looks like quite a change compared to your previous positions. What attracted you to Advocacy?
I have focused on coaching/supporting teams and individuals for the last few years. I realized I was making a more significant impact this way.
Last year, we started working on “XtremTDD”, the workshop I mentioned previously. We had the opportunity to drive the workshop on multiple occasions (conferences, user groups, and a free online summer camp). Let’s be clear: I loved it! It was a fantastic experience. More than the workshop itself, I remember all the individual discussions afterward with participants. I’ve never felt so close to the developer community before.
I believe Advocacy’s a sweet spot and an excellent way to do both. Based on my work on the SDK, I am preparing a talk on introducing ideas from the Functional paradigm in an Object-Oriented codebase. I’m so excited about it!
Do you collect feedback from the users and some “Product-Owner” related tasks? (developers in your context)
We “eat our own dog food”. DevAds are the first feedback source when new features are released and the first API users since we have to implement SDKs to use them.
Then, we are a bridge between engineering and the developer community, and Developers are our “users”. As such, we can collect feedback from developers via our open community Slack, GitHub or at events. Our backlog contains both tasks from our product owners and the community. It’s up to us to define priorities following the high-level ones.
Working on open source is an enabler. The community sees what we’re working on, so it’s easy to have conversations with them.
Is looking for open-source contributors one of your mission?
Not really. Contributors are actual users of our SDKs. They usually contribute because they want to fix/improve a feature they’re using. It all goes through GitHub.
As developers, we often ask ourselves: “How much business value does feature X add to my product?”. Here, there’s no debate. It’s a change a user actually wants. So, we have no reason to decline them if they comply with our APIs or engagement. Of course, all contributors are always welcome 😉
What’s the impact of a DevAd on sharing/propagating good practices? And would Promyze be an alley for that purpose?
DevAds tend to be proponents of the industry, i.e. what are “good practices” within tech when it comes to ethics and culture, diversity and inclusion, etc.
There’s a clear difference between what I do now and what I used to do as a coach. I can’t support a team the same way; I have limited impact because I’m not directly spending time with them.
Still, I believe we should lead by example. Applying such practices, patterns and ideas daily is an excellent way to propagate them. Over time, the SDK will be a concrete representation of my beliefs regarding Software Engineering. Then, there are also our public appearances. I’ll be able to talk and express my ideas during conferences or workshops directly with the community.
What are the main skills required to be a Developer Advocate?
I’d go for Empathy first and soft skills overall. You need to be able to understand people’s struggles and put yourself in their shoes to provide tailored solutions. We are public figures in the Developer Community and are here to help them. As such, social skills are mandatory. Of course, technical skills are fundamental, too, as our primary duty is to write code. Our point of view needs to be legitimate, especially if we’re going to talk openly about it.
People can get confused between DevRel and DevAdvocate positions. Do you have some clarifications to add?
Developer Advocate is a specific role in the Developer Relations field.
DevRel is about building a successful relationship with developers. Having such relation is a win-win! There are four main pillars when talking about DevRel (names may vary from one source to another): Outreach, Community, Product, and Education & Support.
Do you have a blog or similar where we can follow your activities?
Sure! If you want to follow me personally, I’d recommend LinkedIn, where I often post about Vonage or XtremTDD. There’s also my GitHub account if you want to look at my repositories or my work on our .NET SDK.
Check our developer platform if you’re interested in our communication APIs. You can also ask us anything on Twitter or Slack. We’d be happy to connect.