DEV Community

Julien Simon
Julien Simon

Posted on • Originally published at julsimon.Medium on

Technical Evangelism From The Trenches

I don’t look in the rear view mirror much. However, I recently spoke with a young graduate curious about tech evangelism. Halfway through the call, I realized that I actually had a few things to say about that, and I decided to put them down on (virtual) paper. So here goes.


Image: Frederic Duriez / BDIC / media

It’s the product, stupid

You should obsess about bringing value to your audience. It’s the respectful thing to do, you should never waste anyone’s time. It’s also the best way to engage in meaningful conversations with potential customers.

It’s simple, really. Customers face technical and business challenges. They want to know if your products can help. Your role is not to convince them at any cost. You don’t know all the ins and outs of their challenges, you’ll miss the target, and you’ll sound arrogant or desperate. Your role is to give customers the information they need to make the right call.

This requires knowing your products inside out. The product , not the code. No customer cares about your code. Here are a few things they care about:

  • Real-life use cases specific to their industry, that show how to solve problems and create business value with your product,
  • How easy it is to add your product to their existing workflows,
  • How easy it is for users to adopt your product,
  • How good your documentation and your technical support are.

Know your products like the back of your hand. Figure out how customers can use them in their context to solve real-life problems. Boring them with a generic laundry list of features is a recipe for failure.

User experience and business value über alles.

Be customer #1

Are you using your own product every day? When is the last time you found a mistake in the documentation? Or filed a bug report? Or suggested a new feature?

I often define my job as “I spend hundreds of hours on the product so that customers don’t have to.” When trying a freshly-baked feature, I’m happy to bang my head on the wall for as long as it takes. Once I’ve understood how the damn thing works (or not), I can document it and save hundreds, maybe thousands, of customers the same trouble. In fact, there’s no better way to spend my time. For me, clearing the way is an immense satisfaction.

Your company will understandably get excited about new launches. Lots of work and late nights. Everybody wants to celebrate, and move on the next project. Fair enough. Someone needs to keep an eye out for feature gaps, incomplete documentation, and buggy code samples. That’s me. The “grumpy” person that complains about “tiny details”. There are no tiny details when it comes to UX and DX. Every flaw is an adoption killer, and I’m trying not to let anything slip through the cracks.

Eat your own dog food, don’t drink the Kool Aid.

Talk to customers

It’s tempting for a tech evangelist to live exclusively in the fantasy land of keynotes, conferences and social media. “It’s not my role to attend sales meetings.” Really? Tell me then, my dear tech hipster, how the hell will you know what problems customers have in real life, from developers to projects managers to business users?

You need first-hand experience on the complex environment customers live in (business, technical, regulatory, etc.). You need to hear their questions and feedback with your own ears. It’s the only way to fully understand how you can help them. Personas have merit, but they’re only as good as the reality they’re grounded in. Meetups, conferences… sample bias, anyone?

If you’re not in the trenches on a regular basis, you’re either senselessly yapping around on the “conference circuit”, or you’re a tech pawn that your company uses to “talk to developers, not at them”. Take the red pill!

Customer calls are the single source of truth.

Always side with the customer

A tech evangelist should not have skin in the sales game. I never had a sales incentive and never wanted one. Sales teams want to close the deal, hit their quota, and get paid. That’s perfectly fine, and I never had any problem with that. Hungry sales teams keep companies running.

Engineering teams want to push the new release out there, and move on to whatever cool thing they’re going to build next. Been there, done that. Perfectly fine too.

Me? I’m siding with the customer, because no one else will. After all, I’m customer #1. See how this starts to make sense? Sometimes this means arguing with internal teams and with management to make sure that customer feedback and concerns are addressed. You need to be comfortable with that. So should your company. If not, you’re in the wrong company. Some you’ll win, some you’ll lose (and should lose). At least, you gave customers your best shot at being heard.

During customer discussions, you should always be completely honest about your product. If it’s not the right fit for the customer, tell them. This will require some alignment with the sales team prior to the discussion. If you can’t come to an agreement with them, don’t join the discussion and let them bury themselves.

Your word is your credibility. Deceive a customer and they’ll never talk to you again. Tell it like it is and they’ll remember you in 10 years. Chances are they’ll ping you down the road for future opportunities.

You’re the voice of the customer. Let it be heard loud and clear.

Never discuss the competition

You shouldn’t mention competing products in your content or with customers. In large companies, Legal will tell you that’s because blah blah blah blah blah (sorry, I wasn’t listening). My reasons are much more pragmatic:

  • You’ll never know competing products as well as your own. Anything you say is likely to be vague, incorrect or outdated. Customers will notice that when they talk to the other party, and you’ll sound like an idiot.
  • Why would you even bring your competition to the customer’s attention? They may not be aware of them. Any company that you mention will immediately pique their curiosity.
  • More than anything, you should use 100% of your time listening to customers and figuring out how your product may help them.

Every time a customer asks me how our product compares with XYZ, I always tell them that:

  • I don’t know XYZ because 100% of my time is spent improving our own products.
  • I recommend that they run their own PoC or benchmark, instead of listening to sales pitches.
  • I’d love to hear their feedback on how to improve our products.

No one ever complained.

Focus on building great products that customers love. Let the competition worry about you.

Show, don’t tell

To be successful at technical evangelism, you need to find the right mix of story telling and product demos. Too much of the former, and you’re not giving the customer actionable advice. Too much of the latter, and you’re narrowing the scope of your presentation to “have this problem? here’s the solution.”

I always include at least one demo in every talk and conversation. Customers need to see the product in action, get a sense of the UX, and start thinking about how they could use it. Demos are the best ways to trigger questions and initiate a rich conversation. If you’re not demoing, you’re doing it wrong.

Demos are a moving target that need to be adjusted to the audience. A technical audience expects code and notebooks. Business managers and C-level? Not so much, and instead I show them real-life scenarios that they can relate to: querying financial documents, analyzing sentiment on customer phone calls, etc.

I cannot insist enough on how important it is to build your own content (slides and code). Canned content is flawed in many ways:

  1. You won’t be intimately familiar with it, and it won’t flow naturally. That intimacy can only come from hundreds of hours of work, whether you’re writing code, drafting blog posts, and designing a new slide deck.
  2. Canned content is often too generic, especially if it’s been designed by people who generally have no real-life experience with the product and who don’t talk to customers (you know who you are).
  3. Delivering fresh content increases your on-stage focus (thank you, adrenaline), and you’ll come across as a more engaging speaker

Your talks, your slides, your demos.

Walk the Earth

You can’t call yourself an evangelist and not go meet people where they are. Yes, yes, COVID blah blah blah. I went from 100+ flights a year to zero. That was nice for a while, but now I’m getting restless, and so should you. The world is coming back to some level of normality (for meetups and tech conferences, at least), so let’s enjoy it again. Who knows how long that will last?

Many times at AWS, I would fly to a place where people told me: “You’re the first AWS guy I meet”. This never failed to put a big smile on my face, because I knew I was doing my job right. You don’t need to go very far! There are plenty of events outside of the large tech hubs. Go and explore. I’m sure you’ll get a warm welcome, and people will remember that you traveled to meet them. I’m regularly pinged along the lines of “Hi, we spoke after your talk in XYZ a few years ago, and I’ve got a project that you could help with.” You’ll never achieve the same stickiness with online interaction.

Get off your ass and meet people IRL. It pays off.

Embrace the suck

Technical evangelism is an uncomfortable job by design. Ambiguity is the rule. Sales, marketing and engineering have their own goals, often contradictory. You’ll have to fight every step of the way to earn respect and make yourself heard.

Each customer meeting is a new puzzle you have to solve. Each public talk is an opportunity to fuck up in front on hundreds of people.

There’s always way too much going on at the same time. Blog posts, videos, customer meetings, events. The pressure to keep up with new features and to build fresh content. Deadlines. Deadlines. Deadlines.

Traveling is exciting, but it can quickly become grueling. Trains, flights, taxis, hotels, jet lag. Life on the road minus the backstage antics. Writing code at the airport. Losing your laptop adapters. Attending late-night conference calls because of different time zones. Dealing with family issues when you’re 10,000 km away.

This job is not for everyone. I’ve seen bright young folks crumble and quit after a couple of years. Most of them went back to “normal” tech jobs where they’re part of a proper team. I’m happy for them.

7 years and counting. Maybe I’m a tough old bastard. Or maybe I just love a good fight. Forward, march.

Top comments (1)

Collapse
 
glowreeyah profile image
Gloria Asuquo

This is going to quite helpful to me in my Developer Advocacy journey.
Thank you