Issue #62: Partnering with DevRel (Advice for CS leaders in platform companies)

Hi everyone — Nick here. I’m taking over SHH to share an interview that digs into a hidden opportunity: the partnership between Customer Success and Developer Relations. 

Developer Relations can feel like a distant, ambiguous team. But the truth is, for platform or developer-focused companies specifically, the DevRel team is out there actively working with developer communities, partnering with teams to build integrations for your product, and submitting feedback to your Product team. Not partnering with them is a missed opportunity to leverage their knowledge and relationships. And at the very least, partnering with DevRel will help you understand what they’re submitting to Product that may be prioritized over your customers’ requests. 

I interviewed Bear Douglas (Director, Developer Relations at Slack) and Teresa Nesteby (Developer Support Manager at Slack) for this topic. We covered: 

• How the focus of DevRel changes based on the reporting structure. 
• Working with DevRel as a CS leader, and 
• How CS can add value to the DevRel team. 

Here’s their perspective.

The two most common structures for a Developer Relations team

Developer Relations is becoming an increasingly important priority for platform and API-driven companies. But it’s also a role that can be interpreted very differently depending on what a company does and where DevRel sits within the org structure.  

"Developer Relations (DevRel) is an interdisciplinary role that sits in a border space between product, engineering, and marketing.”

-Bear Douglas, Director of Developer Relations at Slack

DevRel responsibilities in API-driven companies

In API-driven companies (think Twilio, Stripe, SendGrid), DevRel tends to act more as a go-to-market function — recruiting developers to use the platform — and is usually nested within Marketing. A lot of the team’s work is around outreach, customer education, webinars, and talks. And their KPIs tend to be based on things like top-of-funnel growth, community engagement, conversions of new developer customers, or expansion within those customers. 

DevRel responsibilities in platform companies

In platform companies like Slack, Facebook, or Twitter, DevRel tends to be grouped within Product or otherwise strongly tied to Partnerships and the Business Development organizations. You can think of the DevRel team in these companies as the ones advocating for the platform with developers, and advocating for developers with the Product team. They provide the training, materials, and consulting when individuals or teams want to build an integration for the product. And they feed back real-world bugs and feature requests to the Product team.  

“Ultimately Developer Relations is responsible for your platform’s developer experience.”

-Reto Meier, Developer Advocate at Google

At Slack, our DevRel team has team members with specific areas of focus: some people are focused on writing API documentation, some build tools or integrations for developers, and others run feature alphas and betas for the Product team. Each group is evaluated on hitting KPIs in their specific focus areas. For example, team members focused on API documentation are measured on delivering high-quality documentation on time. (For more on how teams are measured, here’s an article on how DevRel career ladders work at Slack.) 

Editor’s note: since Bear and Teresa’s backgrounds are with platform companies (reporting into Product), that’s where we focused the rest of the interview. 

Working with Developer Relations as a Customer Success leader 

Some companies, like Slack, have a Technical Customer Success Manager team (aka “Technical Architects”) and a DevRel team. In most cases, Technical CSMs are focused on contract-based work with specific customers — and their focus generally surrounds “administration“ work. DevRel teams are focused more on scale than helping customers one-on-one; they’re creating lots of enablement materials, webinars, etc., that help developers build integrations on the platform.  

Here’s how a CS leader might think about a useful partnership between the Developer Relations team: 

• What CS brings: some text
  • Using technical knowledge about the product (or case studies), CSMs can encourage their customers to build integrations to solve certain internal challenges. 
  • CS teams can also share common questions and areas of confusion from customers in regards to integrations and APIs. 
• What DevRel brings:  some text
  • CS can bring common technical questions from customers regarding integrations, and DevRel can either create documentation to solve those problems or bring those customers to the community. 
  • DevRel can regularly train CSMs on how different types of customers can get the most out of the product. CSMs can use case studies of how other customers have built internal integrations with the product to increase adoption. 

Final thoughts (from Bear)

If I were to share a couple of pieces of advice with CS leaders, I’d say this: 

1. I know a lot of CS leaders want a better partnership with Product. On a tactical level, getting Product to prioritize your requests requires you to build a good business case. But longer-term, the real answer lies in how consistent you are in advocating for the right requests and having good judgment about the things you ring the fire alarm for. I’m careful not to share every single thing we hear from developers with Product — we need to look at the requests together and make decisions before we share them with the Product team.

2. Also, too many CSMs and Sales reps avoid talking about the technical aspects of the product with customers. This is a missed opportunity to help customers get more out of the product — if you think about enterprise customers, the availability of integrations is often a differentiating factor when people are making purchasing decisions. (For example, certain Slack integrations are a ‘wow’ factor for enterprise customers, and they differentiate us in the sales cycle.) Same goes for “the second” and “third” purchases (renewals, upsells, expansions).
    

CSMs want the product to be sticky, and what better way than to embed additional integrations and use cases, however technical they may be, in the customer’s existing workflows?  

The best CSMs are willing to get deep with technical speak but at the very least, CS teams should consider DevRel as a resource to pull in when those discussions go beyond their technical knowledge. Then on an ongoing basis bring DevRel in to train CSMs on the new integrations and other areas of the product they’re working with, and how they might be used with certain types of customers.

This week's top posts

THE ROLE OF THE CCO

Say Goodbye to the Tactical CCO — Here’s What Strategic CCOs Focus On

"If you want to influence Sales, help them close deals. Period." This thinking helped Jeb Dasteel, who pioneered the CCO role at Oracle, pave the way for other strategic CCOs to know how to approach their role. In this piece he goes deep on how top CS leaders can move from being tactical to strategic, including focus areas, key metrics, and common pitfalls.

Read the full post

MEETINGS

QBRs and EBRs Are Things of the Past

Russ Dury, CS Lead at Zeplin, makes the case that too many business review meetings focus on the company and not the customer. “Why do you think your customers skip EBRs with you?” This article is a good reminder that customers are busy and if your meetings with them aren’t tailored around their objectives, you might as well not waste their time.

Read the full post

COMMUNICATION

Nonviolent Feedback

When giving feedback, are you using words like I like it, this is good, awesome—or the reverse, bad, sucks, lazy? In this piece, Zef Hemel calls this “violent feedback.” He argues to remove subjective language from your feedback and instead state 1. the observation, and 2. the impact of the observation.

Read the full post

SELLING

The 4-step Secret to Upselling

Annie Gray, Director of CS at LiveHelpNow, with some useful tips for CSMs to build trust while upselling. Consider passing this quick read along to your team.

Read the full post

Success Happy Hour is a weekly newsletter for Customer Success leaders. Each week we feature one digestible piece of advice or a framework from a top Success leader, along with the best resources from that week. Subscribe here.