Why Developers Resist Marketing, and What Works Instead

Because most marketing makes claims that cannot be checked, and engineers are trained to reject exactly that. It is a standards objection rather than a skills gap. Marketing that survives technical scrutiny works: specific claims, visible limitations, and evidence the reader can verify without trusting you.

The objection is a standards objection

The usual framing is that engineers are uncomfortable with self promotion, or bad at persuasion, or too literal. I think that is mostly wrong and it leads to bad advice.

What is actually happening is a collision of professional standards. An engineer spends their working life making claims that get tested. You say the change is safe, and then it either holds in production or it does not, in front of everyone. That environment produces a strong instinct: do not assert what you cannot support.

Now show that person a landing page saying a product is powerful, seamless, and enterprise grade. None of those are checkable. To someone trained to falsify claims, an unfalsifiable claim is not neutral, it is a signal that the author is either hiding something or does not know.

So the reluctance is not squeamishness about promotion. It is a refusal to participate in a method they have correctly identified as dishonest.

The useful consequence is that the fix is not persuading engineers to be more comfortable with marketing. It is using a method that meets their standard, which turns out to work better on technical audiences anyway. That reframing is what unblocks most technical founders I talk to, because it stops asking them to override an instinct that was serving them well.

What survives technical scrutiny

Claims specific enough to be wrong. "Fast" is a word. "Returns in under a second for a typical query on a single instance" is a claim, and it invites someone to check it. Being checkable is the point: a claim nobody can disprove also cannot persuade anyone who reasons carefully.

Stated limitations. Telling people what your product does badly, or who should not use it, is the single most effective trust move available to a technical company, and almost nobody does it. It works because it is costly to say, and costly signals are the ones that carry information. It also saves you from customers who were going to churn and leave a bad review on the way out.

Evidence the reader can verify without trusting you. A working example they can run. Source they can read. A benchmark with the method described, so they can disagree with it. The measure is whether a skeptical reader can check the claim themselves rather than take your word.

Documentation treated as a marketing asset. For technical products, docs are usually where the buying decision is actually made, and they are typically funded as an engineering chore. A developer evaluating you reads the docs to figure out whether the product does what they need and whether the team is competent. Both of those questions get answered by the docs regardless of whether you intended them to.

Writing by people who did the work. Technical readers detect the difference between someone who built the thing and someone who interviewed someone who built the thing, quickly and without being able to say precisely how.

The two asymmetries worth knowing

Technical audiences are unusually intolerant of hype: one unsupportable claim discredits the rest of the page, and the penalty is disproportionate. They are also unusually generous about depth: they will read four thousand words about an internal design if it is genuinely informative, which no other audience does. Most technical marketing gets both backwards, going short and enthusiastic instead of long and specific.

Where the resistance is genuinely a problem

I would be dishonest if I only validated the objection, because it does get used as cover.

Believing the product speaks for itself. It does not. Nothing speaks for itself. People have to encounter it, and encountering it requires someone to have done the work of putting it where they are. Waiting to be discovered is not a strategy, it is a hope with a technical justification attached.

Treating all distribution as marketing, and therefore beneath you. Answering a question in a forum where people have the problem is distribution. Writing documentation is distribution. Publishing a post explaining a decision you made is distribution. Most of what actually works for technical products is indistinguishable from being helpful in public.

Confusing modesty with accuracy. Refusing to say your product is good when it measurably is, is not rigour. It is a different distortion. The standard is accuracy in both directions, and understating is a failure to meet it.

Deferring it until the product is ready. The product is never ready, and the audience takes longer to build than the software. Starting late is the most expensive version of this mistake and by far the most common.

Frequently asked questions

Why do developers dislike marketing?
Because most of it makes claims that cannot be checked, and engineers are trained to evaluate claims by trying to falsify them. Words like powerful and seamless are unfalsifiable, so to a technical reader they signal that the author is hiding something or does not know. It is a standards objection, not a skills gap.
What kind of marketing works on developers?
Claims specific enough to be wrong, stated limitations including who should not use the product, evidence a reader can verify without trusting you such as a runnable example or a benchmark with its method described, documentation resourced as a marketing asset, and writing by people who actually did the work.
Why does saying what your product is bad at increase trust?
Because it is costly to say, and costly signals carry information in a way that free claims do not. Anyone can say their product is excellent. Saying who should not use it demonstrates that you are describing reality rather than selling, and it also prevents churn from customers who were mismatched.
When is the resistance to marketing actually a problem?
When it becomes belief that a good product speaks for itself, which nothing does. When all distribution gets dismissed as marketing, even though answering questions publicly and writing documentation are distribution. When modesty is mistaken for accuracy. And when it is deferred until the product is ready, which it never is.