Developer relations occupies an odd position on an early-stage org chart. It reports into marketing at one company, product at the next, engineering at a third, and directly to a founder at a fourth. Nobody thinks this is strange, because the function genuinely does touch all four.

The problem is that the reporting line usually gets decided after the hire, not before it. And the reporting line is where the definition of the job actually lives.

So a company hires an excellent developer advocate, gives them a laptop and a conference budget, and discovers three months later that the leadership team has three incompatible views of what success looks like. None of them are unreasonable. They were simply never reconciled.

The Three Jobs Hiding Under One Title

In practice, DevRel at an early-stage developer tooling company resolves into one of three distinct functions. Most job specs describe all three at once.

• Awareness. Getting the product in front of developers who have never heard of it. Talks, writing, open source presence, community participation. Measured in reach and in qualified first touches. Closest in shape to marketing, and the version most founders picture when they write the brief.
• Activation. Turning a curious developer into one who has the product working. Quickstarts, documentation, sample applications, SDK quality, removing the friction between install and first success. Measured in time to first value and in the drop-off between signup and working integration. Closest in shape to product.
• Advocacy in the account. Supporting the developers already using the product so they can convince the platform lead and the budget holder. Reference architectures, migration help, technical credibility inside an evaluation. Measured in expansion and in evaluation win rate. Closest in shape to sales engineering.

All three are real. All three are valuable. But they demand different people. The person who can hold a room at a conference is not automatically the person who will rewrite a quickstart until the drop-off rate halves, and neither is necessarily the person who can sit in an enterprise evaluation and hold their own against a competing vendor’s architect.

Hiring for one and measuring for another is the single most common way these appointments fail.

Scope Follows the Constraint, Not the Job Title

The way through is to decide which of the three the company actually needs first, and to be honest that the answer changes with the funnel.

A company with strong inbound interest and poor conversion from signup to working integration does not have an awareness problem. It has an activation problem, and hiring a conference-circuit advocate into it will produce more signups that fail at the same point.

A company with excellent documentation, high activation and almost no traffic has the opposite constraint. And a company whose product is being used widely inside accounts but never gets past the platform team into a contract has neither: it has an advocacy gap that looks a great deal like a sales problem and is not one.

The diagnostic is not “what does DevRel usually do” but “where does the developer journey break, and what would fixing it look like as a person’s week”.

Where DevRel Sits in the Sequence

Founders often ask whether DevRel comes before or after the first salesperson. The honest answer is that in developer tooling it usually comes before, and that this is one of the few places where the category genuinely departs from standard go-to-market sequencing.

In a sales-led motion, demand is created by the commercial team. In a developer-led motion, demand is created by the product and the community around it, and the commercial team converts what already exists. Hire the seller first and they spend two quarters manufacturing something the product was built to generate on its own, usually by reaching for outbound that a developer audience actively resents.

That is not an argument for hiring DevRel early and sales late as a rule. It is an argument for hiring against the constraint. If adoption is genuinely happening and nobody is converting it, the seller is next. If nothing is being adopted, no seller will fix that.

Sequencing is the underrated half of the problem, and it applies across the whole early team rather than just this role.

Measurement, Before the Hire and Not After

DevRel has a reputation for being hard to measure. It is more accurate to say it is hard to measure retrospectively, when the metric is chosen after the fact by whoever is most anxious about the spend.

The measurable version of each of the three jobs exists, and it is worth writing down before the search opens.

• For awareness. Qualified developer first touches, and the share of new signups that arrive already knowing what the product does. Not follower counts.
• For activation. Time from signup to first working integration, and the drop-off rate at each documented step. This one is genuinely precise, and it is the reason activation-focused DevRel is the easiest of the three to justify to a board.
• For advocacy. Evaluation win rate where DevRel was involved, and expansion inside accounts that had a technical champion. Attributable, though on a longer lag than anyone would like.

A company that has agreed one of these before the first interview will run a much better process, because the interview can then test for the thing that matters rather than for general enthusiasm about developers.

What This Means for the Brief

A useful DevRel brief at seed or Series A is narrower than most founders expect and more specific about outcome than about activity.

It names which of the three functions the hire owns in the first year. It names the metric. It names the reporting line, and it accepts that the reporting line will shape the work more than the job description does. It is explicit about whether the person is expected to write code, because “technical enough” means something different in each of the three versions.

And it is honest about the fact that a company will probably need all three eventually, in an order determined by where the funnel breaks first.

The companies that get this right are not the ones with the largest DevRel budget. They are the ones that decided what they were buying before they went shopping.

It is not about hiring a developer advocate. It is about hiring the specific job the product is currently failing to do on its own.

If you are scoping a DevRel hire and want a second view on which of the three you actually need first, I would be happy to talk it through. You can see how we approach hiring for this market on our developer tooling page.