Reflections on One Year in as a Developer Advocate; Advocating for Developers

In my opinion, someone in developer relations serves as an advocate for the tech community within their company.

-Emily Freeman

For the final entry in my series looking back over my first year as a developer advocate we will look at what it means to advocate for developers. I would like to thank Emily Freeman for her blog article. Her article, particularly the quote above, led me to re-evaluate my role as a developer advocate. Initially I felt my role was to advocate for my organization (IBM), to developers. From reading Emily’s article, I appreciated that my position really has two roles; advocating for my organization, but also advocating within my organization on behalf of developers. In this article we will look at what each of these roles mean.

Speaking Developerish

Developer advocacy is in some ways a new field. While its roots go back over a decade, the field has seen a surge in popularity in recent years which has transformed how it is viewed. Going from a niche role, to a critical element in how organizations develop their products and services.

Developer advocates are critical because we can connect with developers in terms they relate to and provide information they need. I feel this is at times overly romanticized, suggesting developers are somehow “above” traditional marketing. Closer to reality is that often such marketing is tailored towards a different audience; managers and executives. Developers might care generally about licensing, costs associated with using a product, or if support contracts are available, but often aren’t interested in the details as that goes into decision making that is beyond their role. Developers are interested in how a product will improve their workflows or solve a problem they are facing. For that they need technical information; blog articles, hands-on tutorials, that step through what problem a product is attempting to solve and how to use it.

Developer advocates are able to answer these questions because they have an engineering background. Advocates have experienced those emergency pushes to production, worked with difficult to use or poorly documented products, or spent days reading through logs and code trying to find the root cause of a bug. While every developer’s story is unique, we all have shared experiences and advocates can draw on that experience to create content, deliver presentations, and talk with other developers using terms and language they are comfortable with.

For many hoping to enter the developer advocacy field, our first interaction with a developer advocate was from watching them give a presentation at a conference or meetup group. As Emily, from the title of her article says, developer advocacy is more than the art of speaking good, however presentations are important for two key things; informing developers of new tools or features and as an opportunity for connecting with the development community.

Community Engagement

Much in the way that, broadly defined, problem solving is central to the success of being a developer, a willingness to engage with the developer community is central to the success of a developer advocate. Building and maintaining connections is the means by which advocates can receive feedback on products their organization supports and how they can improve them going into the future. However the developer community isn’t just external, but internal as well.

Returning to Emily’s article, while developer advocacy is often thought to be an external facing role, the internal facing side is critical as well. When we receive feedback, we need to know who to channel that feedback towards. Here my experience might differ somewhat from many developer advocates. IBM, at about 400K employees, is roughly the size of a small city, this along with being a truly global organization, the “I” does after-all stand for International, means I will be in an endless cycle of learning of new teams and names. Still no matter the size of your organization, there are going to be teams and people you will need to know, don’t neglect the building of internal connections as you work to build your external ones.

A Canary in a Coal Mine Coding in Anger

Getting feedback from external developers is great. It is however a somewhat lengthy and infrequent feedback cycle. Agile, TDD, Continuous Delivery, these were concepts created to shorten the feedback cycle for development. Shorter feedback cycles lead to not only faster improvement, but the rapid iterative nature leads often to a higher quality product. As a developer advocate the way we can shorten the feedback cycle is by ourselves actively using the products our organization supports.

Sam makes a great point that you should actively use the documentation your organization produced when using your organization’s products. This is after all how you would want external users to engage with a product your organization supports. While a popular product will have its own share of blogs and other content on the web explaining how to use it, the documentation your organization produces should be seen as the best source for how to use a product. This can only happen though if that documentation is “tested”, i.e. actively used and then improved upon.

However I would also view Sam’s advice through the prism of a specific activity for developer advocates to perform from time to time. As I mentioned in the first article in the series developer advocates are often stretched pretty thin, so you should actively seek help within your organization. This helps not only to reduce your workload, but reinforce the internal connections you will need to build, and also as a form of feedback in and of itself. While working on some recent workshops while looking for help on how to use the products I would be using in the workshop, I was also able to give feedback on how they might be improved going forward.

Conclusion

It has been quite an experience looking back on my first year as a developer advocate. Outside of when I first started my career as a professional developer, where it took a couple of years before felt like I hit my stride, switching roles to developer advocate has also been a steep learning curve. When I went from developer role to developer role, it felt like I could hit my stride within a couple months of joining a new organization, as a developer advocate I feel like I am only just now hitting my stride a year in. While there is still a lot for me to learn and I look forward to doing some more articles looking back on two years of developer advocacy, I feel like I now have a much better idea on the road forward.

If you are thinking of entering, or just entered the role of developer advocacy I hope these articles have provided some insight on the work, life, and responsibilities of what it is to be a developer advocate. If you want to hear more, my DMs are always open on twitter @BillyKorando.