"So you just travel and go to conferences?"
That's usually what people say when I tell them I work as a Developer Relations or DevRel. And look, I honestly get it. From the outside, it probably looks like I'm just collecting conference badges, having good food, free stickers and t-shirts.
But after attending some big conference like KubeCon India, speaking at OpenSSF Community Day India, and hanging out at PyCon India, Bengaluru this year, I've got some thoughts to share with you all. Yeah, conferences are fun. But DevRel? It's way more interesting (and messier) than you'd think.
The Conference Life Looks Cooler Than It Actually Is
Let me paint you a picture. You're at KubeCon. There are thousands of people, companies booths everywhere, and someone's handing out yet another t-shirt you'll never wear. You're tired because you stayed up late debugging your demo that broke 10 minutes before your talk. Your phone's dying because you forgot your charger. And you're pretty sure you've had 6 cups of coffee today.
Glamorous? Not exactly.
But then something cool happens. You meet someone who's been stuck on a problem for weeks, and he actually know how to help. Or someone comes up after your talk and says "Hey, that thing you mentioned? That's exactly what I needed and can you help me in that?."
That's when it clicks. This isn't about the free food or the fancy venue. It's about actually being useful to people.
At OpenSSF Community Day India, I gave my first real conference talk. Was I nervous? Absolutely. Did I rehearse it like 20 times? You bet. But standing there, talking about something I care about, and seeing people actually paying attention (not checking their phones!), that felt pretty great.
The Real Conversations Happen in Random Places
Here's what nobody tells you about conferences: The best stuff doesn't happen during the scheduled talks.
At PyCon India, I had this conversation with a developer at the lunch table. We started talking about what he do in the Python community, and they shared their entire workflow, their pain points, why they chose certain tools over others in his work. I think, that 20-minute chat taught me more than any survey ever could.
At KubeCon, someone came to me during a coffee break and showed me his side projects about the communtiy. Right there, between sessions, we debugged an issue together, he has. No slides, no agenda, just two people trying to solve a problem.
These moments are gold. This is where you learn what developers actually struggle with, what they love, what makes them want to throw their laptop out the window(But can't).
Giving Talks Is Terrifying (But Worth It)
Let's be real about speaking at conferences. It's scary.
Before my OpenSSF talk, I was pacing backstage like I was about to take my final exam. What if nobody shows up? What if everyone shows up and I completely blank? What if my demo fails? (Spoiler: demos always fail. Plan accordingly, even my failed.)
But here's the thing about giving talks - it forces you to really know your stuff. You can't just go and understand something. You need to explain it clearly enough that someone who's never seen it or heard it before can follow along with that.
And when you're done? People come up with questions, ideas, their own experiences. Suddenly you're not just talking at people, you're having actual conversations about that topic. That's the fun part actually.
Plus, there's something weirdly satisfying about seeing your slides on a big screen. Not gonna lie, that's pretty cool.
This is my picture from my talk when my demo stop working!
DevRel Between Conferences (AKA The Actual Job)
Okay, so what happens when you're not at a conference? Because that's will be like 95% of the time.
Most of my days look like this:
Writing docs that don't suck. After hearing someone at PyCon say "I read your docs three times and still didn't get it," I learned that what makes sense to me might not make sense to everyone else. Now I try to write like I'm explaining it to a friend.
Hanging out in community channels. Someone's stuck at 2 AM trying to deploy something. You drop a quick tip that unblocks them. They're happy, you're happy, everyone's happy.
Making sample apps and demos. Because sometimes people just want to see "how do I actually use this thing?" Not theory. Not architecture diagrams. Just show me the code.
Being the bridge between users and product teams. When five different people tell you the same thing is confusing, that's feedback worth taking seriously.
None of this is exciting enough for Instagram. But it's what actually helps people.
The Unglamorous Truth
DevRel has this reputation of being all fun and games. Travel! Events! Swag! And sure, those things exist. But nobody talks about:
- Answering the same question 47 times (and trying to sound enthusiastic on answer 47)
- Writing the tutorial that took you 8 hours for someone to read in 5 minutes
- Debugging someone else's setup over a spotty video call
- Realizing your blog post has a typo after 500 people have already read it
- Spending hours planning an event and having 3 people show up
It's not all highlight reels. Sometimes it's just showing up and doing the work, even when nobody's watching.
Why I Actually Like This Job
Despite everything I just said, I genuinely love this work. Here's why:
You're constantly learning. Every conversation teaches you something. Every question makes you think differently. You can't do DevRel and stay stagnant.
You meet genuinely interesting people. At KubeCon, I met someone building cloud infrastructure for rural schools. At PyCon, I talked to developers building tools for climate research. These people are doing cool stuff, and you get to be part of their journey.
You see real impact. When someone builds something because of a tutorial you wrote, or when a feature gets added because you advocated for it, that feels good. You're not just talking about technology, you're helping people use it.
The community becomes your community. You start recognizing faces at events. People remember you. You become part of something bigger than just your company or project.
What DevRel Actually Is
I was at Open Source Summit India, and there Aditya Oberoi gave a talk on DevRel and he mentioned a very good definition of DevRel. As you can see that in the image below.
After going to these conferences, and having countless conversations, here's my take:
I feel DevRel is a person who represents the company to the community and vice versa.
It's about:
- Writing guides that actually make sense
- Answering questions without being condescending
- Building tools that solve real problems
- Creating spaces where people feel comfortable asking for help
- Being honest when something's broken instead of making excuses
Yes, events are part of it. Speaking at conferences is part of it. But those are just the visible parts. The real work is everything else, the daily grind of helping people, listening to feedback, and trying to make things better. And these are the some real work which goes hidden.
If You're Thinking About DevRel
My advice will be? Don't do it for the travel or the stage time or just for the fame. Those things are bonuses, not the job honestly.
But do it if you actually enjoy helping people. Do it if you get excited when someone finally understands something you explained. Do it if you care about making technology more accessible and less frustrating.
And if you do end up at a conference like KubeCon or PyCon? Don't just collect swag and business cards. Have real conversations with he people and make friends. These friends will really help you in future. Ask people what they're building. Learn about their challenges. That's where the actual interesting stuff happens.
Because at the end of the day, DevRel isn't about how many events you attended or how many talks you gave. It's about how many developers you actually helped. And honestly? That's a pretty good way to spend your time.
P.S. — If you see me at a future conference, say hi! I promise I'm friendlier than I look when I'm frantically trying to find a power outlet 10 minutes before my talk.
Top comments (0)