What’s the difference between a technical evangelist and an advocate? What are these terms even? If you’re a technical recruiter, I encourage you to know the answer to all of these questions by reading this piece for the next 4mins.
What is a “Technical Evangelist”?
A way to simplify the definition of an evangelist is to onboard people to their particular topic, do whatever it takes (hackathons, sponsorships, contribution, enablement sessions, flights…lots and lots of flights…blogging, interviews, code samples, research, t-shirt design, customer support, server setup). They wear all the hats, usually at the same time.
What is an “Advocate”?
An advocate defines their job based on the success of the customer (or anyone really) at the job they most need to do. Deep listening, directed dialog, metrics extraction, change impact quantification, being kind, and work framing are all tools in an advocate’s toolbelt. It’s caring about the other person first, then of course yourself secondly.
Advocacy vs. Evangelism
Advocates are good facilitators. Unlike evangelists, they don’t assume that because a hat needs a wearer, that it must be them to wear it. They see the whole field, not just the ball in-front of them. Advocates identify what needs to be done cross-functionally and help to match people who want to and can do a thing to get that done. They think about the problem that people are trying to solve, and put resources into motion to reach that goal.
Naturally, when I frame advocacy this way, it’s easy to see why evangelism leads to burnout. Advocacy leads to faster burndown (e.g. sprint burndown charts) because facilitation, a scalability reinforcer, is at the core of advocacy. What problem are you trying to solve? What’s required to get there? What challenges will arise? How can we most effectively help each other?
How to Qualify Who Should Apply For Which Role?
If someone demonstrates that they can differentiate between facilitating needs over taking on things as a personal responsibility to accomplish, you may just have the potential for an advocate. If a candidate lists off all the things they do without a clear definition of why first, you’re better off funneling them into an evangelist role so they can either learn a better balance or burn out and find something else.
Advocates build plans and often play a significant role in driving those plans to completion. Internal, external, independent, or consultative. When they do take ownership over a goal, you know that it will get closed, even if it wasn’t achieved to expectation, it will get closed and retro’d.
In Practice, I Say “Advocacy over Evangelism”
Evangelists talk about their product and rarely take full responsibility for anything. They are often driven by others to do things, go places, speak under sponsored time, build samples, and be engaged with customers. It’s right in the job title. “Evangelism” in Latin can be translated as “messenger”. In other words, they have been told to deliver a message. Usually the messenger has nothing to do with the crafting process of the message, and would you want someone whose job is to talk rather than listen involved in what your message to people should say? I wouldn’t.
Put another way, an evangelist mindset attempts to frame the problems of the world into terms that their product can solve. Their focus is the product that they’re incentivized to proliferate. If it doesn’t quite fit a customer’s situation, too bad, we’ll make it fit. I don’t know the job you’re trying to accomplish because I didn’t bother to ask, but I’m going to offer you a random solution anyway. And naturally, introducing a wrong-fit solution produces negative consequences (like lost time, lost money, and lost opportunity).
An advocacy mindset exfoliates information required to make decisions about how to best accomplish a customer’s true goal. Your product is not your software. Your product is a right-fit of people, process, and technology for a customer to successfully accomplish their goal. Your overlap to their situation in strictly wheelhouse terms might only by 10% or just one specific job. But if you can understand how important (or not) what you do is to completing the job they have at hand, then you can quickly fit what you offer to their needs.
This is the heart of the way product teams should “go to market”. They proceed as explorers and caretakers, not “disruptors” simply because it sounds cool. In this world, caring about how to help someone with their job better every day is disruptive. It’s honestly disruptive, to sales, to marketing, to product management, and to vision holders in technology.