When and How to Offer 1:1 Onboarding to Developers

In our last post, we suggested that, with the right developer, 1:1 onboarding could increase product as well as community activation, resulting in happy and successful developers and a more vibrant community.

It also helps you learn exactly where new developers get stuck and turn that into valuable feedback for product teams.

That sounds good in theory, but will developers actually want to talk to you? Not everyone, and that’s okay. The ones that do are likely working on an important project or genuinely interested in solving their problem, and that’s exactly the kind of developer you should be spending time with.

To avoid the spam folder and be truly helpful, you’ll need to ensure several parts of your program are developer-centric. Here are some tips for doing just that.

👐 The right offer

No developer wants to “just jump on a quick call.” That kind of offer doesn’t provide clear expectations about why the developer should invest their time, and will probably be ignored. Instead, work to understand where and how developers get stuck, then tailor the offer to help.

Try a subject line like "Invitation to pair" versus something like "Checking in on progress.” The former is a clear and helpful offer, while the latter isn’t clear about the benefit to the developer.

Keep in mind that many developers prefer asynchronous communication like chat to synchronous communication like meetings.

Offer different approaches to connecting with developers, including:

• Sharing a Calendly link to book time
• Starting a DM conversation on a community Slack
• Chatting via messaging tools like WhatsApp

Bonus round: if you really want to go above and beyond, make a dev-friendly landing page with program details and testimonials from developers who participated and found it helpful. Add photos and bios from the engineers they’d connect with and describe what to expect. This builds trust that they’re in for a good experience.

It has to speak developer

When reaching out, be sure the message sounds like something one engineer would say to another. Avoid marketing adjectives and adverbs, and get right to the point.

Offer to help with any questions they might have, product-related or not. That’s because advocacy extends to adjacent things they might need help with too.

If possible, tailor the language of your outreach to include specific context related to their favorite languages or frameworks. This is one area where keeping track of your community member’s interests in a tool like Orbit can be helpful.

🕰️ Timing is everything

There are several points when a developer is more likely to accept your offer to talk.

Right after signing up

Following signup, your tools are top-of-mind for new developers. Instead of making the offer at the exact time of signup, though, consider sending the invite a day or two later, once they’ve had a chance to skim the docs and try a few things for themselves. By then, it’s more likely they’ll have generated some interesting questions for you to discuss.

Based on product usage, or lack thereof

What if you sent a note to a developer after the first time the use a key feature? This can also be useful if you noticed a sharp dropoff in usage. It could be the case that they were just exploring your tools, or, it could be that they got caught on a key part of the implementation, but don’t have the energy to dig through the docs.

If so, your offer to help could be well received.

🔨 Nail the execution

To make the session more effective for both you and the dev, ask them to complete a checklist before joining the call. This might include provisioning an API key or installing important packages in advance.

At the end, you can offer some next steps. If they seem interested in your community, invite them to join your slack or forum.

Finally, ask them for permission to send a followup email with links to things discussed on the call. Make sure that email is not canned but natural and personal.

📈 Measure and scale it

To measure the program, you can compare the activation rate and follow-on usage of developers who do 1:1 onboarding against the developers who don’t. Also keep track of the time you spend on the program which will help you calculate the overall ROI.

One great way to scale onboardings is to recruit other engineers in the company to help staff the program. Not only will customers love talking to product engineers, the engineers will benefit from increased customer empathy from the calls.

Conclusion

There are lots of ways to get started with a 1:1 onboarding program, but our advice is to start small. Block off an hour a week for two sessions and see what happens. Ask marketing if they can help you send the offer to a small segment of the signups. As you learn, iterate on your findings and invest in what’s working.

Over time, you’ll learn a lot about your customers and community, and hopefully provide help to the developers who need it most.