Next April will mark the second-year anniversary of becoming a developer advocate at IBM. Developer advocacy is an interesting role to work in. It’s a mix between technical sales, event marketing, community building and teaching. As a fairly fresh developer advocate, it took me a long time to figure out what this role entails, what my boundaries are and how I can make sense of the constant changing nature of the role; and I’m still learning. This article is all about those findings.


I did not come up with all of these findings by myself. Some of them are from books, some are light bulbs from discussions with my family and friends, and some are people’s opinions after listening to my rants. Thank you to my support structure for being there for me when I need them.


This post is about my views and my perception of the International Business Machine and its processes. It does not reflect the views of my team, my employer and of IBM.

Why Developer Advocacy at IBM? #

My team lead describes the primary focus of this role as to “drive mindshare, awareness and adoption of IBM technologies. That’s a rather broad scope don’t you think? Instead of describing how to perform this role, he has set a hill statement and leaves the implementation to the team.

Back when I first started in April 2019, my colleague shared with me an article that segmented out the different developer advocate job responsibilities: to share the latest and greatest technologies from the company at conferences and events, to organising and supporting events, to becoming a support engineer that helps customers bridge the gap between demos and production. There are more than one job responsibilities in that sentence alone. Each responsibility could be performed by a single person full-time. This led to more questions. How can I manage my time, define my own responsibilities and measure success over time?

Developer advocacy isn’t new. How do other companies do it? In the book “The Essential Guide to Developer Marketing” from SlashData, Jo Stichbury separated developer advocacy into three main roles:

  • Developer relations: build credibility, trust and influence, the person in this role evangelises for the company by taking on the role of a community manager, representing at events, blogging and on social media. Developer relations is also about advocating for the external developers, representing them by giving their feedback to the company’s technical teams to influence the product roadmap and strategy.
  • Developer marketing: encourage third-party developers to learn about, try, adopt, use and contribute to a software product. The person performing this role is able to communicate about the products at a detailed level without marketing jargon. Developer marketing’s activities include creating a developer marketing strategy, segmentation of developers into personas, organising events, steering developer rewards programs and innovator funding or incubation programs.
  • Developer product engineering: build and deliver SDK or API to third party developers, provide technical help, write blog posts, create content for webinars, videos and training courses.

Scanning Australia, I could start to group and put different companies’ advocacy teams into different bins, i.e., purely my opinions. Twilio’s and Auth0’s developer advocates seem to do 1 and 3, leaning to 3 as they have a smaller set of tools. Red Hat, definitely number 1 and 2. Here, we can summarise that number one - developer relation - is an assumed responsibility. You cannot create a community without trust, influence and credibility. In 2019 and 2020, I could see myself doing a mix between all three but leaning towards 2 as we organise Call for Code hackathons and external events. What is developer marketing and how is it different from marketing? (Hint: they are aimed at different audiences.)

Throughout its history, IBM Australia has maintained strong relationships with IT executives, such as CIOs, CTOs and CISOs. Marketing and sales focus on the executive level, thus our marketing content is geared towards that demographic. Chances are high though that such materials did not tell you what the underlying technologies are, how you could integrate that into your existing product lines, what the support structure is, what are the key features that makes this product superior to its competitors.

As a side effect of this style of engagement, developers tend to not know about IBM’s technologies, not because the technologies cannot do what they want, but because they do not know what it actually does from the marketing materials. Developers value the opinions of others like them and want technologies that is supported by a community of developers like them. They want to know when things go wrong, there’s a place they can get help and find answers easily because the community is established and thriving.

This is where developer advocacy would come in, to create content, write documentation, create webinars and help developers from the community succeed. Right? Nah, I wish. I do those after hours. For my day job, I do something else completely different.

What is Developer Advocacy at IBM? #

At IBM, there are two developer advocacy teams - community and client. Each have different responsibilities. The community developer advocacy team builds communities around IBM technologies, organise events and performs the responsibilities of the developer marketing role. The client developer advocacy team supports client accounts, providing enablement workshops and collaborate with client and account teams to create proof-of-concepts, performing the responsibilities of a developer product engineering team. On a global scale, each city has two dedicated developer advocacy teams: one for community and the other focuses on clients.

In Australia, my team’s metrics focus us on providing technical help and training content to client developers, where community focus is a side project. However, without developer marketing, in my opinion, the core values of developer advocacy are lost. Examples of companies that have great focus on communities are Salesforce and Atlassian, and they grow exponentially yearly.

In her book “The Business Value of Developer Relations”, Mary Thengvall talked about how to build and maintain positive relationships with your developer community, and also talked about the many different dotted lines of reporting for a single developer advocacy team.

IBM Developer has always had a focus on the products, particularly on IBM Cloud. After the Red Hat acquisition in 2019, we shifted our focus to OpenShift and all the different Cloud Paks - you can think of them as packaged IBM middleware that runs on Red Hat OpenShift.

I personally have always found it stifling to just advocate for IBM Cloud. Aimed at the enterprise, IBM Cloud aims to be an open platform. This has the advantage of reducing your vendor lock-in risks. On the down side, as a developer working on IBM Cloud, you need to know different technologies well and able to context switch as you integrate them together. By shifting our focus to a software portfolio on Red Hat OpenShift, we have more freedom of what content to create, which products to suggest to truly help a client solve their problem.

At the same time, this pose questions for 2021: how can I keep my skills sharp and specialise across the vast portfolio IBM has? How can I build effective rapport with developers if I have not felt their joy and pain using these products? Will my team get more dotted reporting lines to product teams?

How to sell to developers? #

It’s a myth that you can’t sell to developers. You can sell to developers, but not the selling in exchanging monetary values for products. We’re looking for time or effort, to help our fellow developers get the best bang of their time-bucks or effort-bucks. In his book “Driving Technical Change”, Terry Evans groups developers into seven skeptic types. Four of which are the uninformed, the herd, the burned and the time-crunched. These are the most frequent skeptic types I’ve met thus far.

The uninformed are the most common. People are busy. They may not have time to catch up with the new releases or have other priorities. Did you know that Red Hat OpenShift 4 can run on IBM Z, albeit a subset of the functionalities? Now you do. People go to meetups and hackathons to network, socialise and more often than not, learn new things.

The burned are skeptics that tried to use a technology or tool but were let down. I personally identify the most with the burned skeptic group. IBM has a lot of offerings - both software and services. Some of them are worse than others. Some offerings have competing offerings even within IBM. To remain authentic, I don’t advocate for the offerings that I don’t believe in and make it very clear that I will never advocate for a particular offering until it can be shown that it works. The herd describes a group of people who don’t know that they could impart change, or maybe work is a job for them and that they don’t care enough to impart change. Lastly, the time-crunched are busy people.

For the longest time, I struggled with IBM Developer events. Unlike the varied and interesting contents, I encounter at language-specific meetups, we would have contents that talk about, in my opinion, the most straightforward, simple, easy-to-do use cases ever. It was even embarrassing to hear about these topics from IBM. Coming from the consultancy side of IBM where there were rarely any simple projects. They may sound simple at first, but it would soon be filled with intentional and sometimes accidental complexities. I was perplexed and troubled by this approach. How can we show that IBM is an innovative company when all the examples we show from developer advocacy standpoint are hello-world samples? It wasn’t until Code@Think 2019, when a gentleman came over and asked me an obvious question that blew my mind “can Docker containers run on Kubernetes?”.

There are different developer personas or skeptics as Terry Evans puts it. As time-poor doers who solve problems, developers need to be shown how problems can be solved with these different and new tools, and how much easier it could be. A compelling use case presented with passion and authenticity goes a long way with well-rehearsed demos. In essence, know your audience and work to your strengths.

Where we are now and what’s in for 2021? #

2020 has been challenging. Engaging purely through digital channels means that it’s harder to grasp people’s attention and more taxing on each and everyone of us. After these oncoming two years, I supposed I have learned what I like to do for this role. I like to create content, write documentation and develop use cases that integrate different technologies together, which shows the best of these shiny toys.

Personally, I think that each IBM product ought to have a dedicated developer advocate. The technical sellers sell the product. The dedicated developer advocate manages the communities around the product, the latest and greatest advances, and provide help for specific products. As for my team, we collaborate with those product-team advocates to build greater communities.

2021 will be very different. There will be changes to the developer advocacy reporting structure and who we will be supporting. Ultimately, my role as a Developer Advocate stays true to learning and enabling others on the technology that excites me. I will do so in working with clients both old & new, and by engaging with other users and those looking to learn about how their life could be easier with the right technology.