As the Head of Technology at the manufacturing software company Fabriq, Yacine Hmito frequently interacts with technical products. He often finds blog posts without technical details, so he’s unable to assess the technology. Maybe it would be forgivable if he could discover the vision for the product. That’s usually missing, obscured by marketing speak. Then, Hmito attempts to use the product but finds it’s not self-serve. And then he bails: “If I see ‘Book a demo’ or ‘Talk to Sales,’ I am out.”
That’s the common experience of developers, engineers, architects, and other roles asked to evaluate technical products. Hmito’s experience is one we’ve consistently seen developers voice, often accompanied by the not particularly useful refrain of “developers hate marketing.”
While that may apply for some, the truth is that developers tend to be unresponsive to traditional marketing tactics. If you can understand the distinction, you may find yourself amongst the few marketers who succeed despite the skepticism of a technical audience.
What causes unresponsiveness? In this post, we’ll cover three categories: promising too much and delivering too little, demanding more developers’ attention than they want to give, and not answering their questions. These are the sorts of things that make Hmito and developers like him click away, close tabs, and maybe even write mean things about you in chat — all things you’d like to avoid.
Marketing Frequently Overpromises and Underdelivers
Imagine yourself reviewing a competitor’s comparison table of your product and theirs. Every line or two, you might find yourself shouting at your screen. Pointing at their apples and your oranges. These charts are obviously biased, and your competitor is describing their product in the best possible light.
But you don’t just bring that level of skepticism when it’s your own product that’s the focus — you bring it for every piece of technical marketing you see, and so do developers.
When engaging with technical content, developers look for trade-offs and edge cases. To build faster, for example, what decisions did this company make? What are they doing for me that I might want to do myself? If no frontend experience is required, does that mean I can’t change how the frontend code looks or acts?
Even well-meaning developer messaging can look like an outrageous claim from the skeptic’s standpoint. And it’s a developer’s job to be skeptical! Building good software means watching for areas where computer instructions are open to (mis)interpretation.
Developers are also great at pattern matching. They’ve seen website headlines and polished demos that don’t hold up under the scrutiny of even a glance at the docs. If your promise is too good to be true, it will probably underdeliver. That matches their pattern.
To avoid tripping their radar, avoid hand-wavy or overly flowery messaging, including:
- Hyperbole: Easiest, fastest, simplest, best
- Glossy solutions: Highly scalable, zero-config, plug-and-play
- Non-technical benefits: World-changing, ROI guaranteed, high-velocity
They’ve been burned before. Let’s not bring up those memories.
Sometimes, when we advise companies about developer audiences, they’ll ask how to handle the situation where their product really is the easiest, most scalable, game-changing solution to a dev’s problems.
We tell them to find another way to say it, ideally by framing how well they understand the developer’s pain points; and, perhaps, using toned-down language that can be backed up by data.
Developers Don’t Want Marketers to Steal their Attention
Any deep work requires focus. I’m writing this post in a state of intense concentration. By getting my thoughts into the right order, I’m hoping they’ll make sense as you read them. Every knowledge worker needs deep work periods. Developers need them more than most.
We’ve known the importance of developer attention for some time now. The Joel Test is 25 years old. Though some of its questions may show their age, #8 calls out the need for “quiet working conditions.” And that’s another way of saying attention — something far too many marketers attempt to steal, which leads to what we all interpret as unresponsiveness. Really, devs are just protecting their focus and attention.
Let’s consider the common metrics marketers use to identify or qualify leads:
- Fills out a form
- Downloads an e-book
- Registers for a webinar
- Signs up for a trial
Each of these asks for a developer’s attention. However, just because they engage doesn’t mean they’ve given you free rein over all their attention. And this intention disconnect is where developers feel like marketing loses their goodwill.
For example, a developer may be seeking information about a technical problem. They see your e-book or similar content that promises to solve the problem but are greeted by this:
Look at those personal data fields: they’re all angling to misinterpret information-seeking as a lead signal. I’ve seen forms reject Gmail addresses (we want your professional attention), set phone numbers as a compulsory field (to demand synchronous attention), and even request addresses — for digital downloads, so I can only imagine they plan to show up at the developer’s house.
There may be technical reasons for displaying specific form fields. And certainly, a marketer needs personal data to take further steps with qualified leads. But the line for these signals gets drawn far too closely for most developers, so they retreat to guard their attention.
Not every signal is a purchase signal.
Consider the next step companies tend to ask from this technical audience: Join a call, check out a presentation, or watch a demo. These are all asking for even more attention. All the while, it’s very likely that the developer didn’t even get their initial questions answered.
This brings us to the last misstep many technical content marketers make by approaching developers with traditional methods.
Marketing Often Does Not Answer Technical Questions
The overpromises in your marketing disguise what the product actually does. The thirst for metrics is what keeps these developers at arm’s length. So, the previous two sections are ways of keeping developers from the answers they seek.
A developer may find their way to you via product pages, educational resources, or a link from a co-worker. As they navigate, they may check out the home page or follow helpful signals that you can solve their technical problems. The one place they’ll review as soon as possible? Your documentation, of course. It’s the surest way to see if your product can back up its claims.
Devs click on docs because they think they’ll find their answers there — even if it takes some work on their part, wading through references and other minutia. In fact, if you ask them what they want from marketing, they’ll suggest: “Just show me the docs.” That’s the go-to answer because they don’t trust marketing to deliver the truth. It’ll be quicker to figure it out themselves.
“For developers, by developers” is messaging so frequently used that I’d advise against it now. However, the meaning behind it is that these companies want to let developers know that they see them. It suggests that they won’t be overpromised, their time won’t be wasted, and they’ll be able to find their answers. Above all, it shows the company is worthy of developer trust.
Indeed, all of your developer experience should build trust. From the first impression — whether the home page, a product page, or a blog post — through every interaction the developer has with your company, you want to send trust signals. Many traditional marketing approaches will be mistrusted, even if you have good intentions.
Build Trust with Your Technical Marketing
When you examine the indicators that make developers unresponsive to your marketing, it may initially feel restrictive. Especially if you’ve moved from traditional marketing to a more technical audience, it might feel like you’re losing items from your trusty toolbox.
Instead, embrace the constraints. Look for ways to reverse these indicators. Your marketing can build trust rather than erode it.
Implement a list of words and phrases to avoid — like easy, scalable, and high-velocity — and replace them with more factual descriptions. Reconsider what signals make a lead, or question the volume and type of information you must collect. And see if you can guide visitors toward deeper technical details, which can answer their questions and further qualify them when they’re ready.
Yes, it might be more complicated than reaching into your old toolbox. Maybe you need help assembling a new toolbox — one that will get more and better responses, earn developer trust, and maybe even get some fans in the process.