At Keen IO, our team ran a program called “Pair with Me”. Using video calls, the program introduced our API to new signups and taught them how Keen IO worked. This led to countless conversations with developers at a crucial moment in their journey with the platform.

How did it work? Each time a developer signed up, they received an email from an engineer or advocate that offered a 15-minute pair programming session to help the developer successfully make their first API call and answer any questions. 


During the call, the Keen advocate would offer to discuss data modeling, schemas, event collection, and how to build their first dashboard. If the developer wanted, they could also just talk shop about analytics or infrastructure or company culture—it was all fair game.

Good advocacy builds trust by meeting the developer where they are.

All developer products have a milestone that represents product activation, like first API call, deployment of an agent, or completing a set of activities on a dashboard. Onboarding flows achieve activation with step-by-step flows, usually in a UI or CLI.

In most cases, developers are unsupported during their onboarding experience. In fact, most companies work hard for that to be the case. That’s great: the self-led onboarding should be as fast and frictionless as possible, and the majority of developers won’t want to interrupt their flow to talk to someone.

But whenever devs experience a point of confusion or need to make a complex decision, facetime with an engineer can help.

At Keen, new developers weren’t necessarily intimidated by making their first API call. They could be intimidated by bigger questions like data modeling, dashboard creation, or how to think about their overall analytics strategy, even at the product level.

That kind of fear and uncertainty is hard to resolve with docs alone, but can be addressed efficiently through a chat with an empathetic expert.

Facetime onboarding helps get developers up and running with the product, but there’s another type of benefit too: 

The chance to talk to a real human reduces psychological barriers to joining the community in the future.

 In person, the Keen team was able to demonstrate that the community would be welcoming and helpful if the developer wanted to participate.

 = adding value for other community members for the first time

That’s important, because product and community activation go hand-in-hand. If users don’t activate with the product, they can’t fully participate as community members, and if they don’t participate in community, they can’t become 

Ready to add some facetime to your developer activation process?

 for the next post about how to offer facetime in a way developers will actually go for.

Why a hands-on approach to activating developers actually makes sense.

How Facetime Can Improve Developer Onboarding

? I'd say the judges made a most welcome choice 😉 👍🏆 

Woman holding trophy with confetti falling

The DEV community has quickly become one of my favorite places to hang out for discussions about programming and life as a developer. Want technology explained in a 

DEV is also a very useful platform for expanding your online developer relations presence. DEV has many thousands of developers who are interested in learning new technologies and a very capable publishing platform with built-in distribution.

Check out my step-by-step guide to get your team up and running:

I'd love to hear from you if you find the guide useful or have something to add to it, just add a reply to the post on DEV. You can also 

Learn how to create a presence for your DevRel team on the welcoming, fast-growing DEV community site.

Our guide to using DEV for DEVeloper relations

One of the most common questions we’re asked by founders and execs is “When should I hire my first developer advocate?” This is no surprise to us. More and more companies are developer-focused, or at least offer an API, and have come to grips with the fact that marketing and sales aren't the right tools for driving product or platform adoption. That’s why we say 

Jobs in developer advocacy, evangelism, and community are more in-demand than ever, attracting and retaining a developer advocate is less about stats like funding or company size, and more about organizational readiness.

Before you ask, “When should we hire a developer advocate,” we recommend asking “Are we ready to hire a developer advocate?” 

The latter question will help you focus your efforts through understanding what kinds of activities will impact your business the kind of person you should attract.

Before we dive in, let’s clear the air on role terminology. The titles developer advocate and evangelist are often used interchangeably, but developer advocate is the more modern choice and the one that we recommend. Developer Relations is the umbrella term for the team and a set of programs and practices. A “DevRel” can refer to anyone doing developer relations, be it a developer advocate, evangelist, or technical community manager.

So how do you know when your company is ready to hire your first DevRel?

Before you make that hire, you should do two things:

 — by the time you’re ready to hire an advocate, your team has been doing DevRel activities for some time, ideally for at least a year

 — you know what type of DevRel you’re looking for and you have defined expectations and success criteria

Many assume the first step to hiring an advocate is to post the job description. But unless you’ve done DevRel yourself and have clearly defined the success criteria, you’ll experience at least two types of negative outcomes.

First, hiring will take longer than you expect, since your job description won't resonate with the right candidates and you probably won't have a good way to assess a good fit. As a result, you may never close a hire at all. 

 make the hire, burnout is infinitely more likely because the new advocate won’t get the support and understanding from the rest of the team that they need.

Want to avoid these bad outcomes? Let’s dig into each point to understand how you can avoid the common pitfalls of building a DevRel team.

Today, here are far more DevRel job openings than there are people to fill those roles. One 

 we track has more than 250 open roles at any given time. As a result, DevRel folks can be picky and deliberate about the companies they work for and the products they work on.

You will find it hard to hire a developer advocate if you haven’t invested in the role yourself.

DevRels are attracted to teams with a clear track record of valuing DevRel activities, especially when it’s clear that the founders are fully onboard. In fact, 

your first DevRel should scale what’s already working, not completely start from scratch.

Before you open that job req, consider how you can demonstrate that DevRel is 

That’s why our first piece of advice for founders on this point is to spend some time doing developer relations yourself. This is particularly true for technical founders. Yes, this can be a lot to ask, but we’ve seen the investment payoff in many ways.

First, you’ll know exactly what it takes to be successful in the role.

Second, you’ll have demonstrated to the DevRel community that you’re serious about investing in developer relations, which can help build confidence in and credibility for your company. 

DevRels put their reputation on the line for the companies they represent, and companies with no history of participation represent unknowns and risk

One way to start doing DIY DevRel is to get the whole company writing developer-centric content, especially the engineers. This includes defining and facilitating the content production pipeline yourself, or partnering closely with marketing to deliver a cadence of useful technical content.

You should also keep an eye on speaking opportunities for relevant audiences. Submitting “Calls for Proposals,” or CFPs, is a common task for many DevRels. Doing CFPs and speaking at events will not only get you in front of potential users, but also help you understand the processes and challenges your future DevRel will experience when they’re on the road.

Partner with companies that have more mature DevRel programs

Look for companies with complementary technologies and co-host events with them. This results in visibility for your brand, key learnings from the field, as well as intros to potential hires. These partnerships are a great way to bootstrap an early-stage program.

Content, speaking, and partnerships are important and visible aspects of a DevRel program. 

More visibility, for you personally and for the company, leads to more trust in the community—and trust plays a critical role in getting developers to adopt your technology.

In addition to seeding trust in the community, your hands-on role in these areas will create process and infrastructure for your new hire, while differentiating the role among a sea of other competitive openings.

The second way to prepare for your first hire is to ensure you have clear expectations for the DevRel’s role and success criteria.

To do that, first determine the types of activities that will have an impact for your business. 

 represent three buckets of typical DevRel activities

, and after doing DevRel yourself, hopefully you have a POV on which of those areas you want your new DevRel to focus on.

What kinds of outcomes in each area will impact your business goals?

What percent of their time and energy should your DevRel invest in each area to achieve those outcomes?

This exercise will help you avoid a common failure case: expecting one person to spend 100% of their time on all three areas.

Second, consider the DevRel archetype that will be most effective for your organization. Just as there are different types of PMs and different styles of marketers, there are multiple DevRel archetypes.

Here are a couple of the more common we’ve seen.

These folks are deep experts on a specific language, platform, and/or community. They tend to work alone in service of that community, though they’re very active in online discussions and in person. Not all developer advocates are developers, but the ones that fit this archetype usually are.

They tend to travel frequently to deliver talks in their area of expertise and present at meetups. They often generate a lot of content based on their learnings from the field and in the community.

This type of DevRel bridges the gap between internal teams and external users, and up to 50% of their job could be collaborating internally to help the company understand developers.

They create processes and programs to help engineers publish blog posts, help product teams get developer feedback, organize events, or manage and showcase the accomplishments of the community.

They are knowledgeable about the tech they represent, but are not necessarily a developer or an expert in adjacent technologies.

For any archetype, realistic expectations are key

There’s plenty of nuance to common DevRel archetypes, and this list isn’t exhaustive, but here’s the main idea: 

no DevRel can be successful if they’re expected to play too many roles

: hiring for force multiplier, but evaluating success based on subject matter expert expectations, e.g. number of blog posts or lines committed.

Your job description should incorporate your expectations around activities and outcomes, and should highlight aspects of the archetype your company needs. And ultimately, once you make the hire, your reporting and goal setting should be based on the expectations you set.

By following these steps, you’ll learn a lot about how DevRel can impact your business, and what’s necessary for program success. Along the way, you’re certain to learn lots about developers in your community, and even build some empathy for them as well as for your DevRel team.

Ultimately, you’ll avoid this common and tragic result: "We didn't really know what we expected, but it's not working out."

Two steps to increase your chances of a successful hire and reduce the likelihood of burnout. 

Laying the Groundwork for a Successful Developer Relations Hire

Developer relations can serve as a force multiplier within a company, since DevRel folks routinely work with multiple teams across an organization. But without clear expectations and alignment, that impact won’t be realized, and lots of people will be left underwhelmed and frustrated.

To help companies better leverage their DevRel investment, we partnered with our friends at 

, an accelerator and fund for developer and enterprise startups, to deliver a three-part series exploring the opportunities for collaboration between DevRel teams and their peers in Marketing, Sales, and Product.

Each article explores best practices and offers tips for applying each idea. 

Collaborating with Developer Relations Part 1: Marketing

Collaborating with Developer Relations Part 2: Sales

Collaborating with Developer Relations Part 3: Product

How DevRel can partner with Marketing, Sales, and Product teams for maximum effect.

Collaborating with Developer Relations: a Three-part Series

I was really pleased and impressed with the 2019 edition of 

: 2 days + 1 for workshops, 3 tracks, and over 50 talks. There was also a karaoke night with augmented reality 🎤😎

DevRelCon London is a part of a series of developer relations conferences that take place around the world each year. The events are touchstones for the tight-knit DevRel community.

Communities aren’t funnels: Try the Orbit Model

 instead, which unpacked the marketing funnel's 122 year history, showed why it doesn't work for building community, and explained how the Orbit Model works as an alternative.

I wasn't the only person talking about the funnel. A Tuesday morning talk from 

 Success is a combination of many different moments and interactions.

Can't see the tweets? Disable your ad blocker for this site and try again.

Here's another slide from Steve's presentation:

Talking about the funnel tends to hit a nerve with DevRel folks. This moment was captured nicely by 

Sarah Thiam, a DevRel PM for Azure, gave a talk about authenticity, tracking your community in privacy-respecting way, and the value of relationships.

Jessica West gave a talk about the importance of getting executive buy-in and how to do it. The questions on these slides are worth memorizing.

, which is a great model for thinking about how to track the DevRel's team contribution across the organization.

Did you know that the marketing funnel is 122 years old? Zoom in on the tweet below to see who invented it, and see a lot more talk photos in this 

The video of the full talk will be coming out soon, but for now you can get the 

 team for the amazing job they do, not just with DevRelCon London but the global series that includes events in San Francisco, Tokyo, and China. I honestly don't know how they do it with such a small team. H/T!

Lastly, the team at Orbit wants to publicly high-five 

. Mary is more productive personally than most medium-sized teams. She supports this community in so many ways including her 

, mentoring, and all the wisdom she shares on Twitter. Congrats Mary! 🏆

If you haven't been to a DevRelCon yet, I highly recommend it as a way to learn more about the profession and meet some truly remarkable people. The next one is in 

A roundup of tweets and slides from DevRelCon London 2019, plus a special congratulations.

DevRelCon London 2019: Tweets, photos, and congrats

Hi, we’re Orbit, and we’re building a company based on the principles of developer relationship management.

Since getting started in August, we’ve signed on investors and advisors including 

, and a world-class group of angels who have extensive experience building developer-centric businesses, including James Tamplin (co-founder and CEO of Firebase), Sam Ramji (Apigee and Google), Andrew Miklas (co-founder and CTO of PagerDuty), and Aghi Marietti (co-founder and CEO of Kong). See the full list below.

Our core product combines data, a powerful API, and a modern user interface to give organizations deeper insight into their developer communities and better tools for growing and managing them.

If you’d like early access to Orbit, please drop your email address in 

We’re creating Orbit because convincing developers to adopt new technologies is hard. Developers famously reject traditional marketing and sales efforts, preferring to learn from people and communities they trust. As a result, founders and operators of developer-centric businesses struggle to adapt existing CRMs and marketing automation tools to the developer use case.

We believe that people working in emerging disciplines like developer experience and developer relations need tools built specifically for their needs. 

Tools built on the right principles for building communities, like the 

Orbit has three co-founders—Patrick, Dustin, and Josh. We've known each other since working together at analytics API company Keen IO, and each of us has spent a big part of our careers working with developers.

 was Keen’s VP Engineering and went on to lead the developer relations team at Algolia. After Keen, 

 led customer success for machine-learning company Figure Eight. 

 spent the last two years at Apple designing and making internal tools for developers. Patrick and Dustin live in San Francisco, with Josh a mere nine time zones away in Paris.

Leading up to Orbit, Josh and Patrick created DeveloperMode, an agency that helped companies with developer relations. We’re now 100% focused on Orbit and aren't taking on new clients, but we're always happy to chat with companies wanting to improve their developer adoption, just send us an email at 

We'll share knowledge, experience, and company updates here on the 

If you work on developer adoption—as an advocate, evangelist, community manager, marketer, or founder—then what we're building is for you. 

If you'd like early access or are open to sharing your ideas on what Orbit can help you achieve, drop your email in the form below and we'll follow up.

Thank you to all of the angels who invested in Orbit’s pre-seed round:

James Tamplin (Firebase), Sam Ramji (Apigee), Andrew Miklas (PagerDuty), Aghi Marietti (Kong), Nina Khosla, Guillaume Montard (Bearer), Martyn Davies (Nexmo), Lou Kosak (AirBnb, Plaid), Michelle Wetzler (Twilio), and Kyle Wild, Dan Kador, and Ryan Spraetz (Keen IO).

Orbit helps companies drive adoption by understanding and growing their developer communities.

Introducing Orbit

The Orbit Model on GitHub

The funnel is widely accepted in sales and marketing circles, but despite its popularity, we think it has a few shortcomings when applied to developer relations:

, and not other kinds of relationships between a company and its audience

, i.e a person is either a lead or not a lead, and if they’re not a lead, we don’t want to bother with them

For certain teams, the funnel remains a useful model. In fact, many marketing teams are judged on how effectively they move leads through the funnel.

DevRel teams need tools and models created specifically for our discipline

, and not just those adopted from other fields.

That’s because other models assume a specific kind of buyer-seller relationship, but developers don’t shop in the same way as other B2B buyers.

For example, a dev might use a tool for years before purchasing. Or they might never purchase at all, but given their influence, they might refer dozens or hundreds of paying customers.

That person deserves attention from the company because they can influence growth, but the funnel doesn’t know what to do with them. Short-term conversion is the wrong thing to optimize for, so how else can we effectively model this kind of relationship?

Creating consistent, authentic connection opportunities between developers is the most reliable way to introduce new tools into the developer community and help them grow.

Connection is people-centric, not stage-centric, and therefore excels at producing that most important of moments—the moment in which 

one developer passionately refers your product to another

, an essential type of growth in a situation where 

. Word-of-mouth referral can happen in many contexts, both online and offline.

The mission of a developer relations team following the orbit model is to facilitate high-quality word-of-mouth exchanges.

But given time and budget constraints, DevRel teams can’t dive deep with every developer in the community, so how can you create context for connections at scale? Whether we like it or not, good strategy is all about hard choices, and one of the most important choices DevRel teams make is how to give different groups appropriate levels of engagement.

The Orbit Model accounts for the complexities of community, and allows DevRel teams to segment developers more effectively,

 and then to take action by facilitating connections between developers with and across segments, pulling the community together as a whole.

The first step is segmentation, but given the complex nature of the developer relationship, the linear nature of the funnel’s stages don’t work well. 

Instead, try to think about grouping your audience into levels of orbit

Orbit levels aren’t set in stone, and you should tailor your levels for your situation, but we find that 

 works well for most developer-facing companies.

 an inner circle of developers that are highly satisfied, knowledgeable users of the product and have a large influence in the broader developer community

 speak at conferences, organize events in local communities, run workshops, build plugins and integrations, amplify announcements, be a customer reference, and 

 visibility, help building their brand, exclusive or early access to features, direct lines of product support, speaking engagements, training, free product usage, overall to 

: 1:1 email, Twitter DM, messaging apps, shared Slack channels, video calls, IRL, i.e. make it personal

: a wider circle of developers who are passionate about the product, have successfully used it, and are happy to share their expertise with their sphere of influence

 contribute to documentation and SDKs, build hackathon projects, write blog posts, moderate forums and chats, build showcase projects, give detailed feedback, attend and speak at meetups, attend conferences, beta test new features, host internal workshops, and 

: learning opportunities, reputation-building, speaking opportunities, special swag, discounts, higher quotas, financial support and resources for their community

: Owned community chat/forum spaces like Slack, Discord, Spectrum, Discourse, GitHub issues and PRs, social media, IRL at events

 developers who are actively using the product, and who at a minimum have some online or offline interaction with other developers

 introduce the product to colleagues, be the champion in a deal, upgrade to a paid version, try out new features or related products, and 

: a fast and reliable product, solid documentation, well-maintained SDKs, high-quality support, extensive library of demos and examples, generous free tier, reasonable self-service pricing, swag

 customer support, office hours, product-centric email campaigns, feedback widgets, on unowned developer channels like StackOverflow, Reddit, HackerNews, DEV, et. al.

 the rest of the developers who’ve shown interest by signing up, trying out or subscribing, but aren’t active and 

: read content, browse high-level documentation, execute lightweight code samples, play with an example app, participate in games, contests and challenges

: Quality on-trend technical content, high-level product-centric content that explains use cases, guides and tutorials, starter kits, community projects, social proof, games, entertainment

 Content marketing, newsletters, advertising, brand awareness

So how do you know what developers go into which orbit? There’s a general equation that’s driving the segmentation above. It looks like this:

, a function of sentiment and product familiarity. 

, a function of the size of the developer’s sphere of influence and their authority within it.

 If there’s no love, reach doesn’t matter because there won’t be anything valuable to say. If reach is zero, there’s no one there to spread the love to.

Gravity (Love x Reach) is the criteria for segmenting developers, 

but it also provides a clue for increasing the value of your community

The higher the gravity, the lower the orbit.

The ultimate goal of the Orbit Model is to help you 

maximize the amount of gravity in your solar system

. Gravity is a force of attraction. The higher the levels of developer love and connection, the better your community will be at attracting new developers and encouraging existing members to participate more.

To build a high-gravity developer community, DevRel teams following the Orbit Model should:

make connections in and across orbit levels

offer the right opportunities to developers in each orbit

encourage the right people to move inward and commit more

make it easy for developers to share their love

How can this be applied on an everyday basis? Here’s an example that should be familiar to any DevRel.

Let’s say we’re launching a new feature and want to email folks about it.

Orbit level is a way we’d segment the message. Orbit 1 (O1) and Orbit 2 (O2) might get a message earlier with an ask to help beta test coupled with more detail or transparency that wouldn’t be appropriate for a mass mail, but would be more likely to drive engagement with them. We would then tweak the mass distribution to O3 and O4 based on input and feedback from O1 and O2.

Want to apply the Orbit model in your DevRel team? It’s a big vision, but the orbit model can be adopted incrementally. 

Start with O1 by creating a spreadsheet and filling it with your most engaged and influential developers.

 Then moved up to O2. For both O1 and O2, list out what you can ask them to do and what you can do for them in return. Create some next steps to make that happen and you’re already off to a great start 🚀

In the future, you can incorporate the model into your CRM and top-level KPI reporting, but today you can already get value from segmenting your outreach.

DevRel teams need tools and models created specifically for our discipline, and not just those adopted from other fields.

Orbit Blog