I’ve seen quite a bit of buzz / BS around ‘engaging developers‘ at the moment. Lots of ‘frameworks’ and overly complex fluff to justify expensive consulting fees.

This weblog is biased towards programmable communications, but it’s applicable to many industries.

The critical question is, “Why are you doing it?” Until you have a defensible answer to this question everything else is a waste of time and money.

If it’s to copy Twilio’s business (copying Twilio’s API, documentation, etc. is another issue), you’ll likely fail as you’re not a developer-first organization. Your DNA will limit you at every step. It’s like asking a fish to climb a tree. Only a few can do that, and they tend to focus where they have a strong defensible advantage, e.g. TeleSign, Telnyx, Signalwire, Jambonz, etc.

If it’s for ‘innovation,’ what specific new service examples are you hoping to create? Is it to help your existing customers solve problems using your platform, like SMS notifications for time critical processes? Does the customer have its own dev group, or would they use a preferred SI, or your channel partner that deployed your platform? Work with them and build from there, often these projects become templates you can make available across all customers on your platform. Customers soon learn the benefit of building themselves to retain competitive advantage.

It doesn’t need to be developers and APIs. Ideamart built no-code templates to enable small-medium business owners to run their own notifications, marketing, and alerting campaigns. It became the dominant use case. It could equally be your customers’ and partners’ prefered use case.

It could be a group of channel partners you’re already working with, and simply extending what you do together, adding more flexibility to the solutions they build for their customers. Once you have something working with that group, extend into channel partner prospects and some techy segments of your customers. All this can be managed within existing agreements and security zones, it’s not public. 

Each partner journey should be mapped, just like customer journeys. As you make some resources public, and enable quick and dirty sandboxing so potential partners / customers can play around to see if your resources could be better for them. You’re building on a proven business, and depending on your business the “instant credit card sign-up” may not be as relevant as play for free, then BAU (Business as Usual) buy. Don’t try to copy Twilio’s business, do what’s right for you and your ecosystem.

The list of targets and growth paths can get long, that’s the opportunity. Also there’s lots we can learn from the past couple of decades of dev engagement.

Flesh out the list of targets, prioritize, and start with the low hanging fruit. DO NOT build it and they will come; no extensive websites, processes, and teams. Be incremental as both your organization and your ecosystem are learning collaboratively. Think of it like priming a pump, you’re doing something that’s rather manual, because it will later enable the process to become automated. Starting day one with the ‘grand final automated solution’ will generally result in a failure to launch as the pump is not primed.

A couple more pointers:

• On documentation, API design, etc. Just copy Twilio (copying that bit of Twilio is OK), they’ve set the bar, copy TwiML, do not invent your own. But, do not claim it’s a simple cut and paste between you and them. Just make it easy for people as they’ve likely already played with Twilio. Symbl.ai is also good for conversation intelligence / chat bot, copy, do not re-invent. I say this every time and so many think they can do better, and end up just being different.
• Do not be corporate; be open, honest, and to the point. In order of relevance of who should be talking to ‘developers’ in your organization: dev rel / sales engineering, VP Engineering / CTO (as long as they’re house trained), product managers, sales, and last and avoid if at all possible, marketing. I know this pisses off the technology marketing folks, it’s just the way things are. That’s why it’s called dev rel, not dev marketing.

Stop trying to chase some nebulous dream of dev engagement, focus on the low hanging fruit in your ecosystem and build from there. It takes time, years, but done right it’s truly amazing what can be achieved.