The most common DevRel plan at startups is also the most expensive in human terms: “We’ll hire one person and see.”
See what? Whether community appears by magic? Whether one generalist can out-content a media team, out-support a support team, out-message product marketing, and still show up as a peer to senior engineers? “Hire one and see” is not strategy. It is a setup — usually for burnout, sometimes for a quiet program death that leadership later summarizes as “DevRel didn’t work.”
Solo DevRel can work. Many of us have done it. The difference is whether solo is a scoped operating model or an infinite job-shaped hole.
Why companies default to solo
The logic is understandable:
- Budget allows one headcount, not a team.
- Founders feel developer adoption pressure but cannot define the motion yet.
- Competitors have “DevRel” on the about page, so it feels like a missing checkbox.
- A senior hire seems safer than an agency and cheaper than a full team.
None of that is evil. The failure starts when the company confuses headcount with design. One person is a capacity constraint. Strategy is what you choose not to do inside that constraint.
What the setup looks like in practice
You know you are in the setup when most of these are true:
- The JD lists content, community, events, docs, social, support, partners, and “internal advocacy.”
- Success is described as “build presence” or “get developers excited.”
- Every team believes they have a claim on your calendar.
- There is no written 90-day outcome.
- There is no peer to review talks, drafts, or prioritization.
- You inherit a Discord that is really a free support queue.
- Conference season arrives as a surprise every quarter.
This is the randomisation trap Chris Reddington’s research among DevRel leaders keeps surfacing: lots of activity, thin golden thread from company goals to daily work. Solo multiplies the trap because there is no team buffer — only you, and the loudest Slack ping.
Unclear prioritization plus missing peer support is not a character flaw in the hire. It is an organizational design failure with a person-shaped blast radius.
The real costs (beyond the salary line)
1. Burnout as a feature, not a bug
Solo DevRels often work evenings because community does, travel weeks because events do, and still owe Monday status decks. Early-career people leave the field. Senior people leave the company. Either way, institutional knowledge walks out.
2. False negatives on the function
When solo fails, leadership often concludes “DevRel ROI is unproven.” What failed was an unscoped omnibus role under marketing metrics. The postmortem rarely says that. The next hire inherits the stigma.
3. Quality debt
Content without maintenance, samples that bit-rot, community without moderation standards, feedback without product partners — solo under load creates artifacts that look like progress and age like milk.
4. Invisible internal work
Educating stakeholders, writing charters, fighting for measurement — none of that shows on a social dashboard. Solo practitioners drown in it while being asked why the LinkedIn is quiet this week.
When solo actually works
Solo is viable under constraints that look more like a product launch than a department fantasy:
| Condition | Why it matters |
|---|---|
| One primary outcome for 90 days | Creates a decision filter for every request |
| Explicit non-goals | Protects against randomisation |
| A keystone metric leadership already trusts | Ends vanity-metric debates early |
| Product/docs partners | DevRel cannot fix a broken activation path alone |
| Executive sponsor | Someone who can say no on your behalf |
| Peer review somewhere | Mentor, fractional peer, or guild — not pure isolation |
| Time-boxed experiments | Events and channels as bets, not permanent obligations |
A better default than “hire one FTE and see”
Companies have more options than they use:
Option A — Scoped solo FTE (first 6 months)
Hire for a specialty that matches the bottleneck (content/education, community, or DX), not a mythical full-stack DevRel unicorn. Revisit team shape after the first outcome ships.
Option B — Fractional senior (90 days)
Bring a senior practitioner to design the charter, stand up the scoreboard, ship the first activation path, and decide what FTE profile you actually need. This is cheaper than a wrong full-time hire and faster than learning by burning a junior.
Option C — Hybrid
Junior or mid-level executor + fractional senior oversight. The senior protects prioritization and quality; the executor ships volume inside a clear system.
Option D — No DevRel yet
If the product cannot deliver first value, docs are fiction, and no one will staff support, fix the product. DevRel on a broken path is lipstick. Saying no is strategy.
If you are the solo DevRel right now
You may not control headcount. You can still refuse the full setup.
- Write the charter yourself and socialize it. Silence is consent to infinite scope.
- Pick one keystone and report it weekly in one channel leadership already reads.
- Create an intake rule — “new requests need outcome + owner + deadline or they wait.”
- Time-box community hours so support does not eat strategy.
- Kill or pause two channels this month. Attention is your real budget.
- Find peers outside the company — guilds, fractional networks, trusted reviewers. Isolation is optional.
- Document the no’s you already make. When performance review comes, show the tradeoffs you managed.
If leadership rejects every boundary, believe them. Update your resume while you still have energy. Leaving a bad design is not quitting the craft.
If you are the founder or VP funding this
Ask yourself honestly:
- Do we need ongoing DevRel capacity, or a 90-day launch / docs / community stand-up?
- What is the single outcome that would make this hire obviously worth it?
- Who will sponsor prioritization when Sales and Marketing collide?
- Are we ready to act on developer feedback, or only to collect it?
- Would we rather have one senior day-a-week with teeth than five junior days of thrash?
The companies that get this right treat DevRel like any other high-leverage function: clear outcomes, constrained scope, measurement that matches the work, and enough seniority to say no.
Closing
Solo DevRel is not automatically a mistake. Unscoped solo DevRel is. “Hire one and see” outsources strategy to the person least empowered to set it.
If you want the function to survive, design the job like you design the product: constraints first, outcomes second, heroics never as the plan.
That is how you stop setting people up — and start building a practice.