In an ideal world, every conference talk would be submitted through passion: passion for the subject, passion for the conference, passion to reach that audience.
When you have a distributed developer relations team, with overlapping travel schedules and inconvenient time zones, that passion can need a little help.
Similarly, once your Developer Advocacy team grows beyond one person, its a good idea to check youre not submitting similar talks to the same events.
At Couchbase our Developer Advocacy team covers coast to coast in the US and has people in several European countries.
Taking naming inspiration from the Ubuntu communitys Global Bug Jams, I created a weekly meeting and called it our Paper Jam. Each week wed get on a Skype call, look for open CFPs and collaborate there and then to write an abstract that suited each.
At first, that worked. As both our team and library of proposals grew, it was clear we needed something more efficient.
Pretty quickly, we settled on this:
Thats the easy bit.
Finding open calls for papers has been a bit hit and miss. For our paper jams, weve been using three main resources:
Call to Speakers is now our main list, mostly because it lists tech conferences in order of CFP closing date. However, there are still gaps in its coverage.
Lanyrd almost has the opposite problem: it covers many events that arent tech conferences, which compounds the other issue that makes it less useful to us: filtering simultaneously on location, date-range and theme is hard.
We fill the gaps with our own knowledge and Google searches.
Weve been using a shared Google spreadsheet to track our progress. The main things we record are pretty obvious really:
Maybe theres a better tool but a spreadsheet is good enough for now.
The process is running well for us. It has taken something that we all wanted to do and turned it into a lightweight process that pretty much runs itself.
Our main area for improvement is to formalise our library of talks. Right now, we have an unloved internal wiki page and rely mostly on just knowing what talks we have already written.
If you try paper jams, Id love to know what improvements you come across.
Photo by Tony Whitmore
The distinction between external and internal developers is largely artificial, at least when it comes to how you build APIs, according to Adobe’s Matt Asay.
Creating a developer outreach strategy means having a thorough understanding of where you want to be and where you’re starting out from.