Developer Trust Isn't a Brand Metric: Lessons from Our Conversation with Brian Whippo
- Catchy
- Feb 25
- 5 min read
Brian Whippo is the Director of Developer Relations at the Algorand Foundation. We had him on episode eight of Bits and Bants, and the conversation opened up a few threads worth pulling on. Below are the ones that stuck with us.
Developer relations sits at an interesting intersection: part marketing, part engineering, part community building, part organizational change management. It's a discipline that's hard to reduce to a job description, which is part of what makes talking to practitioners so useful.
Brian came to DevRel from an unlikely direction, fifteen years at Morgan Stanley followed by nights-and-weekends tinkering in the Algorand ecosystem, and that background gives him a perspective on developer trust and adoption that doesn't sound like the standard conference talk. A few things he said are worth a closer look.
Developers don't take credibility on faith
Most marketing functions operate on some version of the same playbook: build awareness, establish credibility, create preference. It works reasonably well for most audiences. With developers, the dynamic is different in a way that's worth taking seriously.
Developers stress-test credibility. They'll read the docs, run the code, and form an opinion before your messaging ever lands. By the time a developer decides whether to trust your technology, the marketing has almost nothing to do with it.
When we asked Brian what makes inspiring developers different from traditional technical leadership, his answer wasn't about channels or messaging frameworks. It was about authenticity as a non-negotiable baseline. Developers, he said, have a keen eye for fluff, and the moment they detect it, you've lost them.
What stays with us from that exchange is the structural nature of the problem. Developer trust gets built through documentation quality, technical accuracy, and community responsiveness. Content strategy and brand voice matter, but they're downstream of those fundamentals. Get the fundamentals wrong and the marketing makes things worse, not better.
Education is necessary but it's not the whole job
There's a widely held belief in developer marketing that the path to adoption runs through education: enough tutorials, enough docs, enough workshops, and developers will get there. It's not wrong. But Brian's framing of the job made us think it's incomplete.
He broke down the core functions of DevRel into four areas: teaching, onboarding, empowering, and inspiring. When we asked which is hardest, he didn't hesitate: inspiring.
Teaching has established frameworks. Onboarding is largely a process problem. Inspiration is something else, and there's no clear playbook for it.
What his team has landed on is a principle he calls "let them play." The job isn't just to teach developers how the tools work. It's to get them competent enough to experiment, and then get out of the way. Once someone has genuine curiosity and the baseline skills to act on it, the goal is to remove friction rather than add more instruction.
For developer content strategy, that's a useful reframe. If your content tops out at education, you may be stopping exactly where the interesting part begins. The content that tends to move developers is content that makes them curious, not just content that makes them informed. Those are different briefs, and it's worth asking whether you're writing both.
Individual developer enthusiasm and organizational adoption are two different problems
This gap comes up a lot in developer go-to-market conversations, but Brian described it with more precision than most.
Individual developer enthusiasm, he explained, is necessary but not sufficient. Getting a technology chosen and relied upon inside a large organization requires navigating org structures, identifying real decision-makers, and moving something from proof-of-concept to a long-term organizational commitment. That's a different set of conversations than the ones DevRel typically has.
Brian came to Algorand from 15 years at Morgan Stanley, where a big part of his work was navigating a large institution to drive change across competing stakeholders. He argued that kind of organizational fluency is one of the more undervalued skills in developer relations, a field that tends to reward technical depth but doesn't always talk about what it takes to get a technology actually adopted at scale inside an enterprise.
It's a tension worth sitting with for any team supporting an enterprise sales motion. Developer excitement is a signal. The conversion happens in a different set of conversations, ones that look less like DevRel and more like change management. Understanding both sides matters.
Your documentation now has two different audiences
Something we talk about with clients a lot is that documentation strategy has quietly become a distribution strategy. As AI-assisted coding becomes a default workflow, how well your technology is represented in training data and context windows directly affects the quality of AI outcomes developers get when working with your platform. LLMs read the manual too.
Brian's experience at Algorand is a good illustration of what this looks like in practice. When they launched a major toolkit update in March, the frontier models from Anthropic and OpenAI had training cutoffs from January. Their new technology simply didn't exist in the model's knowledge. They spent the following six months building tooling and prompting guides specifically to help developers bridge that gap.
It's a concrete example of why documentation structure, content density, and AI discoverability deserve a seat at the table alongside the more traditional content strategy conversation. Hearing Brian articulate it from the DevRel side reinforced for us that this is becoming a shared problem across the ecosystem, not just a marketing one.
The real work of DevRel happens between the conferences
There's a persistent image of Developer Relations as a conference circuit, heavy on events, travel, and networking. Brian was pretty direct about the gap between that perception and what the work actually looks like.
The highest-energy moments on his team, he told us, aren't at the after-party. They're when someone finds a compelling new use case and gets excited to prototype it. The actual work, the internal debates about how to teach something arcane, the dogfooding, the slow process of understanding what developers actually need, happens far from any conference floor.
It's a useful frame for thinking about what a DevRel function should actually look like, and how to evaluate whether it's working. The outcomes that matter are developers who understand your technology well enough to build on it and advocate for it. Getting there requires a different kind of investment than event presence alone.
Watch the full conversation
There's more in the episode than we covered here. Brian's path from derivatives trading at Morgan Stanley to nights-and-weekends open source contributor to Director of DevRel at a blockchain foundation is genuinely worth hearing in his own words. He also goes deeper on Algorand's developer experience philosophy, what it took to ship a TypeScript-native smart contract framework, and his take on where AI-assisted coding is and isn't headed.
