The Overnight Evangelist

There’s a specific character who shows up in every engineering organization at some point. Yesterday they were a solid contributor. Today they’ve found the thing. They got it working over the weekend, they have a demo, and they’re ready to explain why the entire team should be using it immediately.

The overnight evangelist.

The easy read is that this is a problem to be managed. The tool probably isn’t right, the adoption pressure is premature, and the enthusiasm will burn out in six weeks when the next shiny thing appears. Dismiss, deflect, move on.

That read misses something important. The evangelist is usually responding to a real signal. And the org’s reflexive dismissal loses both the tool and the signal, which means the underlying problem stays unsolved and nobody learns anything useful.

---

The Signal Under the Enthusiasm

Engineering organizations that produce overnight evangelists are usually missing something. Not always the specific thing the evangelist found, but something. A deployment process that’s too painful. An observability gap that surfaces as firefighting. A reliability problem that’s been normalized into the background. A category of work that takes three times longer than it should because nobody has solved it at the platform level.

The evangelist felt that gap. They went looking. They found something that addressed it, or appeared to, and they got it working. Getting something working that nobody else has gotten working is not nothing. It requires initiative, curiosity, and enough technical depth to make something unfamiliar function. These are not the qualities of the dullest person in the room.

The signal is: this person identified a real problem and had the motivation to go solve it. That’s worth taking seriously independent of whether the specific solution they found is the right one.

Worth noting: the overnight project usually wasn’t the first attempt. Most evangelists tried the right way first. They filed the ticket. They made the case in sprint planning. They watched it get deprioritized three quarters in a row. The weekend project wasn’t impatience. It was the only remaining avenue. They went around the process because the process didn’t work for them.

Sometimes the deprioritization was correct. The problem is real but lower priority than other things competing for the same engineering time, and the system worked as intended. But often the problem stayed in the backlog not because it didn’t matter but because nobody translated it into language that let it compete for prioritization. The engineer felt the pain acutely. The cost was invisible to everyone else. The ticket said “improve deployment process” and got ranked below eight other tickets that had clearer business cases attached.

That’s a failure of articulation, not priority. And it’s worth distinguishing between the two before concluding the problem doesn’t warrant attention.

The mistake is conflating the signal with the solution. Taking the signal seriously means investigating the underlying problem. It doesn’t mean adopting the tool.

---

The Leap

The gap between “I got this working” and “everyone must use this everywhere” is where the evangelist goes wrong.

The leap happens for a few reasons, not all of them obvious.

The tool solved their problem. When something solves your problem, it’s natural to assume it solves the same problem for everyone. Especially when you’ve been living with the problem and you know how real it is. The myopia isn’t malicious. It’s the genuine belief that the thing that helped you will help the team.

Partial adoption feels like failure. If the evangelist gets the tool running, makes the case, and only one other person uses it, that reads as rejection. The credibility they’ve invested in the tool is tied to the adoption outcome. Universal adoption validates the effort and the judgment. Limited adoption feels like being wrong in public.

The unfalsifiability creep. Once the evangelist has internalized the tool deeply enough to get it working, skepticism starts to feel like ignorance. “You’re having trouble with it because you’re not doing it right” is the tell. Every limitation becomes a configuration problem. Every objection becomes evidence that the skeptic doesn’t understand it yet. The tool stops being a candidate and becomes a conviction.

This is where the conspiracy theorist who found religion shows up. The unfalsifiability of the conspiracy theory combined with the fervor of the convert. Counterevidence gets absorbed. Skeptics get dismissed. The map becomes the territory.

---

The First Mover Penalty

There’s a real cost to being the person who goes out on a limb for something that doesn’t get adopted.

Most organizations, explicitly or implicitly, penalize failed advocacy. The engineer who pushed hard for a tool that got rejected or adopted and later abandoned carries that. The next time they bring something forward, the credibility tax is higher. The skepticism arrives faster. The evaluation is less generous.

This penalty shapes evangelist behavior in ways that aren’t always obvious. The push for universal adoption isn’t just enthusiasm . It’s risk management. If the tool gets adopted broadly and succeeds, the first mover gets credit. If it gets adopted narrowly and fails quietly, the failure is diffuse. If it doesn’t get adopted at all, the effort was wasted and the judgment was wrong in front of everyone.

So the evangelist pushes for all-or-nothing adoption not just because they believe in the tool but because partial adoption is the worst outcome for them personally. The org’s interests and the evangelist’s interests diverge right at the moment when a more measured evaluation would serve everyone better.

---

When They’re Right

Sometimes the stars align.

The engineer who got Kubernetes running in 2016 when the org was struggling with deployment consistency and environment parity, they were right. The tool matched the pattern matched the problem. The timing was good. The org was ready. The first mover penalty paid off in credibility that compounded over years.

The overnight evangelist who is right shares the same characteristics as the one who is wrong: real motivation, real technical effort, enthusiasm that outpaces the formal evaluation. The difference isn’t the person. It’s whether the tool actually matched the pattern that addressed the actual problem.

Which is why dismissing the evangelist is the wrong response. You lose the signal, you lose the person’s initiative, and you lose the non-zero chance that they found something useful. The org that reflexively dismisses first movers eventually stops producing them. The engineers who have the curiosity and initiative to go find new things learn that it’s not worth the personal cost.

---

The Right Response

The right response to an overnight evangelist is neither uncritical adoption nor dismissal. It’s structured engagement with the signal they’ve identified.

What problem were you trying to solve? Not “what does this tool do” but “what were you experiencing that sent you looking.” This question separates the signal from the solution and gives the org something to evaluate independently of the tool.

Is that problem real and shared? Does the rest of the team experience what the evangelist experienced? If the problem is real and shared, the signal is valid and the org has an obligation to address it, with or without the specific tool the evangelist found.

Does this tool implement the right pattern for this problem? This is the evaluation that usually doesn’t happen. The tool gets evaluated on demo quality and the enthusiasm of its advocate rather than on whether it implements the right pattern for the specific problem in the specific context.

What’s the adoption scope that makes sense? Universal adoption is almost never the right answer for a tool that’s been running for a weekend. A bounded pilot, a specific use case, a defined evaluation period. These are how tools get evaluated without betting the org on the outcome or penalizing the first mover for a measured recommendation.

The org that gets this right takes the signal seriously, evaluates the solution adopts what fits, declines what doesn’t, and credits the person who found it regardless of the outcome. That’s the environment that keeps producing first movers. The alternative produces engineers who stop looking.