Developers Don't Trust Logos. They Trust People.

Developer relations has a built-in tension that nobody escapes. You represent a company, but developers don't trust companies. They trust people. The moment you sound like the company instead of like yourself, you've lost the only thing that made you useful.

So the question every DevRel person eventually has to answer is: how do I bring my authentic self to this job without getting crushed between the marketing department and my own conscience?

After speaking in more than 30 countries and delivering a few hundred sessions, here's what I've learned. Not as theory, but as the things that actually held up.

Authenticity is not a personality type

Let's clear one thing up first. Bringing your authentic self does not mean being loud, funny, or extremely online. Some of the most trusted people in DevRel are quiet, precise, and boring on social media. Authenticity is not a vibe. It's consistency between what you say, what you know, and what you'd say if your employer wasn't watching.

I'm Dutch, which comes with a reputation for directness. For a long time I wondered if I should sand that down for international audiences. I stopped wondering when I noticed the pattern: the sessions where I was most direct, including about what a product couldn't do, were the ones where people came up afterwards. Nobody ever queued up to thank me for a polished pitch.

Your accent, your background, your bluntness or your carefulness: these are not bugs to fix before going on stage. They're the reason people remember it was you.

Build the thing before you demo the thing

This is the least glamorous rule and the most important one. Developers can tell within minutes whether you actually built what you're showing or you're clicking through someone else's demo. The first earns you an hour of attention. The second earns you polite nods and an empty Q&A.

Which means: drop the fake company stories. Every company has them, the fictional retailer with the suspiciously perfect dataset, solving a problem nobody in the room has ever had. And drop the role-playing game that comes with them. "In this scenario, I'm a data scientist at company X." No you're not. Everyone in the room knows you're not, and now the whole demo is theater. You don't need a costume to show technology. Instead, build your own examples. Useful things, with the tech you want to show, solving problems you actually have. Automate something in your own workflow, build the tool you wished existed, solve a real problem from your own community or side project. When the example is yours, every question from the audience lands on something you genuinely understand, because you made every decision in it.

Authenticity in DevRel starts as a technical practice, not a communication style. Write the code. Hit the error messages. Deploy the thing and watch it break. Then get on stage and show the version that includes the broken parts. "This took me three attempts and here's where it failed" is worth more than any slide with a checkmark on it.

You cannot fake having done the work. And you shouldn't want to, because the struggle is the content. The polished happy path is in the documentation already. What people came for is the part the documentation doesn't tell them.

And let's be honest: I've been framing this as a rule, but building my own demos is the most fun part of the job. You get paid to play with new technology and turn it into something that works. If that part feels like a chore to you, the problem isn't the rule.

Say the things a spokesperson can't

Trust in this job is built from three sentences—and one right underpinning them all—and every part of it is hard to say when you have a logo on your slide:

"I don't know." Followed by actually finding out and following up. Nothing kills credibility faster than improvising an answer to sound complete.

"This product is not the right fit for that." Recommending against your own product, when it's true, is the single fastest trust-builder that exists. It costs you one deal-shaped conversation and buys you an audience that believes everything else you say.

"That other tool does this better." Developers already know the alternatives. Pretending they don't exist just tells the room you think they're stupid, or that you're not allowed to be honest. Both are fatal.

And the right underneath all three: you're allowed to have an opinion. Any company with a portfolio the size of my employer's has great products and products that are just not that good, and everyone using them knows which is which. You don't have to trash anything on stage. But when someone asks what you actually think, having an answer that matches reality is what separates a trusted advisor from a walking press release. The company hired your judgment. Use it.

Notice how this stacks with the earlier sections. The consistency is the goal. The building is how you earn the credibility to speak. The room to speak honestly is what makes it survivable. If your employer doesn't give you that room, you don't have a DevRel job. You have a marketing job with a developer costume on.

Be a person, not a channel

You're allowed to have a life, and it's allowed to show. I talk about travel, food, and the mistakes I make along the way, like forgetting to pack a jacket on a trip to Stockholm, and then building an agent to make sure it never happens again. Not as a calculated relatability tactic, but because that's who's standing there, and pretending to be a purely professional entity is exhausting and unconvincing. And notice what that example is: a real problem from my own life, solved with the tech I was there to show. The personal story and the demo are the same thing.

But authentic doesn't mean unfiltered. There's a difference between being a person and turning your life into content. My family is not a growth channel. My opinions on every news cycle are not required. Authenticity includes the authentic choice to keep parts of yourself offline. The goal is that the person on stage and the person at dinner are recognizably the same, not that there's no difference between the stage and the dinner table.

Two hats, worn honestly

I work at Microsoft and I run a vendor-neutral community. People ask how those combine. The answer is: openly. I name which hat I'm wearing, every time. On a Microsoft stage, I'm there to show you what Azure can do, and I'll tell you exactly that. At a community event, the stage is neutral and my employer buys no special treatment, and I'll tell you that too.

Having two roles isn't inauthentic. Hiding which one is speaking is. Developers handle disclosed interests just fine. What they punish, permanently, is discovering an undisclosed one.

The long game

Here's why all of this matters beyond feeling good about yourself. DevRel is a repeat game. The developer in the audience today shows up at your next event, reads your next post, and evaluates your next product. Every shortcut you take with the truth is a debt that comes due in front of a future audience.

Your authentic self is not a branding exercise. It's the only asset in this job that compounds. Products get renamed, platforms get deprecated, employers change. The track record of having been straight with people is the thing you carry with you.

So bring it. Accent, bluntness, failed demos, forgotten jackets, and all.