How to build a DevRel team from scratch

Your first DevRel hire should not be a conference speaker.

I know that sounds backwards. You're building a developer relations team. You want someone who can get on stage, fire up a crowd, and generate buzz. I get it. But if you hire a keynote speaker before you hire a builder, you're going to waste your first year.

Your first DevRel hire should be someone who can write, someone who can talk to developers and listen to what they say, and someone who can take that feedback back to your product team in a way that actually changes the roadmap. Content. Community. Connections. That's the foundation. Everything else comes after.

Why should DevRel not report to sales?

DevRel should not report to sales because the two functions have fundamentally different goals. Let's get this out of the way. Developer relations and sales have different goals, different relationships, and different trust dynamics. DevRel builds trust over the long term. Sales converts that trust into revenue. These are related but distinct activities.

The moment you put your DevRel team under a sales leader or give them pipeline targets, you change the relationship developers have with your advocates. Developers can smell a sales pitch from a mile away. When your advocate shows up in a Discord channel and developers think "this person is trying to sell me something," you've already lost.

I call this principle Help First. You give developers what you do best with no strings attached. Over time, that generosity creates brand equity. But it only works if developers believe the person helping them genuinely cares about their success, not their conversion rate.

DevRel supports sales. It warms leads. It accelerates deals. But the moment DevRel becomes a branch of your sales org, the trust that makes it work disappears.

Who should your first DevRel hire be?

Your first DevRel hire should be a builder, not a speaker. I've written about where to start with DevRel hiring, but I want to be more specific here. Your first DevRel hire needs three capabilities.

They write. Not just tweets. They write tutorials, blog posts, getting-started guides, and technical deep-dives. Content is the backbone of any DevRel program. It's the law of numbers. You speak at a conference, you influence hundreds of poeple. You write great content or produce a great video, you influence thousands, perhaps tens of thousands. A person who can publish one strong piece per week is worth more than someone who speaks at one conference per month.

They listen. Your first hire needs to be in the community every day. Forums, Discord, Reddit, Hacker News, wherever your developers hang out. They need to understand what developers love about your product, what frustrates them, and what they wish existed. Then they need to bring that feedback back to product and engineering in a structured way. I wrote about getting great customer feedback elsewhere, and the principles apply directly here.

They connect. Not "networking" in the business card sense. Real relationships with developers who use your product, developers who should use your product, and developers who influence other developers. Your first hire should be someone who naturally builds rapport with technical people.

Notice what's missing from this list. Conference speaking. Demo-building. Webinar hosting. Those things matter eventually. But they're not where you start.

When I think about what kind of developer advocate you need, the first hire is almost always a generalist who leans toward content and community. The specialists come later.

Where should DevRel report?

DevRel reporting structure is the question every leader asks me. I've seen DevRel succeed under marketing, product, engineering, and as a standalone function reporting to the CEO. There's no single right answer, but there are wrong answers.

Under sales is almost always wrong. The incentive structures conflict. Sales teams measure pipeline and closed revenue. DevRel measures trust, awareness, and developer satisfaction. When DevRel reports to a sales VP, it drifts toward lead generation and away from the long-term relationship building that makes it valuable.

Under marketing works well when the marketing leader understands that DevRel has a different cadence and different metrics. Content advocates produce feeds into marketing programs, but advocates have the freedom to prioritize developer needs over campaign calendars.

Under product or engineering works when you want DevRel tightly coupled to the developer experience.

Standalone works at scale. When your DevRel org hits 10 or more people, having a VP of Developer Relations who reports to the CTO or CEO gives the function the executive sponsorship it needs.

The real question isn't where DevRel sits on an org chart. It's whether the person leading DevRel has a seat at the table when decisions get made about the developer experience.

What should a new DevRel hire do in the first 90 days?

The first 90 days set the foundation for everything that follows. Your new DevRel hire just started. What should they do?

Days 1 through 30: learn and listen. Your first hire should go through the onboarding experience as a brand new developer. Sign up. Read the docs. Build something. Break something. Document every friction point. This audit becomes the foundation for everything that follows.

At the same time, they should be in the community. Not posting. Listening. Reading every question developers ask. Understanding what's confusing, what's broken, and what's delightful. They should meet with the product team and understand the roadmap. They should meet with engineering and understand the technical constraints.

Days 31 through 60: publish and connect. By week five, your hire should be publishing. Not product announcements. Outside-in content that takes topics developers in your market care about and provides context, analysis, and practical advice. If your product is a database, write about data modeling patterns. If it's an API gateway, write about API design. Content that helps developers regardless of whether they use your product. That's what I mean by Help First.

They should also be building relationships with five to ten developers who are influential in your space. Not pitching them. Having genuine technical conversations. Helping them with problems. Being useful.

Days 61 through 90: systematize. By month three, your hire should have established a regular publishing cadence, a repeatable process for capturing and routing developer feedback, and a clear picture of which community channels deserve ongoing investment. They should present their findings to leadership: what developers love, what they hate, and what they need.

This 90-day plan doesn't include a single conference talk. On purpose.

How do you scale a DevRel team?

Scaling a DevRel team is where most companies get it wrong. They hire too many people too fast, or they hire the wrong people in the wrong order.

Here's how I think about the stages.

One to three people

Your founding DevRel person has proven the model. Content is driving awareness. Community engagement is generating feedback that improves the product. You have evidence that DevRel works for your company.

Your second and third hires should fill specific gaps. If your first hire is a strong writer but doesn't speak at events, hire someone who does. If community engagement is consuming all your first hire's time, bring on someone with a community focus. I wrote about the three types of developer advocates, and at this stage you want complements, not duplicates.

Budget at this stage: roughly $400K to $700K for headcount, plus $100K to $200K for travel, tools, and content production.

Four to eight people

At this stage, you can start to specialize. What developer advocates do expands as the team grows.

Add a dedicated community manager if your community has grown beyond what advocates can handle in their spare time. Building a developer community is a full-time job once you hit a few thousand active members.

Add a technical writer if documentation quality is becoming a bottleneck. In my experience, docs quality directly correlates with activation rates. Every hour spent improving docs pays back in reduced support tickets and higher conversion.

Consider a developer marketer who can run campaigns, manage events logistics, and handle the operational side of DevRel. This frees your advocates to focus on what they do best: creating content and building relationships.

Budget: $1M to $2M annually, including headcount, events, sponsorships, and tooling.

Nine to twenty people

To the extent that anyone really has teams this large any more, at this scale, you're building a real organization. You need a leader who can manage managers, set strategy, and represent DevRel at the executive level.

This is when you think about geographic coverage. Developers are global. If your product serves developers in Europe, Asia, and the Americas, you need people in those time zones who understand those communities.

This is also when you add domain specialists. When I was hiring for a database company, I brought on PostgreSQL experts, former CTOs, and open-source contributors who had built-in credibility with our target audience. These hires are expensive but they accelerate trust-building in ways that generalists cannot.

At this stage, you should also have a developer experience function that sits alongside advocacy. DX engineers who improve onboarding, refine APIs, and build SDKs. The line between DevRel and DX blurs, and that's fine.

Budget: $3M to $5M annually. This sounds like a lot. It is. But if your business depends on developers adopting your product, this investment pays for itself in reduced customer acquisition costs and higher retention.

What should you measure in DevRel?

DevRel measurement requires a portfolio of evidence, not a single metric. Measuring developer advocacy deserves its own treatment, and I've written about it in detail. The short version: build a portfolio of evidence.

At the one-person stage, track content output and engagement, community questions answered, and feedback routed to product. Keep it simple.

At the team stage, add community growth metrics, developer satisfaction scores, content-attributed signups, and influenced pipeline. Influenced pipeline is different from generated pipeline. DevRel rarely generates leads directly. But it often touches developers who later become customers. Track that influence.

At scale, layer in brand awareness studies, developer NPS, and ecosystem health metrics like third-party integrations and community-created content.

The mistake I see most often is measuring DevRel like sales. Pipeline targets, MQLs, conversion rates. These metrics incentivize short-term behavior that destroys long-term trust.

Why should you not hire a conference speaker first?

Hiring a conference speaker as your first DevRel hire is a common mistake. I've been critical of this, so let me explain why.

Conference speakers are valuable. I've given hundreds of talks in my career. Speaking creates awareness and credibility. But awareness without substance is empty. If a developer sees your advocate on stage and then goes to your website and finds thin docs, a dead community, and no useful content, that conference talk was wasted.

Build the foundation first. Content that helps developers. A community that answers questions. Feedback loops that improve the product. Then hire someone who can stand on that stage and point to all of it.

The best conference speakers I've ever worked with were people who had spent months writing content and talking to developers before they ever got on stage. They had stories to tell because they'd actually been in the trenches.

How do you get started building a DevRel team?

Getting started with DevRel is simpler than most people think. If you're reading this and thinking about building a DevRel team, start simple. One person. Content, community, and connections. Give them 90 days to learn your product, understand your developers, and build the foundation.

Then scale deliberately. Add people who fill gaps, not people who duplicate effort. Measure trust, not just pipeline. And protect DevRel from becoming a sales function, because the moment it does, you lose the thing that makes it work.

I cover team building, DevRel strategy, and measurement in depth in Picks and Shovels. If you're standing up a DevRel function for the first time, it'll save you from the mistakes I made over thirty years. And for a broader look at how all of these pieces fit together, check out the Developer Relations hub.