Invited Keynote: Engaging Developers Steven Goodwin, Award-winning CTO, author, keynote speaker, and developer.
I’m pleased to welcome Steven as an invited keynote. I can not recommend more highly spending the time to listen to Steven’s presentation. I run TADHack, I help a diversity of businesses engage with many different types of developers around the world. The core issues are well-addressed in Steven’s presentation.
If you have any questions please either ask Steven directly (his contact details are in the slides) or ask in the comments section of this weblog. Don’t be shy, you’ll be glad you asked 😉
The problem: People are not engaging with your product, and going elsewhere. Maybe they try a couple of things, once, and then stop. Or they don’t continue their trial. Or they do something totally convoluted, using up unnecessary bandwidth, CPU cycles, or support tickets. What can you do?
The cause: There is no good onboarding for new developers. We don’t need an encyclopedia of the API’s functionality, but rather a piecemeal approach to solving our problems – and quickly. Because if your API doesn’t let a dev get X, Y or Z working quickly then there’s another vendor out there just waiting to accommodate those developer dollars.
The solution:
- Treat documentation like its own product
- Outline the vision
- Create user stories
- Build an MVP
- Try before you buy
- Staff it
Steven will go into the hows and whys of improving your documentation for developers. You can read more about what Steven will talk about here.
There are many gems throughout this presentation. The key is a mindset, treat documentation like a product.
Twilio, Google, etc have set the bar on developer expectations, you have to be as good, you have 20-30 minutes to prove this else developers will go elsewhere. There are tools like Postman and Swagger that help you cover most languages, use them. User stories are critical as it helps a developer find in one place how to do X. Not part of X, but everything from sign-up to implementation in their preferred language.
The only thing I’d add to Steven’s presentation is “be human, not corporate.” Developer relations is about helping people, not brand positioning and corporate messaging. Too many corporations have their corporate marketing group manage developer relations, and it shows because its corporate not human.
I know this looks like a large and expensive hill to climb, but with the right mindset, and an incremental approach (focus on specific user stories). You can be successful in engaging your target developer groups.
Thank you for an excellent keynote 🙂 I have 2 questions:
AQ1) If you’re targeting B2B developers. Say developers in a channel to market for your business, e.g. system integrator, rather than ‘general’ web developers. Are there any changes to your advice?
AQ2) At TADHack real time chat, rather than trouble tickets, works well for engaging developers. I remember in Tropo’s early days they used IRC and developers loved that. But it’s resource intensive. What’s your view?
Q1 – No change – you are still needing to present a roadmap that directs your customers (system integrator, in your example) on the best way to use your product, to do their job. The difference is in the material itself, where you need to focus, and what you provide.
Q2 – It’s intensive if your support people pop up like meerkats every time there’s a notification! Pace yourselves! Manage the expectation that it’s real-time and not necessarily instant-time, but highlight that there are humans online and ready to help. (And not bots, pretending to be human.) Plus, have some level 1 support folk to pick off the obvious questions.
And another one, this time framed as a fashionable ‘Would you rather…”
AQ3) Would you rather: a ‘coder who can write’, and a ‘writer who can code’, and why?
A coder, every time. If they’ve built products from APIs, and written about it, they’ve understood the mindset from the same direction as the customer. (And being coders, they’ll adopt best practise in the examples, and question the gaps in the API before anyone else.)
🙂 Absolutely agree, it’s all about the mindset.
And a couple more questions:
AQ4) Should devrels be part of a development team, or a product team, or the marketing team?
AQ5) On API abstraction, what do you recommend: low-level API or high-level ones? What factors would drive you to low or high level?
AQ6) Why is documentation so invariably bad? Seriously, I advise copy Twilio, but so few do.
4. Development. Let developers talk to developers. Devs generally perceive marketing as too phony, and product teams don’t have the knowledge or depth of detail to get where developers need to go.
5. Provide low-level at the start, to show the plumbing of the API, then build high-level (when you know the required functionality) *using those low-level APIs* It’s a sign you eat your own dog food, and makes it easier to tweak high-level APIs.
6. I also advise copying Twilio, or whomever your biz people cite as a competitor. They might not have it perfect, but it’s probably better than you! (Similarly, Amazon.com is an awful website from a UX/UI/design viewpoint, but since people already understand that site, others will copy it because there’s one fewer mental model for your customers to learn.)
As for “why” – many reasons, usually around cost and understanding. Cost of hiring people to do it, cost of getting them to write documentation/examples/blogs that you don’t believe people will use, cost of moving people to fight fires in other parts of the company, and so on. Then there’s the (lack of) understanding – not knowing why they’re writing docs, for whom, what needs to be written first, what’s most important, etc.