Practicing Developer Communications: Share Knowledge, Not Features Adam DuVander May 28, 2013 Company // SUMMARIES ?> The last four years I had a job that most developers would envy. I got to check out new APIs, play around with them and then tell everyone what I thought of them. As Executive Editor at ProgrammableWeb, I watched the number of publicly available APIs leap from less than 2,000 to more than 9,000. And it’s still growing, more rapidly than ever. Yet, now I work for SendGrid, which represents a small percentage of all APIs in existence. How does that make sense? My entire career has been built around explaining technology. When I was an active developer, I needed to investigate new tools and decide how to implement them. As early as 2000, I wrote programming how-to articles on Webmonkey. Later I blogged for Wired about development topics, with a blend of news, analysis and instruction. Then I wrote a whole mapping APIs cookbook to help anyone to be able to create geographic-enabled websites. It was while considering the entire API landscape that I realized the implications of every company providing APIs. That means every company needs to interact with developers. You probably don’t need me to tell you that some are better at this than others. I believe the solution is simple: share knowledge, not features. It might run counter to traditional marketing, but then developers aren’t traditional people. Why SendGrid? Since I’ve reviewed thousands of APIs, I have seen many great examples and even more bad examples. I developed the Three Cs for developer portals (clarity, cost and community), but I realized to truly understand I needed to see the process from the inside. At a number of events, I was impressed by SendGrid’s developer relations team. And I saw an opportunity to scale their efforts with content. Also, I invented SendGrid. While our founders may debate the semantics of that statement, what I mean is that I understand the problem. Email is the nerve center of my life, as it is for many. Sending email from applications is really hard to do reliably. Back in 2006 or so, I went to several email marketing companies asking to help me send transactional email, such as password resets and welcome messages. They didn’t understand the problem. Developers understand the problem. In 2009, Isaac, Tim and Jose decided to solve it. I don’t just understand the problem SendGrid solves, I feel it. And while I’ve been a fan of SendGrid’s developer communications, I also see a lot of opportunities for me to improve our approach. You’ll see more technical content on this blog, as I encourage the super smart SendGridders to share their knowledge. I’ll keep myself busy writing, editing and speaking, trying to tell the story of modern developers. I’ll be explaining technology, like I always have. And I’ll be listening, a key piece of any communication, but even more important to understand what does and doesn’t resonate for developers. So, please be vocal, and let me know what matters in your life and how I can help.