Building a Developer Advocacy Team from Scratch #2: "Go-To" DevRellers

In our last thrilling episode, we talked about the importance of equipping your team with a strategic prioritization framework to help them to reason about incoming requests so they can spend the majority of their time on high-impact shit that matters. (And help the rest of the org to understand how and why you prioritize unplanned work the way you do.)

In this episode, I want to share some recent learnings on the evolution of "request intake" for those "unknown unknown" requests on our team, and how we arrived at our latest model, which is embedding "Go-To" DevRellers on relevant cross-functional teams, rather than waiting for them to come to us.

What does a "good" request intake process look like?

Let's start with the markers of a high quality request intake process:

• Cross-Functional Partnership: DevRellers and stakeholders partner together on things, collaborating closely, and building robust, long-term relationships.

• Timely: The DevRel team learns of needs early enough that we can service the request well, showing off our best work.

• Responsive: Stakeholder requests are responded to in a timely manner.

• Clearly Communicated: What's happening with requests—who's on it, whether they're happening now, later, or "someday/maybe"—is made very plain. The stakeholder is also not exposed to a bunch of "how the sausage is made" chatter from the team about servicing the request, just the outcome.

• Safe: The team has the ability to frankly discuss the merits of a request and how/whether we think we can reasonably service it without the stakeholder looking over their shoulder.

• Load Balanced: Requests are distributed across the team in such a way that individuals aren't feeling overwhelmed and they can still make their pre-existing planned commitments.

• Visible: There's team-wide knowledge of incoming requests and company-wide visibility who's working on what.

• Inclusive: Both newer and established / senior members of the team alike have an equal opportunity to snag the "best" requests and the fame and glory that comes attached to them.

Phase 1: Informal Relationships

This is how almost all teams start, as it's the default way for human beings to function, and it can even be the best option if both the company and team are sufficiently small.

In this model, stakeholders just reach out to whoever they know from the DevRel team, either because they've worked with them on things in the past, or they're the person who's done the most consistently visible work. The two of them talk about the requests directly, which makes Cross-Functional, Responsive, and Clearly Communicated a done deal. Nice!

However, this also means the DevReller now finds themselves with the sole responsibility for managing any and all incoming requests pointed their way, which makes Load Balanced a non-starter, and especially if the person asking has a "C" in their title, things like Safety can go out the window as well. :\

This situation is pretty obviously also not Inclusive, and that particularly sucks for those new to the team (Stakeholders and DevRellers alike) because they're unsure who to talk to / what requests might need servicing, and often toil away in complete ignorance of one another. Which also means this approach isn't Visible, and that often leads to it not being Timely, either, in the form of a ton of "last minute" unplanned requests to DevRel because a pre-existing relationship was not established upfront.

Quality Checklist

• Cross-Functional Partnership: ✅

• Timely: ❓

• Responsive: ✅

• Clearly Communicated: ✅

• Safe: ❌

• Load Balanced: ❌

• Visible: ❌

• Inclusive: ❌

Pros

• Fosters and nurtures cross-functional relationships

• Faster turnaround from request to action

Cons

• Team doesn't even know opportunities exist until someone’s already taken it on

• Uneven distribution of stakeholder relationships and knowledge of their needs

• Really sucks for new team members who won’t have those relationships yet

• No way to “load balance” requests across the team

• Reporting is an act of reading tea leaves and praying

Phase 2: Command and Control

In this approach, you centralize request intake and anoint a "Request Captain" to field and distribute incoming requests amongst the team.

There are a lot of immediate benefits to this approach: with only one person being the "conduit" for communication inside and outside of the team, we nicely take care of Clearly Communicated, Visible, and Inclusive. Everyone has an opportunity to see requests, respond to requests, and understand who's doing what.

This approach obviously introduces some delays in being Responsive, but that can actually be a good thing if you're in a "People Pleasing" organizational culture where people are generally expected to instantly leap on anything that comes in, especially when it comes from people with high-falutin' titles and/or particularly "yell-y" stakeholders. That situation makes for a DevRel team that is constantly chasing its tail, without thoughtful consideration for the impact these incoming requests have, both on the individual humans on the team, as well as the team's ability to reliably make good on their previously planned commitments. By using Command and Control, it helps train your organization that they need to WAIT JUST A DANG MINUTE before we jump on requests. ;)

Safety is a lot more questionable, however. While it's certainly possible to make the "Request Captain" a rotating "on-call" role, typically this will default to being the team's Manager. In one sense, this is great! The Manager can then act as a "bullshit shield" so their team members are no longer exposed directly to upset stakeholders, and they can actually focus on their "deep thinking" work vs. being on CONSTANT VIGILANCE for any new incoming things. But there are significant barriers to the team being Cross-Functional, as those relationships tend to get forged with the "Request Captain," not with team members themselves. And finally, when it's your boss doing the asking, it can "hit different" and folks can fall back into that anti-pattern of people pleasing. :\

As far as Load Balanced goes, while in theory it seems like this approach would be a slam dunk, in practice it can introduce the 4-Way Stop in the Midwest Phenomenon™ where everyone is politely waiting around for someone else to take action, because they don't want to step on anyone's toes. It's unclear whether they need to ask permission to proceed, and it's also unclear what to do in case of a "race condition" where two or more people raise their hands to work on something.

Quality Checklist

• Cross-Functional Partnership: ❌

• Timely: ❓

• Responsive: ❌

• Clearly Communicated: ✅

• Safe: ❓

• Load Balanced: ❓

• Visible: ✅

• Inclusive: ✅

Pros

• Team-wide visibility of incoming opportunities

• Helps buffer against people pleasing

• Load balancing is possible

• More streamlined reporting, as we know what everyone's working on

Cons

• Can lead to extremely slow decision making

• Can create anxiety with too much visibility, especially if incoming requests are frequent or have short deadlines (or both)

• Disempowers ownership, as people not sure who has decision-making over incoming requests

• Unclear what happens in case of “race condition” of two or more hand-raisers

• When it’s your BOSS doing the asking, it “hits” different :\

Phase 3: "Go-To" DevRellers

Here's the model we have now landed on, where there are clear "Go-To" people identified for various "swim lanes" that cover some aspect of what DevRel does, those individuals embed themselves directly within relevant stakeholder teams, and we create one or more "offerings" under each swim lane to make it clear what our team can do for the organization.

What does it mean to be a "Go-To" DevReller in this model? For your designated "swim lane"...

1. You embed yourself within your designated cross-functional team. You hoover up all the context you can from wiki pages, documentation, previous discussions, etc. You're in their Slack channel and an active participant. You're either part of their operational meetings or you read the notes after so you're always up to speed on what's being discussed. You pair with their Engineers and/or Solution Architects on your work. You join relevant customer meetings, or listen to the calls after. You're a household name within that team, and everyone knows you're their designated "DevRel Buddy."

2. You field all incoming requests. Requests that touch your area come to you (or you are CCed into them if someone else sees it first). You run those requests past the DevRel Impact Factors and an Eisenhower Matrix, and you decide how to handle it: do it yourself, schedule it for later, kick it to the team for help, move it to the backlog, etc. Everyone else butts out. :) (Meant kindly. <3)

3. You own the Roadmap. What are the major deliverables, who's working on them, and by when (roughly) can stakeholders expect them. Your roadmap is inclusive of Code, Content, Events, and Programs and it's aligned on both with your team’s key stakeholders and your Manager.

4. Your Roadmap is a group project. Your Roadmap should be explicitly set up so others can contribute to it, both to your own "top-down" initiatives and also their own "bottoms-up" initiatives from their own areas. This way you can present a holistic picture of everything that's going on in your area to your stakeholders, and you can get done vastly more things than you otherwise would going it alone.

5. You own communication. On at least a weekly basis, you need to communicate about what you're working on and how your Roadmap is progressing. In internal team channels, in stakeholder channels, in external newsletters, etc. This helps manage stakeholder expectations when facts change, and ensures something gets "shipped" there's proper visibility on it.

6. You own metrics and reporting. It's part of your role to figure out what metrics to track and where, and making sure they're surfaced where business stakeholders can "self-serve" them at will.

How does this work in practice? Let's say someone's swim lane was "AI." That is something that is very obviously way too big for one person to handle in totality, and also isn't only DevRel's to own: there are going to be folks from Sales, Marketing, Engineering, and Product who have ownership, too. AI is also a "hot topic" and it's something everyone in DevRel will need to grapple with in some way.

The "Go-To" DevReller for AI would internalize our company's AI strategy, be a subject matter expert on our product's AI features, as well as customer pain points around AI. They would both attend and run key operational meetings about AI, including others from across the company. They would be CCed into any incoming requests and/or key decisions on AI as part of the "core" team. They'd also communicate weekly with stakeholders about the status of DevRel's portion of the AI initiative overall, and make sure that our "outputs" were captured alongside other assets from other teams for reporting purposes.

Their AI roadmap would consist not only of blog posts, code samples, and events they were personally driving, but also the Community Programs person would add AI example projects coming in from the community, the Customer Education person would add an AI-oriented workshop they were developing, and so on.

What happens to things without a "Go-To"?

We fall back to "Command and Control," but the "Request Captain" becomes "the first person who saw it" rather than defaulting to the Manager.

Since we're just starting to roll out this model, what follows are some hypotheses. ;)

Quality Checklist

• Cross-Functional Partnership: ✅

• Timely: ✅

• Responsive: ✅

• Clearly Communicated: ✅

• Safe: ❓

• Load Balanced: ❓

• Visible: ✅

• Inclusive: ❓

Pros

This model aims to build Cross-Functional Partnership in from the start, with the following benefits:

• Requests will be more Timely and Responsive because you're having two-way conversations and there are much fewer "surprises" (on both sides). You are on the meeting when that request is simply a concept, and your input into that concept gets incorporated from the start. You're also in a position to "Yes, and!" with new ideas that others on that team with different perspectives would never have thought of.

• As long as your "Go-To" model is written down and published, it's Clearly Communicated not only who to go to for what, but also what DevRel as a whole can do for other parts of the company.

• The Roadmap creates a Visible way to show the team's stakeholders when you can get that new request done, or, if it must be done now, what other important items are going to be pushed further down the road as a result. It also provides the other DevRellers on the team a place they can hang their own initiatives as well.

• The model aims to be Inclusive and Load Balanced. Everyone on the team has the opportunity to take an area of interest to them and that aligns with their skillset. Everyone on the team has an opportunity to contribute meaningfully in other areas they're not the "Go-To" on.

Cons

• As far as Safety goes, we are back to the same cons as Informal Relationships. The hope is that more "face time" with stakeholders by being part of their overall crew will help reduce mishaps, but time will tell.

• This model pushes a fair amount of program management work onto DevRellers whose feelings tend to range from “shy away from” to “viscerally despise” about such work. 🤣

• (Also a Pro) The "Swim Lanes" have to be dead simple in order for stakeholders to understand them, which can act as a forcing function for having tough team conversations about areas where folks are stepping on each others' toes.

Open Questions

As mentioned, this is the third in a series of iterations on our team's request intake process and I'm sure we'll learn a lot here. too. In the meantime, here are some "known unknowns" about this approach:

• How to handle "race conditions"? If two people want to own the "Community Programs" swim lane, can those folks simply sort it out amongst themselves or will it require a Manager to step in?

• Technical Program Management is an entire discipline unto itself. Will DevRellers be able to balance both the "doing the thing" and the "planning and talking about the thing" aspects of this model?

• How will this model fare in the face of particularly demanding stakeholders? Will additional "face time" and knowledge of the Roadmap be enough to stave off last minute, urgent requests that take planned work off track?

• How will this model fare in the face of DevRellers who are more shy/timid? Does this provide enough support so they feel empowered to advocate for themselves and their area of work, or will they end up feeling bossed around and need a Manager to step in and do so on their behalf?

• How will this model fare in the face of "glory hogs"? If someone's unwilling / unable to make their Roadmap a group project, and wants instead do all the work (or at least take all the credit) themselves, what will the fallout be for the rest of the team?

Stay tuned for future articles for answers to these questions, and more! ;-)

In the meantime, what do you think of a "Go-To" DevRel / Embedded DevRel model? Have you you tried this or a similar structure before? If so, what did you learn, and what were your takeaways?