Event Technical Evangelism is a Game of Inches
The million dollar question in tech is as pervasive as ever — how do I get developers to utilize my company’s product in their pipeline?
Enter, developer evangelists.
The role of a developer evangelist is still relatively misunderstood by many (and for good reason), as it contains aspects from a multitude of traditionally segregated disciplines (engineering, education, marketing, HR). That being said, when segmented, a developer evangelist’s goals are to catalyze technical product adoption while cultivating a community of users surrounding said product, as well as serving as a liaison between the product’s developers and it’s users.
I won’t be going into detail with respect to all of the responsibilities of a developer evangelist here, but I hope to shed light on one aspect that has become mission critical; event technical evangelizing. Tech conferences, community meetups, and hackathons are all avenues by which technical evangelists can accomplish their goals by interacting with potential adopters face to face.
Although my experience is limited to hackathons, here are some of the small things I’ve come to learn that make a big difference in the arena of technical evangelism.
Align Values
I’ve found that the most successful mantra is to align values when evangelizing technical products — engage in a win-win situation for both the developer and your company. I first learned this during my MLH training from Nick Quinlan in the context of conflict resolution, but it works damn well for a lot of other situations as well. I don’t necessarily want to convince the developer that they have a problem that they don’t think they have (also known as a “hard sell”), but rather, I want to show them how my company’s product will mitigate their current problems, or empower them by allowing them to do things they couldn’t easily have done otherwise, all while still fitting into the scope of their desired project. I cannot emphasize the last part enough, if you have to first convince the developer that they have a certain problem, you’re talking to the wrong audience.
Avoid the ‘hard sell’.
All developers have problems, and your product will be able to solve some (if not, all) of them. Being able to connect the problem-havers (developers) to the problem-solvers (yourself and your product) is a critical part of successful technical evangelism, and a skill unto itself.
“You can’t sell developers. You can only earn their respect, and even then you only get one shot at it. And when it is gone, it is gone forever.
Ultimately, developers will use your product only if it is useful for what they are trying to build and if it is presented to them in an accurate, elegant way. The hard sell as a technique is rarely accurate or elegant.”-Rob Spectre, in his 2013 Reddit AMA
Be your company’s best advocate (literally)
At an event, you become the face of your company, and that comes with quite a bit of responsibility, but also a lot of room to be able to sweep your audience off their feet. First impressions mean a lot, so be confident, exciting, and knowledgeable.
Your company has brilliant engineers who work day in and day out to build the awesome product that you’re there to showcase. You love the product and are there to share that excitement with everyone else at the event, so show people what makes your product exciting and help them be just as excited as you are! You might even get a chance to give a demo at either a workshop or the opening ceremony (bonus points for live coding, nothing shows ‘easy onboarding’ like being able to spin up an app or show functionality in less than 3 minutes).
“When you’re there, it’s about the experience the developers have with you, often 1 on 1 or in small groups, they may be frustrated with something that they don’t know about the API, or an edge case, and you’re there to help them through that. And this comes up more often than not, there may be something that is an error on our side. We give that feedback immediately to our developers to help smooth out those edge cases immediately” — Matt Makai, Developer Evangelist Manager at Twilio in an interview with APIgee
Remember, you are your company’s best advocate. Developers always have the option of finding reviews of your product from other third party sources, so make your interactions with them meaningful and captivating, as nobody should be better at showing off your company’s product than you. Know as much as you possibly can about your product, because lesser-known features could be all a particular developer needs.
I’ve seen event sponsoring companies send everyone from marketing reps to CEOs, but the most memorable experiences I’ve had with sponsors as a hacker have been from their technical employees: 3 AM troubleshooting help, kickass live coding demos (from javascript guru Eddie Zaneski from Twilio), or memorable kind gestures (like when Andrew Mager ♫ from Postmates offered free breakfast to hackers at HackTech). Obviously, it would be wrong of me to speak on behalf of the entire developer community, but from what I’ve seen, engineers and evangelists alike are more adequately equipped to help developers, whose interactions result in more intimate and genuine interactions, ultimately translating to greater product adoption, reputation, exposure, and every sort of tangible deliverable one could desire within the context of event sponsorship.
Proactive Engagement
One of the biggest mistakes I see from companies that aren’t getting the adoption that they want out of hackathons is that their event representatives/evangelists don’t take the initiative to demonstrate or help firsthand with onboarding for the developers. Obviously, if you aren’t sending technical staff, it becomes hard to access true engagement with developers at technical events, but it’s more than just the skillset of the representatives at the event — it’s also the manner in which they engage.
It’s imperative to understand that no matter how world-changing your company’s product is, putting it in front of developers simply isn’t enough (although it is a huge part of it) — go the extra mile to truly make the introduction to the product a truly pleasant experience for the developer. If your company doesn’t have stellar ‘Getting Started’ tutorials online, it only accentuates the need for an onsite evangelist to ease the transition.
At most events, you’ll be given a table/booth to call home base. In the beginning of an event there are typically job-fair style sessions where developers make their rounds exploring the companies that are there, inquiring about what products they’ve brought to the event. This is great because it allows you to stay in one place and pitch your company’s products constantly.
“Really great technical evangelism is not about maintaining appearances, it is about helping developers succeed with measurable and documentable results.” — Rex St John, Developer Evangelist at Intel on ‘Pizza Evangelists’
Every company has products that evolve constantly, so I typically like to highlight the newest changes or exciting novel features, as most people don’t know exactly what type of project they’re interested in early on at the start of an event. Also, there’s a chance someone could have potentially seen your company at another event recently, so by highlighting new features, you’ll prevent them from glossing over your product. Try your best to spark up conversation with the developers, as something as simple as discussing the features of your product could spur project ideas that involve implementing your product.
Remember, your company paid thousands of dollars to sponsor an event, get foot presence on the ground, and maybe ship some awesome swag/promotional products, your personal aptitude and commitment to excellence should be an extension of this!
Once hacking has begun I make it a point to get as much interaction with the developers as possible. Beyond prioritizing assistance of those working with my company’s products, I tend to go around the venue and spark up conversation about peoples’ projects (in an unobtrusive fashion, of course). Most groups don’t have a concrete idea immediately, so by asking around, I am able to take part in their ideation phase. By being able to help them hash out a project idea based on what they’re interested in, I am both helping solve their problem, and giving myself a ‘day-zero’ opportunity to catalyze adoption should my company’s product be applicable in the scope of their project. While I’m there, I can help debug any bugs or issues they may have, whether it’s using my product or not. I like to think of it as speed dating meets tech consulting. Even if a particular conversation doesn’t result in product conversion, any positive interaction or assistance, at the very least, paints a positive image of your company, and can indirectly result in future product adoption by either those same people or someone they then recommend your product/company to.
Be Accessible
Remember, developer evangelists are at an event to serve developers. Any barriers that prevent interaction will limit your prospective impact. Connect on social media or offer a way for developers to easily get in touch with you throughout the course of the event. As I’m jumping around like a code monkey hiked up on black coffee, it may be hard to find me. As such, it’s often easier for hackers to ping me on Slack or Twitter, two popular communication channels typically used at events anyway.
A few benefits of direct online contact:
- Faster response time
- Can answer questions when not physically present at the venue/table (out for a meal, back at the hotel, etc. The number of times I’ve given assistance to hackers digitally at the same event or even ANOTHER event is countless).
- Prevents the hacker from needing to stop working in order to find me
- Allows me to ‘queue’ people in need of help so that they know approximately what time I’ll be able to get to them
Be Resilient and Play To Your Strengths
Now, a little about you. Contrary to popular belief, it’s perfectly normal to not have encyclopedic knowledge of every technology under the sun — it’s easy to forget that when your role is a technological educator! Developers don’t need you to impress them by solving all of their problems, focus on the ones your company’s product solves. In a world where information is only a few clicks away, it becomes easy to feel insecure when one doesn’t know an answer to a seemingly simple question. This insecurity plagues even the best of us, and contributes greatly to personal burnout in this field. I like to mentally subdivide my levels of expertise based on the following categories, as it helps me manage the potential intellectual workload at an event without spreading myself too thin:
Expert: My go-to technologies, the bread and butter, the comfort food. Any tech you’re extremely comfortable with and know inside and out belongs here. If you’re an evangelist, your company’s products should definitely fall under this category.
Experienced: Anything you’ve used in the past that you feel comfortable giving advice on should go here. Maybe a language you used to use extensively, but it’s been a while since you last used it.
Familiar: You may have never even worked directly with one of these technologies, but you have confidence that you can pull on background knowledge and a bit of elbow grease to help get a problem solved. Sometimes a fresh set of eyes is all a project needs.
(Example: Helping a hacker troubleshoot C#, but having a background in Java).
If the topic of conversation is something I’m not at least familiar with, I will try to either find a suitable mentor for the developer myself, point them in the right direction of someone who may be able to help, or will mention the situation in the mentor lounge.
Contrary to popular belief, it’s perfectly normal to not have encyclopedic knowledge of every technology under the sun.
This dichotomy may seem very formal, but it surfaces all the time at events. Interested in data analysis? I’m your man [expert]. Building your own API? I’ve done that a few times before [experienced]. Need to troubleshoot in Java? Java makes me cry, but if you’re willing to cry together, we can work through it [familiar]. Having trouble with some node.js? Definitely not my area of expertise, but I’ll help find the right person for you.
There are many problems that can be stackoverflow’ed to completion, but sitting there for hours trying to solve them when there are better alternatives isn’t ideal. Learning when to accept that there may be another tool fit better for that particular job (another mentor with that type of expertise, another product that may solve the problem in a much less convoluted way) is tantamount to not overexerting yourself. Developers’ time is valuable, so pushing for them to use a product that has blatantly easier alternatives is simply disingenuous and will do more harm than good in the long term. If I’m not immediately assisting someone myself, pairing a mentor with a struggling hacker is undoubtedly one of the most valuable things I can do at an event.
Ever Upward
Personal growth and learning are what enable a developer evangelist or mentor to become truly great in the long term. There will always be times where I will be asked questions that I won’t know the answer to, and as hard it may be, it’s a reality that I must come to terms with. As many people also say about college, the important thing in life isn’t always to have the right answers, but rather to know how to go about acquiring them. Resilience isn’t just some nebulous buzzword, it’s a critical trait that will allow one to adapt and thrive in any situation. Having realistic expectations for yourself is critical to feeling confident and preventing yourself from experiencing burnout, as many developer evangelists do.
I know a lot about the technology that I promote, and have firsthand experience using most of the features in my own personal projects. This being said, hackers’ questions never cease to push my intellectual boundaries in relation to my understanding of how our own products work under the hood.
Resilience is much more than a superfluous buzzword, it’s a crucial trait that will enable you to adapt and thrive in any situation.
There’s nothing that irks me more than having to default to a ‘that’s just the way it is’ style of answer that neither a hacker nor myself are satisfied with. To combat this, I’ve had flights where I’ve read textbooks from cover to cover about Mathematica/WolfLang to ensure that I can quickly tackle any question that is thrown my way, but I’ll never be able to know everything. Be able to admit when you don’t know something, and make the effort to learn it, whether that is in the next hour, day, or event.
“If there is one thing that I have learned in the 4 years that I’ve had the privilege of serving at Twilio, it’s that developers, regardless of skill level, regardless of where they work in the world, and regardless of the company that they work at, they’re all turned on by the same stuff. They’re all bonafide technologists that are genuinely enthusiastic about learning new things.”
— Rob Spectre, Lead Developer Evangelist at Twilio in his talk at DevRelCon
The Intangibles
Developer evangelism results in successful product adoption when you offer the full package: an enticing pitch that translates to seamless delivery by a personable and knowledgeable onsite technical evangelist who can enable developers to easily integrate the product into their own pipelines. All of those bolded terms are extremely subjective, and by definition, are hard to define with hard and fast rules.
So, what exactly makes an evangelist great? Evangelists don’t become memorable because their companies are doing well financially, they become memorable because of the personal interactions they have with developers. They don’t become memorable just for working at a well known company, they become memorable for the problems they’ve helped a developer solve at 2am during crunch time. They become memorable for the kickass live coding they do that get people from never having heard of your product, to the edge of their seat dying to use it. They’re solvers of a complex, amorphous puzzle that assumes a new form at every event they’ll appear, but if there’s one thing that remains constant, it’s that as an evangelist, they’re much, much more than the sum of their individual parts. The impact they can have extends far beyond any sort of immediate metric you could seek to record, another fatal flaw many companies exhibit when evaluating the efficacy of devangelism. Being an evangelist is finding a way to pair the human aspect with the 0’s and 1’s that define our field, and procuring tangible results - be it a qualitative experience or quantifiable metric.
“The real value (of developer evangelism) is in the long term relationships.” Mike Swift, CEO & Co-Founder of Major League Hacking
Ultimately, there is no substitute for spending time with the developers utilizing your product. Getting out there and helping them troubleshoot will help you learn more about what they’re struggling with, and only then will you be able to figure out how to better serve them, as well as reflect internally in order to improve your company’s product and your own personal methods.
Yoda said it best, “Do, or do not. There is no try”. So get out there and ‘do’, I can’t wait to see what we can build together.
*All VaultBoy images copyright of Bethesda Softworks, modified from their original forms.
Hey, I’m Nick Walsh. I’m a Technical Evangelist for Wolfram Research as well as a Hackathon Coach for Major League Hacking, with a passion for technology, eSports, and empowering developers & hackers. Data analysis and APIs excite me greatly.
