Creating a winning sales flow with authentic writing from engineers

So, what’s the deal with the title of this post? Are we forcing developers to work for corporate promotion? No way! Quite the opposite, this article is for startup leaders wary of pushing their engineers. Thankfully, there are motivations for them to independently write the kinds of texts that will sell your product or service.

We’ll tackle understanding those motivations in just a bit, but first, let’s talk about who we’re writing for.

Knowing the developer tools audience

We know from our own experience that in the developer tools world, we’re working with two very specific audiences: developers as end users themselves, and their bosses, the people who decide whether to buy the Enterprise version of our software.

Irina Nazarova CEO at Evil Martians

Schedule call

That latter group can be engaged using the typical marketing tactics utilized by the big corporations (ads, exhibitions, emails, calls, and so on.)

On the other hand, engineers generally show zero tolerance for these kinds of practices. Even buzzwords like “innovative” or “blazing-fast” are a red flag for them, subconciously or otherwise.

If this is such a tough crowd, why even try?

So, we have a tricky audience to engage, so it begs the question upfront: why promote your product to these end users? The reason is simple: it’s these developers who are increasingly becoming decision-makers and in many modern companies today. As experts, they play a critical role when deciding to purchasing a developer tool:

• Preparing a list of vendors
• Testing them
• Voting for or against the purchase (all while bringing strong evidence for their decisions to the table).

With commercial open source, many sales stories begin because the developers brought and successfully implemented open source versions of the product within the project. Next comes a phase of growth, and with, it the requirement to scale to an enterprise version.

But why should developers write?

So, with the question of the audience defined, we need to also consider why we need developers involved in the controversial areas of sales and marketing, even tangentially.

This is because developers don’t just adopt a product from the first time they encounter it. Developers are informed buyers. They’re highly motivated to adopt a product based on multiple instances of positive feedbacks from their peers.

There are hundreds of developer tools out there with essentially the same functionality, and a typical pattern involves a careful reading of documentation and searching for benchmarks and feedback from other end users (that is, not marketing teams).

For example, we often see people searching for a product description who add “Reddit” to their list of keywords to find the most “honest” reviews.

That’s why building, growing, and retaining developer trust is everything!

Additionally, we must take all this into account and generate different types of writing to reach both audiences. So, ultimately, while marketing professionals can create content for C-level people, the best source for developer-oriented content is actually your own developers.

We didn’t always realize this!

Several years back, I was actually one of the most loathed members of my team (before joining the Evil Martians team). I’m exaggerating a bit, but seriously, I caught some grief for consistently chasing after them in search of content.

I heard so many variations “I have no time for that” or “imposter syndrome” before I realized the true reason for the roadblock: I was treating the developers like corporate writers, as if they were a part of our marketing teams. Perhaps that’s what big corporations do, but it wasn’t working for us.

There was this notion from a lot of these companies that the responsibility of the developers themselves to generate content. They were wrong, and I was wrong. Startups need a completely different approach.

The mistakes that teams make with “content”

Stop building “content teams”! Instead, build a culture around creation.

Easier said than done, right? The issue is that startup founders usually don’t know how to sell their engineers on this idea, and certainly not enough to get a constant flow of material.

So, how can we make sure that developers understand why this is important?

Or perhaps, more importantly, why they themselves need it? And how to get them to initiate the writing on their own?

The typical mistake is using the approach that enterprise-level companies do: they build content teams and pay for content with swag, gadgets, money, prizes, or parties.

Yes, we’ve also gone down that unfortunate road. But these kinds of rewards (like swag and prizes) hardly motivate developers. Sometimes, it even works the other way around! Like, “I spent 20 hours writing a blog post and all I got this lousy T-shirt?”

Our system

But building this culture still requires solid sources of motivation, transparency, and support systems. So, without further ado, here are things that we’ve had success with at Evil Martians.

First and foremost, it’s important to explain to your engineers why they should put any effort into writing. And indeed, there are many reasons for developers: pumping up their skills, expanding career opportunities, sharing their ideas and knowledge within the community at large.

As we are an international team, we should also emphasize that this can have other practical purposes: publishing articles (or giving talks) can serve as proof when applying for a Global Talent visa or work permits.

To that end, we have meetings, internal webinars, and clarifying posts on these, as well as the points below.

#1: Recognition

Don’t underestimate the power of author recognition in the community. We put a lot of effort into sharing our new content with the community. You can too! Send it to relevant newsletters, podcasts, experts, subreddits, and share it with clients or potential clients.

Seeing your article picked up by a well-known newsletter or reposted or commented upon by a renowned expert feels great. This success is also contagious, and can quickly spread throughout the team.

#2: Bonuses

Even though I just mentioned that direct rewards like 1 article = $100 or 1 T-shirt don’t work. We’ve still added the “content generation” component to our corporate programs. Articles, talks, and podcast participation matter for those programs.

Also, these matters play a role in promotions. We have grades, and content generation can influence the promotion from one grade to another (of course, they are not intensely critical factors, but still.)

#3: Allocated time for writing

Rather than relegating our engineers’ writing periods solely to their free time, let it be so that they can credit it as part of their work schedules.

#4: Coaching

“I don’t know how to start.”
“I’m afraid of negative feedback.”
“I’m afraid of no feedback.”
“I’m a procrastinator.”
I’ve never written anything, and I don’t know how.”

Help your engineers solve problems with writer’s block or anything else preventing them from jumping in. Invest some time and money into coaching on how to overcome the main blockers. This might include helpful webinars, courses, consultations, or books.

#5: Editorial staff

Hire an editor! This will significantly improve the quality of texts and make the entire process of creating content much less painful. Hire a freelance editor if you cannot a full-time team member.

#6: Transparency

We also share information on the articles that were lead generating and how much revenue we gain from these projects. When one or multiple team members can see the real impact of their work in hard numbers, that can make people feel really good about their work.

If you cannot make your finances so transparent, you can at least share the percentage of your revenue that was influenced by your team’s content.

Does it work?

So, is all this worth it? It sure has been for us! Let’s look at our results. Here’s how the number of articles on our blog and the number of authors have grown over the years:

For example, in 2023, we published 44 blog posts. Six of those brought us over $700K of revenue—and all of those were written by developers. (It’s also worth noting that 9 authors published their articles for the first time ever during that year!)

Starting a content flow

So, what’s next?

Let’s imagine you’re starting from zero: and with no marketing people to help create a system of content generation. And we’re not talking about an ad-hoc approach or just a couple of publications, but a constant flow.

My suggestion is to kick things off with a meeting. Include your engineers and explain your plan, keeping in mind the content above.

Every organization is different, and so are the people inside of them. So, ask what they need to start writing, brainstorm ideas and the topics you want to talk about, suggest some perks, and maybe create a rough content plan that will highlight the topics you want to emphasize.

With all that said, don’t expect that all your developers will suddenly begin to write. But you can be confident that you just might get fewer “miss me with your marketing BS” remarks.