Over the past three years, I’ve put a lot of thought into how to approach and engage developer communities around the world. I’ve experimented with running side projects, hosting hackathons and startup competitions, planning and attending meet-ups, contributing to open source projects, giving talks, sitting on panels, going to conventions, and handing out tons of high fives. And all of my various experiences have taught me one super important lesson: Be genuine, and be helpful. As Keen IO’s first Developer Evangelist, I’m tasked with engaging and growing our developer community while sticking to those two core values.
One of the first things I did when I joined Keen IO was to get with some of the other developer evangelists I know and talk with them about what they’re doing, what they’ve done, and what has or hasn’t worked. Through these conversations (and some experimentation on my part), I started to organize my thoughts about how I want to do things at Keen IO and what my main goals are going to be for the foreseeable future. I’ve segmented these high-level goals into three categories that I feel outline the different responsibilities of a modern Developer Evangelist. (Keep in mind, though, that every company needs to fine-tune how they approach community building for their specific audience.)
Outreach
Every company needs to focus on outreach in some capacity. It could be that no one knows who you are, or it could be that everyone knows who you are, but either way, you should always be working to make yourself top-of-mind with your audience. Right now, Keen IO is right in the middle of those two extremes. We’re seeing a huge amount of organic growth, but putting some extra oomph behind the brand can return big dividends, so I’ve made outreach my very highest priority. I see it as the low-hanging fruit of my job.
Our take on outreach is that spending lots of dough on conferences, hackathons, and startup competitions doesn’t really make sense at this stage. Anyone can throw a bunch of cash at sponsorship opportunities, but we really want to build a unique, human-oriented brand. It’s a better investment of our time and better fits who we are as a company.
We’re big fans of Paul Graham’s essay, “Do Things That Don’t Scale,” which is probably the best way to describe how we handle outreach today. For us, this means sending me and some other folks on the team to various tech hubs around the US (and eventually around the globe!) armed with t-shirts, stickers, a whole bunch of smiles, and plenty of beer tabs. Our goal is to high five every developer in the world — which is to say, make as many genuine connections with developers as we can.
Whenever one of us travels to a new city, we schedule a “Happy Data Hour,” where we buy some snacks and some beers and simply invite people in the community to come hang out. We’ve hosted talks, played board games with customers and friends, and even put together our own data geek version of Pictionary! Our goal is to create a fun environment where people can come relax, have a drink, and chat with some like-minded people. In the 6 weeks that I’ve been at the company, we’ve had events in San Francisco, New York, Austin, Boston, Utah, Las Vegas and Boulder, with new events already scheduled in SF and Portland in December.
But really, that’s just the beginning of what we do to help with outreach. We also
– Mail out hand-decorated care packages whenever someone requests a T-shirt via our SUPER SECRET API Easter egg
– Send hand-written thank-you notes to our community contributors
– Take every customer out to dinner when they visit SF
They’re small things, but people really seem to get a kick of them and, well, it’s pretty fun decorating the boxes. 🙂
Contribution
Having the community provide feedback and contribute to our various SDKs is extremely important and a big part of how we’re able to support such a wide variety of API clients. Helping people get things done and celebrating the work that they are doing is one of the funnest parts of my job.
A big part of me reaching out to our existing community is a) getting an understanding of how they’re using our platform and b), if they are up for it, helping them share with others exactly they’re doing. We are always looking for people to write technical blog posts talking about their Keen IO implementation
Last but not least, we have some pretty great internal tools we’ve built, and we think they may be of use to a lot of our customers, too, so we’re in the process of documenting and open-sourcing them as a way to give back. We’ll have more on that soon — we have a little bit more work to get done before we announce anything official. 🙂
Support
Of course, one of the most important aspects of my job is supporting our current customers. Our goal is to respond to customer emails within 15 minutes. We get a ton of email and can’t always hit that goal, but we do make sure we respond in less than 24 hours, no matter what. There is also almost always someone hanging around in our customer chat room, ready to help. As the newest team member, I spend tons of time in customer chat, because helping customers is really the fastest way to learn about our product. Our entire team team works on support, though, not only because it helps us keep a pulse on issues and ensures a high level of empathy with our customers, but also because it means we’re all that much more stoked when new improvements or fixes are pushed out.
One other thing that I really want to get to but haven’t gotten started on yet is helping with the document management for our API’s and SDKs. Oftentimes the real test of a company whose product is code is having easy-to-use and extremely well-documented API’s. Fortunately, our documentation is already pretty good, but eventually I want my team to support the rest of the organization in updating and containing to flesh out the Keen IO docs, possibly to the point where we own that part of the company entirely.
Like I said, this is only the beginning. I’m always open to new ideas or suggestions — feel free to send along your ideas, or hit me up for pointers if you’re building your own Developer Evangelism program.
