Skip to content


We make our product meaningful for developers. We show you what's possible. We teach you how to do it yourself. We celebrate your wins, help you through your struggles, and we're there when you're ready to do it all over again.

Proposed team structure

With a clear north star, the most effective developer relations teams will "divide and conquer" responsibilities even when the team is just starting out with 1-4 individuals and these roles are combined. As teams grow larger, these four disciplines must increasingly collaborate together to deliver meaningful developer experiences. Of course, we might not have permission to own all these areas, but to operate effectively we must build influence and trust to accomplish our common goals.

A product-oriented developer relations team might arrange itself to serve four primary functions:

  • Education - teach the how, what, and why of the product
    • Produce engaging, well-organized, and accurate technical documentation and tutorials around the core services we provide.
    • Develop processes, procedures, and occasionally software to maintain a growing corpus of content and learning experiences.
    • Innovate on creative ways to teach and effectively bring developers to and beyond their first a-ha moment.
  • Engineering - provide the tools, libraries, and infrastructure devs need to succeed
    • Produce, enhance, and amplify the tools, SDKs, and other software developers need to be successful on the platform.
    • Make the developer journey as measurable as possible.
    • Provide a consistent, predictable end-to-end developer experience.
    • Manage our open source strategy and presence.
  • Partner engineering - make strategic business deals work for everyone
    • Pitch the art of the possible to partners, independent software developers, and other stakeholders.
    • Build example integrations by collaborating deeply with our most important partners, on their terms.
    • Represent partner needs, wants, and delights internally to product & engineering.
  • Advocacy - customers will love us if we love them
    • Produce timely material that reaches our target personas in the mediums that serve them best, including but not limited to tutorials, blog posts, video, webinars, and workshops.
    • Author deeper pieces on emerging and fringe topics important to our growing developer community.
    • Be the face of developer relations to the community, on-line and beyond.
    • Scale customer-facing programs appropriately with growth targets.
    • Keep the long tail of developers warm and well-taken care of.

The entire developer relations organization shares responsibility and builds partnerships in:

  • Go to market support
    • We want our customers and partners to succeed and sometimes that means teaming up to go above and beyond.
  • Developer support and advocacy
    • Everyone benefits from experiencing the platform, tools, and documentation from the perspective of those we serve.
    • Developer support happens on Slack, Discord, in Github issues & pull requests, in customer and partner calls, and wherever else developers bring their needs.
    • Everyone uses their "in the field" experience to improve the product and developer experience by becoming a trusted voice of the developer.
  • Producing tutorial and workshop content
    • Utilizing the expertise required from each discipline results in more effective, inter-connected learning materials that scale with complexity
  • Developer relations operations
    • Everything it takes to serve developers day to day, week to week, month to month, quarter to quarter, or even campaign to campaign.
    • Teaching and upleveling everyone else on the team with unique pockets of knowledge and experience.

This team organization assumes that a developer marketing function and a business development function operate outside of developer relations. Some adjustments are necessary as funding shifts for these functions.

Developer relations metrics and KPIs

Our developer relations organization is metrics-driven. To impact company-wide KPIs, we'll identify, hypothesize, and experiment with metrics local to our work and influence. We can adapt how we measure and set goals whether the organization prefers loose planning, OKRs, or V2MOMs. We're here to take care of developers no matter what the company is up to.

Without knowing our business too deeply, we start with baseline assumptions that:

  1. Friction in the developer experience is the primary drop off point for the developer activation funnel.
  2. It's best to "meet" developers where they are or where they're going to be. We can't expect them to join our community and use only our tools, exactly as we want them to. But we can encourage them to.
  3. Experiencing the joy of our developer product is the best way to inspire developers. The sooner a developer experiences the product and the better the experience is, the sooner they can build something meaningful.
  4. Developers need help reaching the end of their funnel. It's not enough to attract them, we need to help them succeed.

Proposed goals

We'll increase the number of integrations going to market by increasing the number of monthly active developers and their rate of success with tactics like:

Theme Example KPIs Sample projects
✅ Reduce friction
  • Resolve documentation bug backlog by XX%
  • Increase # of developers going beyond hello world by XX% m/m
  • Reduce time to market by 60% for Persona XYZ.
  • Launch a end-to-end hello world experience
  • Identify & provide a specific persona with near turn-key solutions.
  • Reorganize documentation by use case
  • Make sample projects more predictable & reliable
🤝 Meet developers where they are
  • Increase # of AI/ML hobbyist developers by XX% m/m
  • Increase # of Python developers m/m by XX%
  • Increase # of iOS developers by XX%
  • Provide a well-documented Python SDK built with ML and AI enthusiasts in mind
  • Support a platform partnership to integrate shortcuts to documentation from their product
  • Launch SDK for direct iOS support
  • Tutorial series on unusual use cases to inspire out-of-the-box thinking
  • Develop scalable community event strategy
🦉 Increase product exposure
  • Increase # of unique users using integrations w/w
  • Diversify integrations into 3 additional categories
🦾 Help developers succeed
  • XX% of projects under development for 6 months or more have a ship date expected within the next 6 months.
  • Maintain 80% developer questions answer rate
  • Increase developer resurrection at 2 weeks from X% to YY%
  • Add tracking metrics to SDKs
  • Build & promote forums for long-term knowledge & expertise sharing
  • Offer high-touch support for notable customer and partner developments
  • Formalize open source strategy for SDKs, sample code, and documentation.

Activating and enabling developers

We want all developers to feel welcome and empowered. We can and will provide them an amazing experience.

  1. Instrument our developer funnel
  2. Identify primary drop off points
  3. Continously reduce friction and measure impact

With so many developer personas working with us, we must identify common goals and the most important outliers to best serve and enable those most likely (or most desired) to succeed.

Research and continous learning is as important for this developer relations team as it is for our developers.

We also must remain open to doing activities that will not scale to reach outcomes.

Making platform safe for growth

With an instrumented developer funnel, we should identify the primary points of drop off and propose solutions to alleviate those, especially those that happen earliest in the process or are the biggest indicators of future success.

If there are shortcuts to success for these personas, we should build them and put them in reach!

Once we have high confidence a persona will be successful, we should consider campaign-based approaches to grow their introduction to the funnel, including targeted advertising, and direct outreach.

The last thing we want is a life-long developer trying the product, hitting a major point of friction, and then leaving with no intent to return.

Campaigns to grow developers don't just start and stop in developer relations, we need the help of marketing, product, engineering, design, and even our developers.

Developer education

Of all things measurable from the outside: improving documentation, tutorials, and enablement materials often are the highest priority.

No matter how many developers flow through the door, if they can't find what they need to succeed, they'll go away frustrated. Insufficient documentation is more than just a friction point, it's a crisis that only very few will weather.

A more cohesive education experience is paramount to onboarding and activating developers from all journeys. What are some deterministic, successful experiences developers can have to introduce themselves to everything our platform can do?

Of course, our predicted projects match our identified themes...

Theme Projects Outcomes
✅ Reduce friction
  • Document the product event loop/bus for developers
  • Tutorial: Building your first game
  • Tutorial: xyz
  • Developers understand what's happening behind the scenes and can model their code around it
  • Developers learn the tools and tricks of the trade while making the product a key part of their first-time journey.
  • Developers learn how to mix the product into existing sample projects, step by step
🤝 Meet developers where they are
  • Audit documentation and tutorials
  • Improve Node.js documentation
  • Re-orient Node REST server for usage by other programming languages
  • Quicker paths to success for developers coming from diverse backgrounds
🦉 Increase product exposure
  • Gamify building great product
  • End-to-end tutorial on building most complex integration
  • Developers will experience how the product itself can help them build their characters and integrations.
  • Developers will understand best practices and possibilities in context.
🦾 Help developers succeed
  • Build a friction log and begin chipping away.
  • Research successful customers and partners and magnify what went right.
  • Check in with developers with works in progress and ask how we can help
  • Go beyond the marketplace in ways to feature and highlight developer work
  • We know what to improve next
  • We know what success looks like and how it happens
  • Developers know we're interested in what they're working on and available for them
  • A rich opensource ecosystem for using the product in a diverse collection of software

Engineering a developer experience worth having

We believe that building tools and SDKs for developers is an investment leading to more productive developers and a shorter time to coding business logic.

Building SDKs enables us to better engage developers where they are and with their preferences in mind. It provides us additional avenues to encourage and reward a thriving ecosystem.

Our tools and SDKs also provide us valuable data and opportunties to guide developers to the most successful outcomes.

Event strategy

Our events strategy is conservative, opportunistic, and patient.

Every developer relations program has an events strategy. Sponsoring, attending, and hosting events can be an expensive distraction with intangible rewards.

Being where your developers are is important. Our developers are on the internet. All of them. Most developers who will ever use our product will never attend a meetup, conference, or join our Discord.

Every segment has its influencers and reaching them might happen at an event or through the press that echoes after.

But the single most important event in the confluence of our product and a developer's life is to be present, in mind, and useful in a time of need. Our event strategy focuses on making us top of mind at the right time and place, not on building a lead pipeline giving away free stuff, or building a library of single-serving content.


Audience Event Cost Goals
Python developers PyCon $5,000
  • Understand what's current and unique in the Python ecosystem
  • Connect with ML and AI developers and show them how our product fits with their interests
  • Recruit developer relations engineers to build our Python SDK


This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.

CC BY-SA 4.0