Photo by @wrwhite3 / Unsplash.com

Researching developer advocacy – a revisit to my Executive MBA thesis from 2020

Thanks for reading my blog! If you have any questions or need a second opinion with anything Microsoft Azure or Power Platform related, don't hesitate to contact me. I'm happy to provide my professional services through my company, North Advisors.

I began my Executive MBA journey in March 2019. It’s a two-year program that you can complete on the side while you work full-time. As part of the studies, you need to write a thesis (I graduated in early 2021). The aim is to focus on a singular topic and produce a paper that can stand academic rigor and perhaps be helpful at the same time. It sounds easy but is surprisingly tricky to get right.

We were free to choose the topic, and I spent several weeks playing with some interesting ideas at first. I figured it would be interesting to look at AI in services businesses on the list of ideas. Then I changed that to figure out how a small business can create a new product in the IT security space.

However, the challenge is that if you choose a topic that’s vastly researched already (like sales or a business strategy), you have to read and do research quite a bit before you get to a point where you can consider you have something to add to all that. I also thought of AI in the context of sales as a topic. The challenge is that you too quickly spend half of the paper explaining the basics, leaving very little space for the exciting and valuable findings. We didn’t have a strict cap for the length of the paper, but the recommendation was to aim for around 50 pages. I ended up with about 70 pages in total.

Eventually, I settled on researching developer advocacy. Why, though? Well, I wanted a decent challenge, and it’s two-fold here. First, it was a topic I spent my days on while working at Microsoft in 2020. Second, it’s a topic that many people seem to have very different ideas of its meaning. A bit like with AI – it means Machine Learning to some and “weird self-driving cars” to others. And everyone argues their definition is the only proper one.

I started focusing more on finding useful literature, research, and papers on developer advocacy first. Developer Relations (or DevRel for short), developer advocacy, influencing, advocacy in general, and evangelism are pretty intertwined. The existing literature was often very scarce or beside the point (such as a specific marketing strategy instead of advocacy through a wider lens). I then knew this was a topic I had to learn more about – and perhaps contribute something extra for others to benefit from.

I’ve now published my thesis on Research Gate, and you can find it here.

Writing the thesis – insights

Once you’ve settled on a topic – even if the title might evolve – you get assigned a supervisor. This person is someone with proper academic credentials, and they are often a subject matter expert on your thesis topic.

The essence is that your thesis needs to ask a question – and propose one or more answers backed with facts. I settled on the following final title for my thesis in June 2020: Understanding organizational advocacy in the context of modern marketing: The Avocado Reach model framework.

There’s a bit to unpack here; we’ll get to that in a bit.

I defined my schedule – I’d be writing during my summer vacation from July to August, and then I’d focus on finishing in late September. We were given about a year to complete the thesis, but I figured that a few months should suffice as it’s ‘only’ a 50-pager. I completed my thesis in October, so all in all, it took about three months from scratch to a 70-pager thesis. I’d estimate I spent about 120..140 hours in total. In a way, it was a tough assignment, yet at the same time, it was very doable, and sometimes I didn’t think about the thesis for a week or two and just let it sit in the back of my head. I’ve written about ten books, so a 50-pager felt easy in comparison.

I usually wrote during the evening and sometimes during the weekends after the kids went to bed. I utilized Grammarly throughout the process and configured it for academic writing style. That was helpful in the sense that specific complex sentence structures could be spotted and fixed more quickly. I also had https://thesaurus.com open on the side to find synonyms whenever needed.

We settled on a bi-weekly rhythm with my supervisor. We couldn’t meet in person (due to COVID-19), so we used Microsoft Teams video conferencing to catch up. I know myself well in the regard that I need a rhythm to get stuff done. I would send my paper updates each week, and then we’d go through the feedback, ideas, changes, and issues during our calls. I would also print out five or ten pages to read by myself and make edits on the fly in-between. I find this analog approach very effective. Towards the end, we had weekly calls – usually just 30 minutes at a time.

I especially remember one call with my supervisor. I’d spent about 12 hours going through my datasets. I carefully crafted piecharts, diagrams, and analyses in Power BI and Excel. I was drilling deep into the data. I felt proud on a Sunday evening with my 10-page progress on the analysis portion of my thesis. On the next call, my supervisor wryly stated, “Hey Jussi, this is good, but it’s super boring. So scratch this or move it to an appendix and let’s focus on the actual findings“. Ouch. There goes a dozen hours of hard work down the drain, I thought. It was educating and a way for me to learn how to write better. And that’s the essence of the thesis project – get better.

On developer advocacy

When you embark on writing a thesis, you have certain boundaries: a fundamental question, facts, findings, previous literature, a methodology. The usual stuff, I guess, for anyone in the academic world, but a different world for someone like me who primarily focuses on business writing and presentations. I can twist words quite quickly, and it’s easy for me to produce text. But creating text that can stand academic rigor is more challenging.

The structure of my thesis is as follows:

  1. Executive Summary
  2. Introduction
  3. Research Formulation: Research question, the challenge with advocacy, the objective of the research, definitions, and how advocacy differs from classic marketing concepts
  4. Literature Review
  5. The Avocado Reach Model – A theoretical framework
  6. Methodology (gathering the data, interviews, survey)
  7. Findings and analysis
  8. Discussion and recommendations
  9. Managerial implications
  10. Conclusion
  11. References + appendices

I learned that people rarely read beyond the executive summary or the intro, so they need to have some punch written in. I’m semi-proud of how I handled these, as I used structures I’m not intimately familiar with and still made it very readable and somewhat entertaining.

A few out-of-the-context sentences from the intro:

“Advocacy is the act of advocating – often through evangelizing, influencing, and storytelling – a company’s narrative to one or more communities and stakeholders. For KIBS companies, it is key to winning the hearts of like-minded individuals – engineers, developers, and IT professionals.”

And:

“Often, advocates effortlessly align and orbit closely with engineering or R & D and gravitate away from traditional and conservative marketing structures. Advocacy should not be streamlined to yet another communications channel that ponders the content of a specific tweet or mulls over a company’s newsletter content.”

It took me a long time to drill down to the essence of what developer advocacy is. I defined it reasonably well, but I also wanted to avoid absolute terms, as it’s never black and white. Thus, to gather more data and insights, I conducted an anonymous survey and interviewed select people. Let’s take a look at this in a bit.

The framework

It’s often advisable to ground your research in a framework. Perhaps someone has a great framework that helps you align your research outcome to the real world. I spent considerable time going through existing frameworks. But each failed me – as the ones that are more aligned to organization advocacy often were not frameworks – but process charts for a specific task (like when to attend a conference or how to connect with people on social media). I wanted something more high-level that grounds advocacy efforts within the organization and the external relationships – communities, customers, and partners.

I fiddled with the idea of creating my framework. I brought the idea up with my supervisor, and he was very supportive of this. It turns out, from our class of 2021, I was the only one who created a custom framework – and it was a delightful experience. I’ll save you from reading pages upon pages of academic arguments on how it works and share you with the actual framework as I think it’s pretty self-explanatory:

At the heart of the framework is organizational advocacy. It usually (but not always) sits within a given company’s marketing or product marketing departments. The relationships with customers, communities, and partners are exposed via actions that conform to authenticity, honesty, and empathy—the expected outcomes listed on the proper aim for increased sales, brand recognition, and such. Then, two measures are received – one for future (lagging) impact of a possible deal, and another for near-real-time effect – usually such that it might influence future R & D and advocacy efforts.

I named this framework the Avocado Framework. It’s an old wordplay on the word advocates, and I felt it’s a bit like an avocado – hard in the core and soft to the outside. A lesson I also learned during this project was that when you search with ‘advocate,’ you get a lot of legal text in results.

As part of the outcomes for the thesis, I listed additional considerations on how to apply the framework, and it would be interesting to use this on a larger scale in the future.

The data

For any decent thesis, you need data. I gathered data through an anonymous survey (quantitative data) and personal interviews (qualitative data). I didn’t record any of the discussions, but I just typed furiously while meeting the interviewee like a paralegal in a courtroom. This produced pages upon pages of text that was primarily coherent but required quite a bit of re-reading and iterations.

I had five interviewees, and I spent about ten days sifting through the data I gathered. It opened my eyes to many aspects, especially how vastly different people might see or perceive the advocacy role in technology.

For the anonymous survey, I utilized social media – mainly Twitter and LinkedIn. I crafted a survey with about ten questions. After seeing the initial draft, my supervisor had me re-do it with more challenging questions. Altogether, the questions I had were:

  • Do you consent to participating (anonymously) to this survey?
  • Do you currently work in an Advocacy role (such as a Cloud Advocate, DevRel, or similar)?
  • Do you know people working in an Advocacy capacity?
  • Do you follow people on social media who work as Advocates (such as a Cloud Advocate or a DevRel Lead or similar)?
  • In your perception, do you see Advocacy, Developer Relations, Technical Evangelism, and such roles as more similar, or different to each other?
  • How would you position Advocacy with Marketing and Engineering functions?
  • What groups or stakeholders do you expect people in Advocacy roles to work and interact with? (You can select one or more choices)
  • What content and activities do you expect to see from a person working in Advocacy or Developer Relations? (You can select one or more choices) (blogs, speaking at events, etc.)
  • Please rate each statement on your thoughts about people working in an Advocacy role?
  • Based on your preference, rearrange the following statements:
  • People working in Advocacy role should focus on (X, Y, Z..)
  • How should the success of people in Advocacy roles be measured? (You can select one or more choices)
  • Any additional comments, thoughts, or insights?

A total of 160 people responded to my survey, for which I am very grateful. Some of the questions required you to think through, rather than just clicking the obvious choice and submitting it in less than a minute. Many people spent more than 15 minutes on the survey.

I amassed all the raw data to Excel. I have a large display, and it was filled from corner to corner with the data. On the side, I built a relatively valuable but straightforward Power BI dashboard that I could use to visualize my findings. I still utilized Excel quite a bit, as visualizing data often meant a clean chart rather than a fancy clickable and animated element.

Here’s an example – are DevRel people usually developers, or at least, what’s the expectation?

It’s a mixed bag. Most people somewhat agree, while a lot of people somewhat disagree. I was a bit scared about analyzing something like this, but my supervisor encouraged me to push forward and towards the tough questions. Why? Why is this? I spent numerous pages studying these insights. While I cannot say I’ve reached a conclusive result, I found the managerial recommendations and the template for anyone working in DevRel capacity.

Managerial implications

So, to conclude a thesis, you need to suggest the following steps – basically, recommendations. In short, these are:

Finding the right people – it’s a challenging role. I wrote in my thesis:

Experienced subject-matter experts, such as developers, are great candidates for advocates. Nevertheless, not each developer is a great fit. Beyond being intricately skilled in their craft, advocates have to be easily approachable, supportive, and candid. These traits might be natural for some, while others have to orient and grow professionally more. A way to achieve this could be, e.g., leading the advocacy function by example, partnering and connecting with other advocates (from other companies), and carefully adjusting based on feedback and reactions from the communities. The advocate’s role is a mix of marketing, social media appearances, influencing, know-how, and a pirate. Not too much of any, but enough of all.

Training and supporting advocates. Again, I wrote in my thesis:

Cultivate, support, train, and encourage advocates to be honest, authentic, and empathetic. A traditional corporate training, while perhaps mandatory, has very little to offer for advocates. An advocate must know the rigid limits of their role and the organization. Is it easier to ask for forgiveness than ask for permission? More so than often, it turns out to be.

Advocates are free-roaming artists who are fiercely driven by social interactions with their respective communities. Seeing a junior developer experiencing that” Eureka!” moment through the advocate’s work and support is the role’s figurative fuel and incentive.

Crafting partnerships. In short: Establishing a frictionless, dynamic, and reciprocally beneficial partnership with marketing and engineering. These traditional functions can benefit significantly from advocates’ work and passion, yet advocates do not thrive in rigid corporation structures without breathing space.

Having clear business-driven goals. KPIs, essentially. Advocates are passionate, but their ethos includes honesty and a fierce focus on their key stakeholder groups. Imaginary goals, such as sign-ups to a newsletter, are not only insulting but mostly useless in terms of the business value created.

Applying a framework (the one I did or something else). Finally, advocacy should not be driven as a quarterly exercise with direct profit-and-losses responsibilities. Instead, advocacy is a strategic investment that usually takes a year to mature and become a competitive asset.

In closing

I submitted my thesis for review and grading in early October 2020. I spent about three calendar months on it, sometimes taking a week off and not thinking about it. Other times I worked furiously for a long evening, late into the night.

There are plenty of bits and pieces that I’m immensely proud of. The framework – my first – is something I enjoyed doing. The surveys and analyzing the data taught me how I approach such tasks now in my work. Crafting the comprehensive document – and I’m used to working with long, +50 page docs – was a challenge, but something you learn to live with.

The executive summary is perhaps the most crucial piece of content in any thesis. I also finished the idea with something less dry:

Advocacy is often considered an extension of marketing that revolves around social media activities. Organizations that can envision and build a true advocacy function are optimally suited to connect and win with their communities, customers, and partners.

Advocacy is about distinctively doing things. In the late Steve Jobs words,” it’s more fun to be a pirate than to join the navy” (Sander, 2011).

A key finding, at least for me, was that most surveyed people (87 %) felt that advocacy, developer relations, technical evangelism, and similar professional terms are identical. A little more than half (54 %) stated that advocacy is part of marketing and engineering – not just one or the other.

I’ve printed my thesis, it sits in my bookshelf, and now and then, I flip through a few pages of it. Perhaps to remind me that this, too, was fun and challenging at the same time. I’ve since changed my roles and work away from pure advocacy-focused work, but I still carry much of the learnings with me in my daily work.

How did the thesis land, then? I got a top score, 5 out of 5 for it.