What a DevRel Actually Does All Day
People hear "Developer Relations" and picture someone at a conference with a branded hoodie, demoing something on stage, then flying to another city to do it again. That is a real part of the job for some people on some teams. It is also maybe 10 percent of what the role actually involves.
The honest answer is that DevRel is one of the hardest roles to explain because it sits at the intersection of engineering, marketing, and product, and depending on the company, it can lean heavily into any of those three. Slack's engineering blog describes DevRel as "an interdisciplinary role that sits in a border space between product, engineering, and marketing." That description is accurate and also somewhat unhelpful if you are trying to understand what someone in this role actually does between 9am and 6pm.
So here is what it actually looks like.
Most of the day is content work
According to the 2024 State of Developer Relations survey, content development was the top job activity for DevRel professionals, with 50.3 percent focused on educational content like tutorials and workshops, and 43.5 percent on technical documentation. Advocacy came third at 43.2 percent. This has been consistent for several years running.
What that means practically: a significant portion of a DevRel's week is writing. Blog posts, tutorials, API walkthroughs, sample applications, README files, code comments, changelogs. Not marketing copy. Technical writing aimed at helping another developer understand something and do something with it.
The difference between this and a technical writer's job is that a DevRel is writing from a place of actually having built something with the product. If the SDK has a rough edge that makes a common integration annoying, the DevRel knows because they hit it themselves while building the demo app. That experience is what makes the content credible and useful to other developers, rather than just accurate.
There is a lot of internal communication that nobody outside the team sees
The other thing that actually takes up significant time is translating between developers and the product team. This is sometimes called "closing the feedback loop" but in practice it is more continuous than that phrase implies.
A developer posts a question in a community forum that reveals a gap in the documentation. The DevRel sees it, answers it, and then files it internally as a docs improvement request. A recurring pattern of similar questions suggests a deeper product friction, and the DevRel writes it up as a product feedback item. A conference conversation surfaces an integration use case the product team had not considered. The DevRel brings it back.
The Wikipedia article on Developer Relations describes this as the "zeroth customer" model: using the product directly, finding problems, and advocating for improvements from the inside. Developer advocates are essentially the first real user of every new feature, before it ships, and the most organized collector of feedback after it does.
This is the part of the job that has the most impact and is the least visible externally. The reason an API has an idempotencyKey field, or the reason a webhook fires with enough detail to avoid polling, or the reason there is a TypeScript SDK at all — those decisions often trace back to DevRel feedback.
Events and community, but not in the way people imagine
Speaking at conferences is real, but it is a smaller slice of the calendar than the outside view suggests. The 2024 State of Developer Relations survey found that public speaking at events held at around 40.3 percent as an activity, while other event activities like attending, booth duty, and sponsoring declined year over year. Social media was down to 12.3 percent.
What takes more consistent time is community management: answering questions in Discord or Slack, moderating a forum, following up on GitHub issues, tracking what developers are building and asking, spotting which threads are turning into repeat friction reports. This is not glamorous work. It is also the only way to stay current on what the developer community actually needs versus what the product team thinks they need.
The same 2024 report found that 67.3 percent of DevRel professionals identified measurement as their top challenge. This is a real tension in the role. Building documentation that helps a developer unblock themselves at 11pm does not show up in an obvious metric. Writing a tutorial that gets referenced in 200 Stack Overflow answers over two years does not map cleanly to a quarterly number. The impact is real and it is genuinely hard to quantify.
The role looks very different depending on the company size
At a small company, the DevRel is usually one or two people doing everything: writing docs, building sample apps, running the community, speaking at meetups, filing product feedback, managing social media, writing changelog entries, and responding to developer support tickets when the load is high. The job is generalist by necessity.
At a larger company with a dedicated team, roles start to specialise. Some people focus primarily on content and documentation. Others own developer experience, which means auditing the onboarding flow, testing the SDK, running friction logs, and working directly with the product team. Others own community. Others own events. According to a DevRel career overview at Draft.dev drawing on the 2024 State of DevRel data, developer experience audits are becoming more of a priority, with the number of programs that never conduct them dropping from 44.2 percent to 31.2 percent year over year.
What makes someone good at it
The people who seem to last in this role and do it well tend to share a few things: they are comfortable with ambiguity — as a former Firebase DevRel described the job, it is basically "figure out what developers need and provide it" — they genuinely enjoy both coding and explaining, and they have enough product empathy to understand why a feature was built the way it was, even when they are arguing for it to be different.
The State of DevRel consistently finds that burnout is a top-five challenge for practitioners, at 40.1 percent in 2023. This makes sense when you understand the shape of the role. You are producing a high volume of technical output, maintaining community relationships, managing internal stakeholder communication, and trying to measure work that resists easy quantification, often simultaneously. The variety is genuinely one of the best things about the role. It is also what makes it exhausting if the scope is not managed carefully.
The short version: a DevRel is the person who builds with the product so other developers do not have to start from scratch, translates what the developer community is experiencing back to the people building the product, and does enough public-facing work that developers know the company is paying attention. On a good day, all three of those things happen at once. Most days, you are working on one of them and hoping the other two are still moving.
