[This was written by Raghavan Srinivas (@ragss) from the EMC {code} team. “Rags” brings over 20yrs of technology experience in building communities around Java, NoSQL databases and OpenStack]

Philosophy of Developer Evangelism

Geoffrey Moore in is his “Crossing the Chasm” book highlights the “Technology Adoption Lifecycle” which is illustrated in the following diagram.

The role for technology evangelism is to help form a bridge between the visionaries (innovators) and the early adopters and early majority (pragmatists). The main audience is application developers defined in a very broad swatch. If successful, evangelism can create a bandwagon effect leading to significant adoption of the technology.

The goal is to inculcate mindshare and not to sell/market overtly.

We need to be able to pick Technologies/Platforms that have tremendous potential but still in the early adoption phase.

Audience

A Developer evangelist like everyone else, needs to understand the audience. Although Developers are different and quirky (especially based on geographies) there are some commonalities. The following personas are useful to keep in context.

  • Startup Developer – Usually willing to take some technology risks for high rewards. Usually uses the best tool for the job.
  • Enterprise Developer – Already on a Platform that is usually hard to supplant but has some liberty in picking complementary technologies/tools.
  • Students/Hobbyists – Catch them early. GitHub for example, has a program aimed at students (https://github.com/blog/1900-the-best-developer-tools-now-free-for-students)
  • Business/casual developers – MySQL developers, Hadoop Pig/Hive developers who can write some simple code/scripts
  • Architects/Lead/Senior Developers – Might not care so much about the “How to” as much as about “How does it fit in”
  • Decision makers – Who care more about Risk Mitigation, Compliance, ROI, TCO, etc. than about the technology or platform.

Obviously, content will have to be tailored depending on the audience. We coined a term called “Technology Decision sandwich” – a Technology decision that is made somewhere between the grass roots developer (who is our main audience) and the CTO/CEO/CIO (our secondary audience).

Technology/Platform and Timing

As it pertains to developers it’s important to discern the difference between the following (although the lines are somewhat blurred).

  • Technology – This is the underpinning for a product or platform. For example: Java SE, JavaScript, REST, Android, Map/Reduce
  • Platform – A collection of different technologies that help developers build the complete stack for a product or solution. Developers tend to live here. For example: Java, CloudFoundry, Node.js, Linux. iOS SDK, Eclipse/Android, Hadoop
  • Product – Usually a flavor of a technology/technologies or platform that is supported by a particular vendor. For example: CDH (Cloudera Distribution of Hadoop), MOS (Mirantis OpenStack)
  • Solution – A collection of technologies that solve a particular problem. For example: A solution for scaling out on the Data tier.

In general products are somewhat late in the technology adoption lifecycle. The technology/platform to be evangelized and timing is very critical. Here are some of the questions that I have asked in the past to separate the wheat from the chaff. This is not a perfect science by any means.

The right technology/platform?

  • Does it solve a/multiple Developer pain point(s) (for example: AWS, Hadoop, Docker)
  • Is there an API, SDK, code samples to ease developer adoption? (for example: AWS, Java)
  • Is there a quick idiot-proof Getting Started? (for example: AWS, Docker)
  • Does it have broad industry support? (for example: Java EE, OpenStack)
  • Is it a paradigm shift for the right reasons? (for example: NoSQL)
  • Is there Developer Support for the advanced developer?
  • Licensing model to protect from IP infringement accusations (for example: Hadoop)

The wrong technology/platform?

  • It does not really have an API or an SDK – where is the Developer Call For Action (For example: PalmOS)
  • A solution based around an existing technology that is looking for a problem? (For example: Jini)
  • Just because it’s Open Source? (For example: Symbian)
  • Does it require formal approval into a program that might take days? (For example: VMware Integrated OpenStack beta)
  • Is there a “hidden” fee?

The right timing?

  • Are there leading indicators across the industry? (technology being featured in developer conferences, portals, etc. For example: NetFlix OSS)

The wrong timing?

  • Has it already reached significant adoption? (Apple iOS)
  • Is the technology/platform already baked into products? (for example TCP/IP)

 Some of the big buckets of technologies/platforms as of today are DevOps, Big Data, IoT, Mobile (more mainstream than others).

At Sun, we picked a set of technologies/platforms and prioritized them for roughly half a calendar year and we would reevaluate them at the end. We called them Key Technologies.  We had 2 categories “verticals” and “horizontals.” Examples of horizontals are performance, scalability and so on, which might cut across multiple technologies. After all, content is king! We need to be talking about what the developers want and what they care. We also evaluated on the “Corporate friendliness.” For example a .NET was a no, no whereas an XML (which had industry impetus and no corporate impetus yet) was OK.

Traits of a Developer Evangelist

  • Been a Developer, preferably a practicing Developer.
  • Extrovert
  • Expected to be a Visionary, an explorer and a teacher.
  • Understands Technology and Business (seldom is it purely a technology decision)
  • Capable of appealing to developer, lead developers and architects (sometimes CTOs, CIOs, etc.)
  • Should be comfortable with large crowds and small audiences.
  • Should be comfortable with electronic media (Blogs, Tweets, videos, podcasts, screencasts, etc.).
  • Technical chops (although may not write production quality code)
  • Polyglot (multiple languages, multiple platforms, etc.)
  • I would add a good understanding of DDS (https://sites.oreilly.com/odewahn/dds-field-guide/) in keeping with current Developer trends.

In general you need to be able to:

  • Assume you report to them although your paycheck might be coming from your employer.
  • You are their BS filter – You need to build credibility one developer at a time – never lie or make up things.
  • You may not know everything (nor are you expected to) but you need to have a broad understanding with a capability of going deep (T-skills)

Artifacts

  • Blogs
  • Tweets
  • Getting Started guides
  • Demos
  • Podcasts and Webinars
  • Session recordings, Screencasts
  • Hands-on Labs
  • Code

The golden rule is to be able to “reuse, reduce and recycle”. If you are able to build a Hands-on Labs, you should be able to break it up into distinct parts that you can create Blogs, Screencasts, Podcasts, and so on. Some other guidelines are

  • Less is more – don’t try to cram too much and cover too many topics.
  • Leave room for questions – I hate when a speaker takes the entire allotted time.
  • No death by Powerpoint – Shake it up a bit!
  • Incorporate some demos – Yes, even the most technical talk should have a demo.
  • Plan B for demo. – Demos don’t always work! Have a plan B (a pre-recorded demo. That you could voice over, a snapshot of a working demo., etc.)
  • Absolutely include code – Keep it short and sweet.
  • Provide a couple of takeaways – In any artifact there should be a couple of key takeaways and a call for action.

Venues/Formats

  • Keynote presentations/demos
  • Session presentations
  • Bring Your Own Laptop Hands-on Labs/Hackathons
  • Panel moderator/panelist
  • Booth presentations

Microsoft evangelist Don Box said, there is so much crammed in the minds of developers. You can only affect that slightly. Their time is precious so make it count!

The popular presentation I delivered worldwide was a session on “Java Puzzles.” It turns the interaction around. The speaker speaks a bit; the audience think and usually walk away with a very good understanding.

In line with the audience participation, don’t be afraid to try some unique formats. A highly successful format was a “shoot out” of different languages (Scala, Groovy, etc.) that I dubbed the “Script Bowl” in which the audience vote for the winner. This has been going on for about 8-9 years now.

In general, I have found the booth presentations to be the least effective unless they are after a talk and you have an opportunity to interact with your audience on a 1-1 basis.

I’ve also found that as a Developer evangelist, it’s good to be at company events (like EMC world) but you don’t need to be preaching to the choir. You also need to be at 3rd party events (like OpenStack summit,  JavaOne, LinuxCon, etc.).  Maybe even competitor events. It would be great to have a mix of large events (like OScon) and small events (like No Fluff Just Stuff, InfoQ, etc.).

Keeping up and providing feedback

Since the job of an evangelist is at the cutting edge of technology, it’s a big challenge to keep abreast of changes in the technology and industry. The following methods are usually effective.

Focus on a few technologies/platforms. Have a direct line with the difference makers (for example the PMs, architects). I have also found it great to build a personal connection with the skeptics within a group who are not afraid to voice their opinion.

  • Attend leading-edge conferences in the technologies concerned (like OpenStack summit)
  • Following blogs, tweets of other industry leaders and having them on speed dial
  • Participate in industry standards (I participated in a W3C/IETF xmldsig Working Group). The problem here is it might be a huge time sink. However, you can help engineering groups in uncovering holes in their technology portfolio.
  • Invite internal and external audiences and maybe the evangelists themselves for a “technology sharing” session on a periodic basis (weekly/monthly). There will be lean weeks/months when most folks are not traveling.

Tools in the Developer Evangelist arsenal

To encourage developer participation, it will be great to have/provide

  •  “Demos, Demos, Demos” – Short demonstrations that excite developers
  •  “Gadgets” – Developers and evangelists have a common interest in gadgets.
  •  “Gifts”  – Providing some discounts for participation in programs/conferences. For example, AWS gives out “free time” on AWS for HOL attendees.
  • “Guest Blogs/case studies/demos” – Ability to let a 3rd party developer do the evangelism on behalf of you.

Scaling for wild success

The idea is that we will be resource constrained and if we do our job well, we will be even more resource constrained. So, the goal is to scale. At Sun we had the following programs (although my involvement as an evangelist was at varying degrees)

  • User Groups (we would provide content/speakers/swag/logistics support)
  • Internal and external Champions (like the Microsoft MVPs)
  • Evangelist-in-a-box (for internal and external champions)
  • Campus ambassador

Measuring Success

Each program had it’s own success metrics. Measuring the success of an evangelist was a bit more informal. The metrics that were used was.

  • Credibility within the company and industry
  • Butts on seats for events (talks, webinars, etc.)
  • Formal/informal feedback from talks
  • Quantity/quality of artifacts produced

 To a lesser degree the following were used as well.

  • Effectiveness of providing feedback to product groups
  • Ability to turn some engagements to sales leads (this is was certainly not a main goal. Only a side effect)