Building a Developer Advocacy Team from Scratch #0: Team Foundations

If you should happen to come into the situation where you are asked to forge a Developer Advocacy Team from scratch, you might think that the first thing you should do is map out a calendar of technical content, or generate the list of developer events you plan to submit CFPs to and speak at. And yes, those things are quite important to get started on ASAP.

But the most important thing you can possibly do, and something that is important to do incredibly quickly? Setting strong foundations that will allow your team to be awesome.

There are a few components to this:

Really get to know each other, not just the “fun” stuff but also the stuff we don’t always think to talk about (e.g. individual working styles) that can lead to problems down the road if not addressed early.
Define what "Developer Advocacy" means, for your particular team, and in your particular organization. Figure out the "super powers" each person on the team possesses (and conversely, what work is "kryptonite" for them).
Lay down the Minimum Viable Processes™ Where are you tracking work? How often do you meet to talk about it and for how long? Lay down some early "team norms" so you're not inadvertently burning each other out.
Write it the (*&@# down :) The most important step! This clarifies expectations not just for your team, but for the organization around you.

Let’s dig in! :D

Step 0: Really get to know each other

Photo by Volodymyr Hryshchenko on Unsplash

There might not be time for a lot of time for this upfront (as Step 1 will need to start ASAP), but this is something you want to start working on as early as possible. And while this includes things like “what are your hobbies outside of work” and “which shows are you binging these days?” it also means things that are going to cause you all to inadvertently burn each other the *(&@# out if you don’t figure them out extremely early in the formation of the team:

What are your working hours?
What safeguards do you need in place to do your best work?
What are things that energize you / sap your energy?
How do you like to receive feedback? (Including praise!)
What’s our team’s “Slack etiquette” around things like messaging in off-hours or expectation around response time?
...

A really cool framework for this is a Personal User Manual that can give even people who’ve worked together before insight into what makes each other tick and how to be more supportive team mates.

But essentially, start noting these things down as “baby steps” toward developing more holistic Team Norms. (Which is an exercise that can be easier to do at something more like an in-person offsite.)

Step 1: What does “Developer Advocacy” mean in YOUR context?

Pro Tip: This Venn diagram works for all sorts of teams, not just DevRel teams. :)

If you ask 5 people what “Developer Advocacy” means, you will get 12 different answers. That’s because it’s highly dependent on context:

The context of the overall business
The context of the phase of growth of said business
The context of where DevRel sits in the org chart
The context of your team members, and their specific skills
…

Use this confusion to your advantage. It means you get a very brief window of time when first forming the team to put forward an opinion about what YOUR Developer Advocacy team is going to do. Which ideally, is going to look like a Venn diagram (pictured above) between organizational needs, departmental priorities, and your team members' unique strengths.

For our team, we approached this conversation in the following way.

Start with the “team level view"

Start with an overall “guiding framework” for your work that makes sense to your team. In our case, we used the 3Cs of Devrel (Content, Community, and Code) at one of our team member's suggestion (https://www.linkedin.com/in/mason-egger/). (Along with a 4th "C" of "Consulting" 🙂)
Next, have a big ol’ brainstorming session as a group about ALL of the things that could possibly fall under that framework: teaching workshops, answering user support questions, creating demo applications, speaking at events, etc. (A tool like FigJam with sticky notes can make this kind of fun.)
Now it’s time to ruthlessly prioritize. :) Which of those things are most interesting for each person on the team? (For this part, everyone had a maximum of 5 stars they could allocate across dozens of sticky notes.) Conversely, are there any “no-go” zones amongst members of the team? (A direct quote: “You don’t pay me enough to teach TypeScript.” 🤣)
Finally, in an ideal world, what sort of focus allocation would each person put toward each of the “3Cs”? (For this, we used kind of a "thermometer bar" where each person coloured it in according to how much of their work week they wanted spent on each "C". This part was quite interesting; some wanted a pretty equal distribution; others wanted as little as possible to do with one area or another.)

Now, pull it "upstream."

Go over the company goals, as well as the departmental goals, as a group. Everyone puts their heads together to brainstorm about what are—at most—3-5 major initiatives that we think are in that Venn diagram of things we want to do, and also things that the organization needs?

Our list shook out like the following:

Priority 0: Ensure we meet our commitments to the rest of the organization. This includes things like workshop / hackathon preparation for the Replay conference and assisting with various launches in advance of it.
Priority 1: Ensure we make steady progress on our own team’s “top 5” list. This includes “foundational” things like getting an event and content strategy together, some “must have” tooling, and some high impact “quick wins” we can knock out by leaning on our strengths, with particular focus on topics and audiences identified by the organization as major growth levers.
Priority 2: “Supporting” initiatives (also known as the “Kitchen Sink” — another Mason-ism ;)) — These are the random requests that inevitably come in, which you pluck away at as you have time. We talked about an ideal ceiling on these being about 25% of our time, with the remaining 75% focused on P0 and P1 initiatives, because those are what the rest of the company is expecting us to do, and how the efficacy of our team will be measured.

Step 2: Lay down the team's Minimum Viable Processes™

Photo by Marvin Meyer on Unsplash

While you can certainly dive right in with the entire soup-to-nuts Agile / Scrum / Six Sigma / what have you, my personal philosophy around program management is two-fold:

Don’t screw around with processes until and unless the team is expressing a clear need for it. (This will normally come about as complaints about their job; apply some “systems” thinking to such complaints.)
Make sure the team has ownership in the shape of any new / adjusted processes that are introduced. (In other words, rather than pulling from page 3 of the Agile Manifesto, ask them what they want. 🙂)

Here were some things our team identified as process needs early on:

A place to talk: Our team members were more comfortable with a private Slack channel where they could speak openly, with copious use of the team Slack channel for collaboration with others.
A place to keep track of work: While the rest of our department uses Asana, our team members prefer Jira, so Jira it is. (This is how much I love these people. ;))
A clear separation between “actively on the go” and “not yet” work. Boom: a backlog and a kanban board.
A meeting cadence for talking about our work. We decided that weekly works for now.
Dedicated time for “deep dive” discussions. Community, Content, and Events are much Bigger topics, and they also need input from people outside of our immediate team, and so we have dedicated meetings for those every 2 weeks.
Heads-down time. Done: No Meetings Wednesdays, and “Avoid” Meetings Thursdays.

(Note: If you keep pulling on this “needs-driven process” sweater thread for your team, you will eventually discover ALL of the breakdowns in processes “above” and “beside” your team and will need to at some point do something about them. However, that is a topic for our next instalment. 🙂)

Step 3: Write it the (*&@# down!

You, when you over-rely on verbal / Slack communication. (Image source: Reddit)

This step often gets skipped, as it can feel like boring / thankless work that’s not as pressing/urgent as other things. But the real thankless work is when you end up communicating critical information about your team and what they are working on, over and over again, to dozens of different stakeholders in dozens of independent conversations, and you end up in a "purple monkey dishwasher” situation.

So, all of that hard work you just did? Write it the *&@# down ;) And write it in a place where the entire organization can see it (e.g. Company Wiki).

This document will be essential when defending your time, and the team’s time, from random side quests that pull you away from top priority work. It allows you to remind people if they complain that this is what you are working on, and also why.

Here’s the structure of our team wiki page, in case you're looking for inspiration:

About our team: Pictures of everyone’s faces, where we are from, what our “superpowers” and interests are.
Guiding principles Pulls key lines from organizational / departmental strategy (e.g. delight developers) that overlap with the team’s mission / values.
What does Developer Advocacy do? The “3Cs” definition, calling out specific areas our team identified as being of interest.
What are we doing this quarter? The P0 / P1 priority list, along with a bit of context on each for “why” we are doing those.
What are we doing next? Show people your team’s longer-term vision, and assure folks that the priority they are really concerned about is on our radar.
What are we not doing? ← SUPER IMPORTANT! Explicitly call out areas you’re not currently staffed to take on, and what it would take to get you there. (For example, I had to drop most of our Community programs when transitioning from IC -> Manager. The requirements documented there are at least half-time from a dedicated program manager, which the business can decide to address with either staffing or patience.)
How do we work? Here’s the document your team norms stuff: when do we meet and why, how do we use Slack, etc.

I'm curious for others who have been in a similar boat: What were your first steps in the "team forming" stages? What do you feel are the most important team foundations to lay down?