Founders, Stop Putting DevRel in the Wrong Box

TL;DR

• DevRel is not marketing with a hoodie, product management with a conference badge, or support with a public calendar.
• If you hire DevRel, let them cook. Give the role clear outcomes, trust, and room to build the relationship between your company and developers.
• Good DevRel needs community respect and commercial judgment. Open source roots and sales alignment are not enemies.
• DevRel, sales, and customer success should form a tight loop. That loop can grow the business without betraying the community.

Abstract

Founders make DevRel harder than it needs to be.

They hire someone because the company needs developer trust, then they stuff the role under marketing. Or product. Or community. Or sales. Or whatever department has the budget that quarter.

Then everyone gets frustrated.

Marketing wants campaigns. Product wants roadmap feedback. Sales wants pipeline. Community wants care. Engineering wants examples. The founder wants credibility. The DevRel person is expected to satisfy all of it while proving ROI in a neat little box.

That is not a role. That is a trap.

DevRel is its own thing. It needs commercial awareness, community trust, technical credibility, and a strong internal loop with sales and customer success. If you cannot define that up front, you may spend months hiring someone, put them in the wrong structure, and then feel bad when it does not work.

Or you can contract with someone who has done the work, define the motion clearly, and avoid the expensive mistake.

Table of Contents

• The Founder Mistake
• DevRel Is Its Own Function
• Let Them Cook
• The Commercial Mindset Matters
• Selling to Developers Is Not Betrayal
• The Golden Braid: DevRel, Sales, Customer Success
• Hire Carefully or Contract First
• Summary
• Next Steps

The Founder Mistake

The founder mistake is thinking DevRel must belong cleanly somewhere.

Marketing says:

Put DevRel here. They make content and drive awareness.

Product says:

Put DevRel here. They talk to users and bring feedback.

Sales says:

Put DevRel here. They influence deals and help technical buyers.

Community says:

Put DevRel here. They run Discord, GitHub, events, and meetups.

Each department sees a true part of the role. None of them sees the whole thing.

That is why DevRel gets mismanaged. The role becomes a tug-of-war between functions with different incentives.

If you put DevRel entirely under marketing, the work can become noise: campaigns, impressions, event activity, and content volume.

If you put DevRel entirely under product, the role can become an unpaid research arm with no external operating rhythm.

If you put DevRel entirely under sales, the community may stop trusting it.

If you put DevRel entirely under community, the work may become warm and beloved but commercially disconnected.

DevRel touches all of those functions. It should not be swallowed by any one of them.

DevRel Is Its Own Function

DevRel exists to manage the relationship between your company and the developers around your product, platform, ecosystem, or category.

That relationship includes:

• education
• trust
• activation
• feedback
• technical content
• examples
• demos
• community participation
• product signal
• sales enablement
• customer expansion
• public credibility

That is why DevRel is not the same thing as developer marketing or community. It overlaps with those functions, but it is not reducible to them.

The best DevRel people can move between worlds.

They can explain technical details to developers. They can translate community feedback to product. They can help sales understand objections. They can help customer success see patterns. They can help marketing avoid embarrassing claims. They can help founders sound less vague.

That range is the value.

It is also why the role is hard to hire for.

Let Them Cook

If you hire a strong DevRel person, do not smother them with unclear expectations and constant departmental whiplash.

Let them cook.

That does not mean “give them no goals.” It means define the outcomes and then give them enough trust to build the motion.

Good DevRel needs room to:

• talk to developers directly
• build real examples
• write in a technical voice
• say when the product is confusing
• push back on weak claims
• route feedback internally
• support sales without becoming empty sales performance
• support community without becoming community babysitting

Founders often say they want developer trust. Then they panic when DevRel tells them what developers actually think.

Do not do that.

If you want the role, accept the signal.

The Commercial Mindset Matters

Here is the part some companies avoid saying out loud: DevRel needs a commercial mindset.

Not a sleazy one.

Not “turn every community conversation into a sales pitch.”

But a real understanding that the company has to make money to survive, pay employees, support users, maintain open source work, and keep building.

Open source is good. Community is good. Advocacy is good. Helping developers is good.

But a DevRel person who acts as if revenue is a moral failure will eventually create problems inside the business.

The role needs someone who can hold both truths:

• Developers deserve respect, honesty, useful help, and technical clarity.
• The company needs customers, expansion, enterprise contracts, and revenue.

That is not contradiction. That is the job.

Developer trust and commercial survival have to coexist.

Selling To Developers Is Not Betrayal

Some people treat selling to a developer community as if it is automatically dirty.

That is childish.

Most reasonable community members understand that companies need money to exist. They understand that an open source project may have a hosted product, enterprise version, paid support, security features, compliance controls, team management, SLAs, or private deployment options.

The problem is not selling.

The problem is selling badly.

Bad selling hides the tradeoff. It manipulates. It pretends a sales motion is community care. It spams. It refuses to name limits. It treats developers as leads before treating them as people.

Good selling is different.

Good DevRel can say:

• here is what is free
• here is what is open source
• here is what the enterprise version adds
• here is who needs it
• here is who does not
• here is how to learn more
• here is the technical reason this exists

That is not betrayal. That is clarity.

If the community does not know there is an enterprise version, how are the right people supposed to evaluate it?

The DevRel person should not be afraid to help developers discover the commercial path when it is relevant.

The Golden Braid: DevRel, Sales, Customer Success

DevRel should have a tight loop with sales and customer success.

This is the golden braid.

Sales hears the market’s objections.

Customer success hears what happens after adoption.

DevRel hears what developers believe, misunderstand, want, fear, build, break, and complain about in public and semi-public spaces.

When those three functions work together, the company learns faster.

Sales can tell DevRel:

• what technical objections block deals
• what comparisons buyers ask for
• what content would help evaluation
• where the enterprise story is unclear

Customer success can tell DevRel:

• where users get stuck after purchase
• which docs are missing
• which workflows create support pain
• what expansion use cases are emerging

DevRel can tell sales and customer success:

• what the community is saying
• which examples resonate
• where the product promise is confusing
• which objections are legitimate
• what technical proof is needed

That loop protects the business and the community at the same time.

It helps the company sell without losing its open source roots. It helps the community get a clearer product. It helps sales stop guessing. It helps customer success stop repeating the same fixes.

If you get this braid right, your company can go far.

Hire Carefully Or Contract First

DevRel is hard to hire for because the role does not fit a neat box.

The wrong hire may be:

• too marketing-heavy and not technical enough
• too community-purist and afraid of revenue
• too salesy and not trusted by developers
• too product-focused and not externally active
• too content-focused and not connected to business outcomes
• too visible online but weak in execution

That hiring process can take months.

Then, if it does not work, you have to unwind the role, reset expectations, and feel bad letting someone go.

There is another path.

Contract first.

Define the motion up front. Decide whether you need positioning, content, community repair, sales enablement, developer education, feedback loops, launch support, or a zero-to-one DevRel operating system.

This is why I often tell founders not to rush the first hire. See the first DevRel hire should not be a megaphone and when your AI product needs DevRel and when it does not for the broader hiring logic.

If you want the outcome without guessing your way through the org chart, talk to me. We can define the DevRel motion before you make an expensive full-time mistake.

Summary

Founders should stop putting DevRel in the wrong box.

It is not just marketing. It is not just product. It is not just community. It is not just sales.

DevRel is the relationship function between your company and developers. It needs technical credibility, community respect, commercial judgment, and tight loops with sales and customer success.

Let DevRel cook, but define the kitchen.

Next Steps

Before hiring DevRel, answer:

• What business problem should DevRel solve first?
• Who owns the role internally?
• How will DevRel work with sales?
• How will DevRel work with customer success?
• What community promises must be protected?
• What commercial outcomes matter?
• What should this person not be responsible for?

If you cannot answer those questions, do not rush the hire.

Let’s define the DevRel motion together before you spend months looking for a unicorn and then put them in the wrong box.