James Governor's Monkchips

20 Dos and Don’ts about Presenting at Developer Events

Share via Twitter Share via Facebook Share via Linkedin Share via Reddit

A couple of months back I presented at IBM Interconnect about developer events and why they’re increasingly important. IBM is a client and paid my travel etc.

Some of the reasoning is fairly obvious. Twilio for example, is now adding $1m in annual recurring revenue every seven days, driven by participation in more than 500 developer events in 2014.

IBM itself has been investing heavily in developer ecosystems, events and locations, through its Ecosystems and Digital Cities initiatives. It’s been running tons of BlueMix (IBM’s Cloud Foundry implementation) training events, hackathons and so on. And of course it supported the Shoreditch Village Hall venue, by Shoreditch Works, helping to fund a space in which we ran developer community events and conferences such as London Node User Group, London Java Community, and Cleanweb throughout last year.

But for traditional companies, IBM’s core customer base, the obvious isn’t always so obvious, so I put together this deck to help IBM clients (and Big Blue holdouts) understand the value of face to face interactions with developer communities, but also to provide some advice about how to come across.

So here are some dos and don’ts. I bet you have your own pet loves and hates. Please make your own suggestions.

do and dont





  1. This is a nice list. I’d be careful with the “use the slang and idioms developers use”, because if you’re faking it by using the slang, devs will know. Definitely avoid the Corp Speak, but don’t use terms unless you really understand them (unless it’s Microservices, which means whatever you want it to mean).

    My biggest pet peeve is when any presenter, and especially a vendor’s dev evangelist, starts out with how great their solution is, when I haven’t yet heard about the problem that’s being addressed and why their solution is better/different/more interesting than others out there.

    As I like to say, “start with the problem”, then explain what you did to alleviate the pain.

    1. ted – true dat. you don’t want to sound like an uncool uncle trying to be down with the kids

  2. In the best Dev presentations I’ve seen, there’ s a lot of Q&A — either during or after the session.

    1. true dat, Jay. sharing real world experiences generates great questions.

Leave a Reply

Your email address will not be published. Required fields are marked *