Developer Platform DevRel: Listen. Build. Learn. Make Developers Badass
Don’t build for developers. Build and Grow with them.
With huge thanks to Lucy Tesco for all her contributions to this article!
Just build it, and they won’t come.
Most internal developer platforms fail not because they lack features, but because they lack ears. They confuse enablement with instruction, automation with empathy.
When developers whisper, “It’s just another ticket system,” it’s not cynicism — it’s grief. They wanted a partner and got a bureaucracy. They wanted flow and got friction dressed as safety.
To build a platform people love inside a company, you must build a relationship, not a release train. That’s where internal Developer Relations (DevRel) comes in — not as a PR arm, but as an engine of empathy and evolution.
The mission isn’t to increase “adoption.” It’s to help developers become badass — confident, competent, and proud of what they ship.
Kathy Sierra said it best: people don’t fall in love with your product; they fall in love with their own progress through it.
So stop marketing your platform. Start coaching your developers. To do that, you need three interlocking disciplines:
User Needs Mapping — the cartography of empathy.
You learn what developers are trying to do, how they feel when they fail, and what “flow” means to them. You map pain before you pave it. You learn to hear the difference between “I need more automation” and “I need to stop feeling stupid at 4 p.m. on a Friday deployment.”
Badass Design — the psychology of mastery.
You shorten the “suck phase” between beginner frustration and confident flow.
You reward progress, not compliance. You make the golden paths shine not because they’re mandated, but because they feel like cheating in the best possible way.
Listen → Build → Learn — the rhythm of resilience.
You don’t ship and shout. You sense and evolve. You treat every feature, every doc, every demo as an experiment in human cognition. You listen until it hurts. You build the smallest possible intervention. You learn faster than the organisation can forget.
Internal DevRel, done right, turns the platform from an infrastructure product into a living ecology of learning. It shifts the question from “How do we get them to use it?” to “How do we help them grow?”
And in that shift, something beautiful happens: Adoption stops being a KPI, and becomes a by-product of respect.
Listen. Build. Learn. Make Developers Badass.
Don’t build for developers. Build with them. Listen until you hear their pain hum like feedback through a live amp, build something small that eases it, then learn fast enough to stay worthy of their trust.
Some Practices
Listen Deeply — Run User Needs Mapping workshops where developers narrate their actual day, not their ideal one. Shadow deployments like an anthropologist, noting where frustration leaks out. Ask questions that begin with “When was the last time…” instead of “Would you like…” Maintain a “Friction Log” where every curse, workaround, and Slack rant becomes a clue. Treat every complaint as a love letter in disguise.
Build Small, Build With — Prototype interventions, not features: a simplified onboarding flow, a “2-minute win” tutorial, a one-click golden path. Co-create with developer champions. Let them show you how they’d actually use it. Make progress visible — badges, dashboards, streaks, stories. Design for confidence first, compliance later.
Learn Relentlessly — After each DevRel loop, hold a “Learning Review”: what surprised us, what shifted understanding? Publicly share “You Said / We Did” dashboards to close the empathy loop. Track not just adoption, but Time to Flow, Confidence Index, and Golden Path Mastery. Celebrate developers teaching each other — the truest signal of badassery. Consider seeking iterative feedback from develops following the launch of new platform capabilities using questions you might previously have reserved for onboarding new developers:
Were there any surprises?
Were there any confusions?
What were the successes?
Any questions?
Tell Stories, Not Updates — Replace release notes with narratives of mastery: “Here’s how the Payments team cut deploy time by 60%.” Make developers the heroes; make the platform the mentor. Honour the explorers who break the path, the maintainers who guard the gates, and the firefighters who restore order. Every story should whisper: you could be this good too.
Institutionalise Listening — Make “Listen → Build → Learn” the heartbeat of the platform roadmap. Ritualise the loop:
Platform Listening Lab – monthly empathy sessions.
Mini-Experiments Board – backlog of hypotheses.
Story Sprint – one developer success story per iteration.
Learning Review – fortnightly reflection on insights.
Platform Campfire – informal storytelling forum.
Some things to avoid
Listen Theatre — surveys without sincerity; empathy without consequence.
Build Syndrome — over-engineering answers to unasked questions.
Learn Amnesia — forgetting to encode what the team discovers.
Hero Worship — spotlighting DevRel personalities instead of developer progress.
Metric Myopia — counting users, not confidence.
When DevRel turns into marketing, developers go silent. When DevRel becomes anthropology, developers open up.
A Helpful Checklist
Have we mapped what developers are actually trying to do this quarter?
Have we reduced one major source of friction through a small, measurable intervention?
Have we learned something that changes our roadmap?
Have we told a story that celebrates a developer’s progress, not our platform’s features?
Have we closed a feedback loop publicly — “You said / We did”?
Are developers teaching each other faster than we can document it?
If the answer to all six is “yes,” your platform is no longer an API garden. It’s a habitat for mastery.
Some Examples
The “Golden Path Diaries”: short internal posts where developers describe a moment of unexpected ease. (“I deployed to prod before lunch — and nothing exploded.”)
The Platform Listening Lab: quarterly workshop mapping needs across archetypes. (“The Firefighters” wanted rollback buttons; “The Makers” wanted autonomy.)
The Confidence Pulse: a recurring survey asking only one question — “How confident do you feel shipping through the platform today?”
Platform Campfire: monthly event where developers share war stories and “aha!” moments — fuel for future platform improvements.
Each of these rituals turns a technical product into a trust network.
“A platform that listens becomes a mirror.
A platform that builds becomes a bridge.
A platform that learns becomes a legend.”
Further Reading
Kathy Sierra – Badass: Making Users Awesome
Rich Allen – User Needs Mapping
Eric Ries – The Lean Startup (for the build-measure-learn loop, ancestor to listen-build-learn)
Hafsa El Maizi - Onboarding 2.0: Designing better developer interactions from day one
David Anderson - Creating Momentum with The Value Flywheel Effect
Steve Smith - “I hired a platform product manager, but our platform is still less popular than Cheetos chapsticks” for listen-build-learn
The practices list is good but the "Institutionalise Listening" section is where it gets real. You need rituals that make listening the heartbeat of the roadmap, not a quarterly checkbox. Most teams do one listening session, build what they hear, then go silent for six months. The fortnightly Learning Review is critical. Without it, teams forget what they learned and repeat the same mistakes. Culture change doesn't happen from one-off workshops. It happens through consistent, repeated patterns that become 'just how we work.'