“If you treat your developers well, then they will (for free) provide you with valuable insights about ways to improve your API, and they will evangelize your API for you.”

—Pamela Fox, The Developer Support Handbook

Just over six months ago, I started working at Iron.io as a software engineering intern. I quickly diverged from my intended purpose, though, mainly because I’m really bad at following instructions.

As of today, I’ve been upgraded to full employee status, with a title change that more accurately describes what I do. I’ve become their first Developer Experience Engineer.

I know, I know. What the hell? That’s the wankiest title I’ve ever heard of. But it’s actually pretty accurate. My job at Iron.io is to do anything I can to make sure that people who develop on our platform have the best possible experience. That is my responsibility. It manifests itself mainly in the ongoing work I’m doing with our Dev Center, but it has developer outreach parts, it has higher level strategy parts, it has a lot of connotations that come with it. It means I offer feedback and suggestions on new products. It means I write client libraries and examples. If something will make using Iron.io’s services easier, more enjoyable, or more effective for our customers, I’m supposed to be doing it or helping someone else do it.

That’s a tall order. The job is modeled heavily after Developer Evangelists and Developer Advocates, but with a more holistic approach.

I wanted to take a moment to lay out the principles that I hold above all others for this job, as I think they explain things a lot better than I can:

• Never sell anyone anything. I have been accused of blatantly advertising Iron.io’s products. I want to make a promise, right now, that I will never try to do this. I do not believe that the cloud is for everyone. I do not believe that Iron.io can solve every problem. I do not believe that getting a user to sign up under false pretenses is a good thing. Iron.io’s services are all pay-per-use. That means if you stop using them, we stop getting paid. Even if I trick you into signing up, you’re going to figure out pretty quickly that the solution isn’t right for you. We’re going to lose you as a customer and will have most likely made nothing. You’re going to tell Twitter and Facebook and Google+ about how our products suck, because you’re not using them in the right situation. Nobody wins. Instead, I’m going to try to help the people whose problems can be solved by Iron.io’s tools to solve their problems. They get a solved problem, we get a happy customer, everyone wins. Doesn’t that seem like a much more enjoyable job to you? Me too. That’s the job I’m going to do.
• You owe us nothing. If you aren’t reading our documentation, it’s because our docs are too boring and dry. Or maybe they need better navigation. Or maybe they should be more interactive. The point is, you have a choice in who you host your software with. If we don’t make it as easy as possible for you, you’re going to go to someone who will. Plain and simple. “The developer should do more work” is not a valid answer, no matter what the problem is. Using our services is supposed to make your life easier, not trade out your old work and annoyances for new work and annoyances.
• I’m not too busy for you. I don’t care if you’re from a one-man shop doing a weekend hack or if you’re Google. If you need help, you deserve nothing less than the best assistance I can offer you. Sometimes that may not be enough. That’s regrettable, but inevitable. I’m a limited human with limited time. My inbox will always have room for developers who need help, I will always do my best to respond on Twitter or Google+, and I will do my best to ensure that no question is met with silence in Iron.io’s public support chat room. I can’t build a better developer experience if I don’t know what developers are experiencing.

I’m very excited to continue my efforts at this, even as the daunting size and scope of the job intimidates me. I hope that my efforts in the next six months will help to make me more available to you and will help to make you more productive at what you do.

An intuitive and adaptive product renders examples unnecessary. Illustrative examples render documentation unnecessary. Clear, concise, and useful documentation renders a support channel unnecessary. A support channel makes sure that all other failings do not leave anyone stranded.