Technology Evangelist

Developer evangelism is one of those professions that defies easy explanation. It’s sort of marketing, but it’s not quite that. It’s developer relations, but not exclusively that. It’s selling, but with an app on GitHub. At this point, the lines between the above have become so blurred that even those practicing it don’t always agree on what they do. Consider: There are folks at Microsoft or Google (other vendors are available) who are contributing code samples and repositories to open source one day and presenting to developers about that company’s cloud platform or API the next. (Spoiler: It probably isn’t actually the future but they’re gonna convince you it is.) The point is, if it’s any consolation, there is no one-size-fits-all description for the practice of tech evangelism these days. You have the corporate evangelists, those big-name tech company reps who flit from conference stage to conference stage proselytizing to developers on how to adopt a specific technology or product. Then you have the scrappy indie evangelists who can’t be bothered to even call themselves that, but are instead the solo rep for an otherwise unknown startup peddling a…well, let’s be honest here, evangelism is the only thing giving most of these startups that little extra cache, and without evangelism, what they have to say usually doesn’t matter much in the grand scheme of tech. They are at every tech meetup doing demos on their laptop, which is always stickered to within an inch of its life.

I won’t beat around the bush on this one, it takes a particular kind of person to excel at this. Developer evangelism is objectively a ridiculous job in terms of skillset requirements. Coding-wise, you’ve got to be good enough that developers are not immediately dismissive when you share code with them, but not so good that you end up in engineering and never speak to another human. (I like to think I’m good at both though, what can I say? Dual threat.) Speaking is an obvious prerequisite. Presenting, after all, is a key part of the job. Workshops, podcasts, tweets half the time, when a JavaScript framework you use every day drops a breaking release at 2am. Writing, too, is key, because much of evangelism is written, in blog posts, documentation, GitHub READMEs that are…readable? Wow that’s rare when I think about it. Oh, and you better have the gift of the gab on top of all of that, or your community just won’t vibe with you. It’s a difficult thing to explain. Some days when I see the line-up for the next tech conference, I just shake my head at what people have to put up with to be great at this job.

The pay ranges drastically as well which makes the whole profession even more peculiar. From what I’ve observed talking to people in the industry, the big tech evangelists can be making well into six figures, upwards of $200K+, with stock options, trip reimbursements, the works. Sure, you’re flying business class to give your talk in Singapore for one vendor one week, then on to Berlin the next for another gig. And the developer advocates? The developer advocates at young startups are lucky if they have $80K, and have to pay for their own conference passes while hoping someone on the floor will care about their pitch. In terms of title inflation, that’s what really chaps me. Developer Evangelist? Developer Advocate? Developer Relations Engineer? Technical Evangelist? Community Engineer? Every company has a different name for their people doing these kinds of roles and it becomes this ongoing conversation (or argument, more like) in the developer community over whether these different job titles have different meanings or whether it’s just corporate speak BS.

Truth is, this is what an actual day (for the most part, but I’ve spoken to dozens and they’re all similar) looks like: Mornings tend to be writing of some sort—docs, blogs, sample code, Twitter threads. Afternoons are sometimes internal meetings where you’re either arguing with product teams to get a bug fixed that will be embarrassing if you can’t demonstrate the feature at that conference event next week, or convincing product teams that yes, this feature that everyone’s asking for is important. (Internal arguments are very, very common for this job, FYI.) Evenings is when you “engage the community,” because developers are night owls, and they will be most active on Discord or Slack or whatever platform your community is hanging out on, then it’s evenings. Weekends? Blurred into work all the time, because there’s a hackathon or conference or something. This is why the burnout rate is through the roof.

Authenticity is one of those perennial questions with this work. You are an employee of Company X, on the payroll to evangelize their products. Everyone knows that. But at the same time, you are supposed to be a trusted voice within the community to developers. Give it to them straight. Be “real” with them. When you work at some multi-national Fortune 500 with public stock, how does that work? The good evangelists navigate that tightrope by being actually critical when the moment demands it, even about the tech and products of their own company. They’ll tweet “yeah the new API version is rough in places, here’s the workaround I’m using,” not hawking their employer’s wares without a whiff of a critique. The bad evangelists are the literal walking billboards. You can smell their breath from across the conference hall.

Junior devs are getting maybe too reliant on these tools, I think. I think if you never learned how to actually read documentation or grok the fundamentals because you just ask AI for all the answers… that’s going to come back to bite you later. These tools are supposed to augment your skillset, not replace learning the basics. I mean, senior devs use the tools heavily too so this isn’t meant as an attack on juniors, but seniors can usually tell when the AI is spewing garbage or taking an objectively bad approach because they have the years of experience to recognize. Juniors will often blindly accept… or not recognize they’re being blindsided. Which is not good.

How one measures actual “impact” is so damn fuzzy. How do you know you’re doing a good job? Downloads of an SDK? Numbers of attendees at an event? Stars on GitHub repos? Tweets? Developer engagement in communities? Companies can track that sort of thing but it’s a herculean task to cleanly correlate “that evangelist did an excellent talk at that conference” and “signed up those three enterprise accounts.” It’s a tension that is never far below the surface. Management wants metrics, they want return on investment. They want numbers and email blasts and slides saved and webinars uploaded to YouTube. The evangelists are out there spinning their wheels, trying to cultivate relationships and build community. There’s value in both and it’s frustrating for everybody.

There’s the open source side of things, because much of the best evangelism often happens in those communities where developers contribute because it’s their passion project and they aren’t expecting a return on investment the next quarter. Answering questions on Stack Overflow at midnight? It’s not because your quarterly targets demand it, but because that’s how you build trust and rapport. Fixing bugs in another project’s docs? Not for that quarter’s numbers, but for the overall ecosystem’s good. Developer evangelism can’t shake that friction between community cultivation and that drive for short-term company gains. Every company does it a little differently and the companies that do this well handle it differently as well, obviously. Some that just…

As for the future, I think it’s pretty clear that we are not going back to a world where NOT using AI coding tools is even a thing. It’s just like using Stack Overflow is these days. The tools will only get better at context and start to avoid common pitfalls and eventually maybe they will actually be good at architecture level decisions and not just code generation. But we’re not there yet and tbh I’m not sure we want to be? There’s something very human about the skill of software development that I’m not sure we should be able to fully automate. But it is what it is for now. AI coding assistants are just another tool in the developer’s toolkit. Powerful. Useful. Frustrating at times. Not going anywhere.