top of page
  • Writer's pictureRasheed Mudasiru

First steps as a Developer Advocate at Company X

You successfully completed the company onboarding, met with key stakeholders and familiarised yourself with the necessary services and products. What’s next?


The first task for every successful developer advocate is proposing and creating what is popularly known as “DevRel Discovery”.


DevRel discovery is usually possible and brings success by adopting a series of models and frameworks.

As the first on the team, the following will be the necessary first tasks in the “DevRel Discovery” process.

  1. Understanding the company and service landscape.

  2. Developer Experience Audit (DX Audit).

  3. Goal Setting

In this article, we will examine what, why and how to successfully carry out DevRel Discovery focusing on the above three (3) objectives.


We will talk about each element and the impact it will have on the team's development and growth.



During my research process, I thought of structuring this article to resemble a case study, which is why you will see me using Company X for the company name we are representing and Company X is a developer-first company.



Understanding the company and service landscape


It is important to have the above tasks in order early on, and the success of the first task (understanding the company and service landscape) will depend on other teams’ understanding of the role of developer advocate.


Customer supports and customer success, sales and sales engineering teams and other teams and stakeholders need a deep understanding of the role to ensure alignment across the board.


Here are the actions you can take to achieve this:

  1. Internal Education: Prepare the “DevRel Playbook” document with the teams and stakeholders.

    1. This is a short and very brief document, usually not more than 15 slides. Explaining what DevRel is and what the company can expect from the developer advocate role and how this function can benefit other teams.

    2. Gather responses to examine the perspectives of members in different teams to their views and expectations towards the role of a developer advocate.

  2. Schedule interviews with stakeholders: Use the responses collected earlier and include them in your Playbook deck's. It is an excellent time to discuss where individual teams stand with their expectations for the DevRel team.

It is crucial to connect all our actions to our role, as developer relations/advocates. Through this interview, you will understand the following:

  1. The goals and priorities of every stakeholder in the company

  2. Company challenges and how the DevRel team can help tackle them.

  3. Marketing model (marketing model or orbit framework etc.)

  4. Track conversion strategy by the sales and marketing team


How do I measure success?

  1. At the end of the above two processes, you should be on a high level of understanding of both the company goals, services and the stakeholders.

  2. The number of successes recognised through different team strategies.

  3. The number of challenges discovered facing another team focused on the DevRel team.

  4. The number of staff or teams that understand the role of a developer advocate in relation to their teams (aim at 70% of the staff to be onboard instantly and check in on the progress over time).


Developer Experience Audit (DX Audit)

After the company landscape exploration, stakeholders’ interviews and learning about the nitty-gritty of the business, it is time to discover the friction log by looking into the Company X service from the developer's point of view.


This process will reveal a lot about the company’s customers, and services and will help you discover how easy or hard it is for users to sign up and get on board with your product, the number of technical guidelines and documentation.


The main purpose of the process is to document, report, and provide solutions to any kind of friction or inaccuracies discovered in the developer workflow and necessary feedback for service improvements. The best strategy to use at this level is to test and do a developer workflow for each of the Company X service use cases. Here are the main steps you should take to complete Developer Experience Audit:

  1. The report should focus on each use case, offering feedback on the good or bad sides of e.g. the integration into the web should (not to be assumed for integration into iOS or Android).

  2. Customer’s voice: this can be done by collecting users’ feedback sourced via social, forums, surveys and GitHub discussions.

  3. Create a ticket to follow each of the feedbacks till they are all resolved and keep track of the time taken.

  4. Build a project to test out use cases.


How to measure success?

  1. The number of frictions discovered and how quickly they were resolved.

  2. Customer feedback after friction removal and their experience and satisfaction with your product.

  3. The number of new users acquired.

  4. Stakeholders, sales and marketing teams’ experience and impact on cross-team goals (identified in the next step.)


Goal Setting

A famous quote from Bill Copeland says: “The trouble with not having a goal is that you can spend your life running up and down the field and never score”. This applies to our work in Developer Relations too. Here a lack of S.M.A.R.T, Specific – Measurable – Attainable – Relevant – Time Bound, goals for the team will affect and bring down your results, and how fast and successful the developer advocate team will be. For every team bringing business impact and creating meaningful programs starts with having the right goals and strategies to achieve them. Among the tons of frameworks, I will focus on the Objectives and Key Results (OKRs) framework. Let’s take a look at the example of my first set of OKRs at Company X.

Business Objective: Grow revenue by increasing our number of customers through community engagement


Key Business Results:

1. 150 leads added to the pipeline 2. 100 existing opportunities engaged through community 3. 50 new customers acquired 4. Retain existing customers

Metrics: 50 new members Focus: New and existing customers


The above OKRs are what is crucial to tackling as DeRel team at Company X among other initiatives.


It is important to note that these numbers will vary across different companies and it will depend on your present company’s size to base your projection of the key results and metrics for future growth.



Conclusion

Congratulations on reading this article to the end, you should now be ready to take on your first tasks as a developer advocate in your company especially, if you are the first one on the team and your company is developer-first focused.


I hope you learnt how to set up DevRel Discovery based on three basic models which are Understanding the company and service landscape, developer experience audit (DX Audit) and Goal Setting. It is important to note the emphasis should always be on creating strategies and ways to measure success at every stage of your activities and programs. It is very important for successful developer advocates to tie their achievements to business outcomes.


I hope that you found this article useful and informative. In case you have an interest in discussing this with me and peers in the community, you can reach me through the DevRelX Community. I would love to hear your feedback and can’t wait to hear if this article has helped you in your career and set you up for success as a Developer Advocate.


I am Rasheed, a software developer (DevOps) passionate about community and community building.


I am the lead organiser at Cloud Native Computing Foundation, Minna and a GitHub Campus Expert. You can also find me and follow my work on Twitter, Linkedin and GitHub.

bottom of page