The Detour?
I took my first developer relations job in college without fully understanding what I was signing up for. At the time, I thought of it as a stepping stone to put on a resume while I figured out what "real" engineering work really looked like.
That's not what happened.
What DevRel Actually Taught Me
I wasn't just building product or just talking to users, I was building the systems that keep them both afloat, and more of the organization. This exposured to virtually all major parts of a tech startup, regional enteprise, and early stage companies.
This is a very diverse role that's difficult to define. Here are some of it's common duties, all of which I've done:
- Translating between engineering, product, and the developers using use what we shipped.
- Gathering feedback and relaying it to the right people, which later became powerful insights that led to successful business decisions in virtually all departments.
- Being a voice for the users to the company, and the voice of the company to the users.
- Fielding support questions that turned into bug reports and long-term customers.
- Filling in gaps where documentation failed people in real time.
- Testing new releases and managing tester communities.
- Onboarding new users as a trusted, educative product expert.
- Making user-informed product decisions.
- Building developer-first communities and marketing campaigns.
- Marketing the product as a tech evangelist.
- Sitting in on internal engineering conversations and then having to explain the why behind decisions to people who had none of that context.
- Mastering context switching and prioritization to balance many diverse roles, and not losing momentum between them.
Plus programming!
At first, it didn't feel like "real" technical work. But over time I realized this work builds an important business advantage for tech companies. Work that is rooted in empathy for the user, team, and businesses too, that serves to keep them all afloat and aligning smoothly.
And it's not new. Developer relations originated in the 80s-90s during one of the initial consumer tech booms. It's what set todays leading tech companies (Apple, Android, Ebay, and much more) apart from the others. Ultimately a defining move for their long-term success. Here's my favorite talk on DevRel History and Origins: History of Modern Developer Relations by Brandon West.
Glue Work Gets a Bad Rap
I panicked when I first discovered the true definition of glue work. It seemed unglamorous, and something that especially plagued fellow women in tech. Just coordination, documentation, support, cross-team translation. Not "real engineering." It doesn't show up neatly on a roadmap, and ownership is harder to define.
Glue work has a reputation problem, and I understand where that stigma comes from. Glue work may be largely invisible by design, but that's exactly the point. When it's done well, it's easy to go unnoticed. But it's what keeps teams, users, and systems held together, and someone has to do it. The question isn't whether it's valuable, the question is whether you treat it as beneath you or as a skill worth developing.
Not All Glue Work Is Created Equal
To be completely frank, I have never had glue work that felt meaningless or low-visibility. The value has always been obvious to me, and I've had amazing managers who honed in on ownership. That said, I don't want to romanticize all glue work equally, I know it can be thankless and low-leverage. But part of maturing into this work is learning to identify the difference, and it's as simple as asking yourself -- is this really needed, or is it just busywork?
Some questions to help you figure it out:
- does the work compound and scale?
- is documentation you write paying off?
- is the support / communication pipeline you designed preventing issues, boosting productivity, and retaining more users?
- does your onboarding lead to faster results?
- is your system making work more efficient?
- what can you identify and say "I owned this?"
Owning My Generalist Identity
For a long time, I treated my generalist streak as something to eventually grow out of. I expected I'd pick a lane once I "figured out" what kind of engineer I wanted to be. What actually happened is that DevRel, support work, and glue work became the throughline of my career, and one I'm very proud of.
Eventually I stopped seeing "jack of all trades" as a hedge and started treating it as a specialty. Developer Success leadership is, in a lot of ways, generalism formalized: you need to understand the engineering deeply enough to be credible, the user's experience deeply enough to advocate for them, and the organization deeply enough to know where the gaps actually are. That's not a fallback career. It's its own discipline.
And in the age of AI, I believe this is becoming increasingly valuable.
Further Reading:
