Amit Jotwani

Amit Jotwani

Being a Developer Evangelist

— Essay Developer Experience

Last week, I was given an opportunity to give a talk at NYC Developer Evangelists Meetup and I chose to talk about what it is like being a Developer Evangelist, basing it off the lessons I’ve managed to learn in the last 9 months being a Developer Evangelist at [Mashery](http://dev.mashery.com/) . The talk was fairly well received and I thought I’d go ahead and document it, so it can be available to more evangelists and hopefully kick off some discussion/feedback around it. Intend to keep this an updating piece with tips/suggestions from fellow Developer Evangelists. [_Slide deck_ [here](https://www.ajot.me/wp-content/uploads/2012/06/Being-a-Developer-Evangelist-Business-of-exciting-people-reduced.pdf) ]


Lot of these tips & lessons learned hover around interacting with people. I thought they were relevant, given the amount of interaction we as Developer Evangelists do everyday dealing with developers.


Goal of a Developer Evangelist

A Developer Evangelist is relatively such a new role that the goals/role differ widely between companies. Following are some goals however that I feel are/should be universal across all evangelists.

  1. **Excite developers** - Our top goal as a Developer Evangelist is simple - _get people excited_. We are not here to teach people to code. Our role is to simply excite the heck out of them. Excite them enough, so they go play with the APIs/frameworks and then ask us questions. Incite their creative cells. Perhaps even sit and brainstorm with them about their ideas. This is probably the reason why hackers make the best Developer Evangelists - cause they tinker with stuff all the time and can pass on that infectious energy along. Show them the lego pieces you’ve built yourself using the API/Framework you’re evangelizing. Nothing beats that.
  2. **Make life easier for developers** - One of the other goals of a Developer Evangelist, I feel, is to make things easier for developers. That includes making sure the documentation is succinct, to the point and up to date. Developers have very little patience when it comes to reading documentation. They want spend more time building stuff, not reading stuff. _Read less. Do more_ should be the mantra. Tools like [I/O Docs](http://dev.mashery.com/iodocs) , for instance help a lot in that regard.
  3. **Creating a community** - should be one of the top goals of a Developer Evangelist. Always be building a community that evangelizes on your behalf. Let’s admit it. We’d love to be everywhere, but we can’t. In fact being everywhere should not be a goal in the first place. Your community should be doing that for you out of love. There’s nothing better than that. If your product is awesome, this job is a little easier already.
  4. **Earnestly reflect the true face of the company** - Being Developer Evangelist is a really fun gig. The fact of life is that you gotta love what you do to be able to do well. That holds especially true for a Developer Evangelist. I am convinced, you cannot be a successful evangelist if you do not truly believe in the product you’re evangelizing. All awesome evangelists do. That’s why we travel on weekends and enjoy it. That’s why we don’t wait for Fridays to happen. That’s why we don’t cringe about Mondays. That’s how we enjoy every minute of what we do. But, with great power comes great responsibility. We are the face of the company and we owe it to our peers to reflect them in good stead.
  5. **Know your company** - People expect us to know everything about our company and the industries we are in. It’s our responsibility to know as much as we can about the company and the API we represent. Right from things like when was the company incepted to the background of your CEO to limitations of your product.      * **Admit mistakes when you are wrong** - Admit where your API falls short. Have total honesty and visible integrity. Particularly the ability to admit when the competition is better, or when your technology has flaws.      * **Don’t argue for the heck of it.** Don’t be insulting. This might sound like a pretty obvious thing, but I saw this evangelist couple weeks ago argue to death with some developers over their API implementation. At some point you gotta stop and think - what am I doing here? Developer feedback, both positive and negative, is a gift. Accept it graciously.      * **Be good. Be genuine** - Don’t be a douche bag. Be genuinely helpful and good to people - even your competitors. There’s no reason to be rude or obnoxious to anyone, just because they happen to be your competitors.      * **Encourage them. Motivate them.** Drop the ego. Drop the power words. Get to the level of the developer you’re speaking with and motivate them.      * **Talk less. Listen more.** - Do not interrupt people. Ask questions without interrupting and don‚Äôt just pretend that you are listening whilst you are daydreaming. Again, be genuine and true.

Achieving the goals

  1. Being there for the developers when they need you      
  2. Be Pro-active on Twitter - Engage in conversations and answer developer queries.      * Set Google alerts - So you know what/when people are talking about your product and then act on them as needed.      * Answer questions on Quora/Stack Overflow etc  2. **Participating in Events** - Goes without saying that participating and/ore representing at events is one of the top ways to spread the love among developers. It gives you a chance to connect with the developers at ground zero. Excite them and gather feedback. Think Hackathons, Barcamps, conferences etc. If you’re not doing at least a couple every month, you’re probably doing it wrong. This is where the real fun and evangelism takes place.  3. **Creating Useful Content** - Write blog posts recapping the events you represent at on a regular basis and other related content around your product. Think event recap blog posts, code samples, wrapper libraries, talks/presentations etc.  4. **Make on boarding easier** - Falls under the goal of making life easier for developers. On boarding is a critical part in the cycle of getting developers’ attention and making sure they have a pleasant overall experience. Also includes providing awesome documentation. Again, use Read Less. Do More as a guideline.
    # Some Lessons Learned
     1. **Engage with people** - That’s why we are there. Don’t be self-involved. Interest people by talking about the subject they are interested in and not so much about what you would prefer. Remember, it’s not about you. It’s about them - the developers.  2. **Take notes at Hackathons** - you’ll need it when you do a recap blog post. Trust me!  3. _Connecting with people_ - Don’t follow everyone you meet at events on Twitter. I used to do that and it quickly hijacked my timeline. Use LinkedIn or Twitter lists instead for that. Who you follow on Twitter is sacred. Keep it clean to get maximum value out of it.  4. **Stick around. Have fun.** I’ve seen many evangelists present their APIs and then leave. That’s so stupid and mind boggling. The real evangelism happens after that demo you just gave. You need to stick around for the entire hackathon for instance. Be available when developers begin dabbling and have questions for you.  5. **Take pictures at events** - Pictures make great blog posts!  6. \*Get there early. Meet new people.\**
    # Fuck, please don’t do these
    <img loading="lazy" src="https://www.ajot.me/wp-content/uploads/2012/06/Devangelist-2.008-300x225.jpg" alt="" title="Devangelist-2.008" width="300" height="225" class="aligncenter size-medium wp-image-210" />
     1. **Don’t humble brag. They don’t care** - People don’t give a shit about how well your company is doing. Don’t show them slides after slides of what your product is capable of doing. Show them. Tell a story. Show code.  2. **Don’t be a Brand promoter or a brand manager or a social media consultant.** So don’t pretend to be one. Just be yourself. Be personable. Be responsive. Try not to get all “official” lingo get in your way. Interact and answer questions as you’d if you were talking to a really close friend. “Dude” is better than “Sir”.  3. **Don’t be a salesman** - We all hate being sold. You cannot influence people by telling them what you want. Show them how your product can help them solve their pain and you’ll never have to sell. What’s more - they’ll even do the evangelism for you.  4. **Don’t fuck up people’s names** - Remember the names of the people you meet. A person’s name is the most important sound to them in the world. Get it wrong and you’re not going to be liked very much.
    ## Devangelist Power Tips
    **FACT:** Developer Evangelists have a high burn rate. Most of us travel on weekends to hackathons and conferences. While we don’t consider that work, we do need time to recuperate and recharge our batteries.
     1. **Take time off:** Take regular time outs. This means you stay completely away from email/phone. Easier said than done I know. My boss once told me to “treat my PTO with as much diligence, conviction and execution as I treated my work. All highly functional people need downtime to be highly effective at work. Otherwise you burn out and are no good to anyone.” I have since been trying to make that my mantra. Not perfect yet. Getting there.  2. **Get enough sleep**: Given the travel and sometimes weird schedules we keep, it’s important to get enough sleep. I’ve lately started using SleepCycle app on the iPhone. It’s based on the fact that we go through sleep cycles every 30-40 mins from deep to shallow sleep. It aims to wake you up when you are on your shallowest sleeps, so you wake up more fresh. Bonus Tip: Keep the alarm away from you, so you’re forced to get up to even snooze it. Better still, keep it in your bathroom! More chances of you splashing water on your face, since you’re already there!  3. **Keep Checklists**: Every multi-step recurring task should have a checklist. Travel kit, writing blog posts being some examples.  4. **Be lazy:** As a Developer Evangelist, our goal should be to be as lazy as possible. Lazy is good. Laziness encourages us to find easier ways to do things. Laziness leads to creativity and innovation. Note that being lazy is not the same as being lousy.       * Despise typing repetitive stuff: Create Keyboard shortcuts for repetitive tasks. I use [TextExpander](http://smilesoftware.com/TextExpander/) for example to automate all my repetitive keystrokes.      * [1 Password](https://agilebits.com/onepassword) - If you’re not using 1Password, you’re doing it wrong. It balances laziness with security perfectly. It allows you to autofill your username/passwords with just a keystroke. Oh, did I mention - you still get to use unique and secure passwords.      * [Alfred](http://www.alfredapp.com/) - is my new found love. While I’ve been using Alfred for a while now as a replacement to Spotlight, I was recently introduced to the power of it’s extensions. You can write your own scripts or download one to automate pretty much every task that you find yourself doing often. Must have.
    ## Getting more done
    A direct derivative of being lazy is getting more done with as little effort and as much focus as possible. Always be looking for ways to get more done with as little effort as possible. Here are some tips around that -
     1. **Decide your Most Important Tasks everyday**: We’ve got a million things to do every day, but chances are there are 1 or 2 that are top priority. Knowing your MITs helps keep you focussed. Write it down and place it somewhere you will see it. These MITs are then the first thing you’d do. No matter what. So, at the end of the day, you’ll have the satisfaction of completing at the very least the things that mattered the most, rather than being busy all day and yet not having a satisfying day.  2. **Focus on one task at a time**: Use the [Pomodoro Technique](http://www.pomodorotechnique.com/) for instance to get the most out of your time. It’s amazing how the things that I thought would take me at least 2 hours have been done in 1 Pomodoro (25 minutes). Here’s how it works:       1. Choose a task to be accomplished      2. Set the Pomodoro to 25 minutes (the Pomodoro is the timer)      3. Work on the task until the Pomodoro rings, then put a check on your sheet of paper      4. Take a short break (5 minutes is OK)      5. Every 4 Pomodoros take a longer break  3. **Stay focussed**: Close all distractions and focus on the task at hand. Close your Email/Twitter client/IM App. I use [Concentrate app](http://getconcentrating.com/) on the Mac to accomplish this. It allows you to quit any distracting or unnecessary apps/websites and stop them from launching while a “concentration” is in progress, thereby covering those weak moments when you feel the urge to check Twitter/Facebook or launch an IM conversation.  4. **Turn off email notifications:** Do not live inside your email. Don’t spend your day just responding to emails. Turn off email and check them every 30 mins or so. Respond to the urgent ones and get back concentrating again.  5. **Powering Email**: I use Mail.app + [MailAct-On](http://www.indev.ca/MailActOn.html) + [MailTags](http://www.indev.ca/MailTags.html) to keep myself organized and top of email.       1. [MailTags](http://www.indev.ca/MailTags.html) allows you to add tags keywords, project, priority, notes to your messages, so they are easily searchable.      2. [MailAct-On](http://www.indev.ca/MailActOn.html) - allows you to move or copy messages to any folders with just a keystroke. Also integrates seamlessly into Mail’s rule editor. Very useful.  6. **Get a task list manager:** Don’t keep the todos in your head. Worse still, don’t keep them in your email. Get them all in a task list manager of your choice. I have a slight bias towards [Things.app](http://culturedcode.com/things/) . I value good UI. It’s important for me to continue using a product. I have to like the UI. [Omnifocus](http://www.omnigroup.com/products/omnifocus/) is another great task list manager that follow the GTD principles to the core.  7. **Defer reading**: Use services like Instapaper / Pocket to defer reading. Concentrate on the tasks at hand. Read these deferred articles on the subway, in the flight, waiting in lines etc.
    ## Devangelist Travel kit
    <img loading="lazy" src="https://www.ajot.me/wp-content/uploads/2012/06/Devangelist-2.014-300x225.jpg" alt="" title="Devangelist-2.014" width="300" height="225" class="aligncenter size-medium wp-image-219" />
    Every Developer Evangelist worth his salt carries a hardcore Devangelist travel kit at an arms reach. I am always prepared for the worst tech fail that can happen while I am on travel.
     1. Battery pack - Mofi or similar  2. MiFi Hotspot device  3. Stickers & similar pocket schwag  4. Chargers & display adapters  5. Kindle  6. Take that banner  7. Business Cards  8. Protein bars
    ## Helpful material (books, blogs etc)
    <img loading="lazy" src="https://www.ajot.me/wp-content/uploads/2012/06/Devangelist-2.020-300x225.jpg" alt="" title="Devangelist-2.020" width="300" height="225" class="aligncenter size-medium wp-image-220" />
    Here are some books I’ve found helpful -
     1. [Developer Evangelist Handbook](http://developer-evangelism.com/) by Mozilla Developer Evangelist, [Chris Heilmann,](http://twitter.com/codepo8) . Probably the only book I’ve seen on Developer Evangelism. It’s a really good read.   2. [How to win friends and influence people](http://www.amazon.com/gp/product/1439167346/ref=as_li_ss_tl?ie=UTF8&tag=amitajotwa0d-20&linkCode=as2&camp=1789&creative=390957&creativeASIN=1439167346) by Dale Carnegie back in 1930’s. If there was one book I had to recommend, given the amount of interaction we do with people, this would be it. Must read. Brilliant piece of work.  3. [Getting Things Done](http://www.amazon.com/gp/product/0142000280/ref=as_li_ss_tl?ie=UTF8&tag=amitajotwa0d-20&linkCode=as2&camp=1789&creative=390957&creativeASIN=0142000280) by David Allen  4. [18 Minutes: Find Your Focus](http://www.amazon.com/gp/product/0446583413/ref=as_li_ss_tl?ie=UTF8&tag=amitajotwa0d-20&linkCode=as2&camp=1789&creative=390957&creativeASIN=0446583413) by Peter Bregman  5. [ReWork](http://www.amazon.com/gp/product/0307463745/ref=as_li_ss_tl?ie=UTF8&tag=amitajotwa0d-20&linkCode=as2&camp=1789&creative=390957&creativeASIN=0307463745) by [Jason Fried](https://www.ajot.me/2012/06/07/being-a-developer-evangelist-the-business-of-exciting-people/twitter.com/jasonfried) & [David Heinemeier Hansson](http://twitter.com/dhh)   6. [Getting Real](http://gettingreal.37signals.com/) - [37signals](http://37signals.com/)
    ## Questions
    <img loading="lazy" src="https://www.ajot.me/wp-content/uploads/2012/06/Devangelist-2.022-300x225.jpg" alt="" title="Devangelist-2.022" width="300" height="225" class="aligncenter size-medium wp-image-221" />
    Like many evangelists that I bump into on a regular basis, I absolutely love what I do. This piece obviously is not the be-all, end-all of developer evangelism, but hopefully it’ll kick-off some conversation around the subject and get us all talking about what it takes to be a rockstar Developer Evangelist. So, please keep the comments/feedback coming and feel free to reach me on Twitter at [@amit](http://twitter.com/amit). Also, if you’re an evangelist based out of NYC, please consider joining the [NYC Developer Evangelists Meetup](http://www.meetup.com/nycevangelists/events/65876432/) . It’s pretty awesome!