(Editorial note: I originally wrote this post over on the Hit Subscribe blog. I’ll be cross-posting anything I think this audience might find interesting and also started a SubStack to which I’ll syndicate marketing-related content.)
I've been on a listening tour of late, talking to product marketers that own their business's content production, among others. My aim has been to discover subtle pain points, identify patterns, and possibly develop productized services to help.
A couple of weeks ago, I heard something interesting. "We have in-house engineers that want to contribute to the blog, but there are some barriers."
This is exactly the kind of tidbit that I like to dig into, and it exemplifies what I mean about looking for patterns. Hit Subscribe has been around for six years, and we've occasionally, on request, taken on client engineers as if they were in our author pool to help produce content for the company. And, as a long-time blogger before that, I've also observed companies, often app dev consultancies, try to tease a steady content stream out of their engineering groups.
I suppose I could hurriedly try to roll out a productized service and scoop up the opportunity, but that's not really my style. Even if we didn't phase productized service rollouts (alpha, beta, general), I like to run lean. Why roll out some kind of offering when I could just write about it and see if anyone finds this interesting?
So today, I'd like to explore the idea of using internal engineers to create content. Assuming you have folks that are interested in creating content (I wouldn't try to force it), here's a series of steps I'd recommend to establish a successful program.
[caption id="attachment_94331" align="aligncenter" width="750"]
Courtesy of Danial Igdery (https://unsplash.com/@ricaros)[/caption]
First, Some Guiding Principles
Before I get to those, however, I'd like to establish some basic guiding principles about how the program should work. Understanding that these are the things we're after will help you understand the rationale behind the specific tactics I'll describe later in the post.
1. Don't Deputize the Engineers as Marketers
First, don't ask your organization's engineers to be marketers. If they were interested in this, they'd either be marketers themselves, or else maybe dev rels.
If they're interested in contributing to the blog, they most likely have motivations like sharing knowledge, improving their writing, showcasing cool stuff they've done, and building a personal brand. None of those involve preserving brand voice, adding an interstitial call to action, or doing anything they might construe as shilling.
You'll want to let them write the posts they want to write.
2. This Needs to Be Fun for the Engineers
Zooming out a little, the program needs to be fun for them in general. As I mentioned, that means letting them write the content they feel like writing, but it also means establishing a community, sharing spirit in general.
These folks are busy, which means they're quite likely contributing in their spare time and that there are lots of other things they could be doing. At Hit Subscribe, we understand this acutely, since the content creation workforce consists of side hustling engineers.
The second it starts to feel like toil is the second that the program dries up.
3. The Engineers' Work Isn't What You Sell
Unless you're a professional services firm, your engineers' work isn't what you sell. As such, if you try to position this program as "look at us, we're smart, you should give us money," you run the risk of creating performative content. And even if you avoid that attractive nuisance, you risk putting undue pressure on contributors and depressing the impulse to volunteer.
Sticking with the theme of it being fun, I'd suggest thinking of this content not as a marketing vehicle but as a morale-boosting perk for contributors. "Our company has your back and wants to see you succeed and grow your brand."
4. Commit—You Don't Want a Sad, Three-Post Attempt at a Campaign
Finally, the last guiding principle to this is that if you're going to do it, you need to commit to it. There's nothing sadder in the blogging world than someone excitedly starting a blog, publishing seven posts the first month, two the second month, and then one last lone post, six months later. This is the avatar of the failed blog that you throw in the closet beside that guitar you are totally going to learn to play one day and that rock tumbler from your brief interest in rock collecting.
In all seriousness, it's a bad look to have an engineer contributor program that you obviously tried to start and it went nowhere. I'll explain how to avoid this in the tactics, but suffice it to say that you should only launch the program if you're committed to seeding it with significant content.
Building the Program
With principle established, I'll now offer some specific suggestions for building the program.
1. Considering Defining Recruitment as the Program's Goal
One great way to avoid what I described above—deputizing engineers as marketers—is to establish a clearly non-marketing goal for the content. And recruitment is clearly a non-marketing goal.
"Look at how we do things; you should buy from us," is a fairly weak connection to prospective buyers. But "Look at how we do things; you should work with us" is a pretty direct and clear appeal to prospective candidates.
Having a company's engineers write about how they do things can help you attract technologists with philosophically similar outlooks. This in turn can help you economize on recruiting costs and have open reqs close faster, which means potential material savings for the business.
2. Insulate the Content From Your Marketing Content
The next thing I'd consider is to establish a moat around your marketing content, as far as this content is concerned. In other words, I would suggest not just slapping these posts up in your CMS and tagging them as blog posts to go along with your marketing blog posts. Instead, give them a distinct home somewhere.
This could mean having a separate tagging scheme or section of your site, titled "how we work" or similar. But you could also use a venue like dev.to or even establish a subsidiary property for it.
But however you structure it, I'd have a clear and obvious purpose for it, distinct from the rest of the content.
3. Enlist a Copy Editor for the Contributors
The next thing I'd recommend is finding a copy editor that knows how to do at least a little developmental editing. This is not to be confused with someone that has a decent command of English proofreading the authors. I'm talking about someone who will help them polish their writing.
At the most basic level, this editor serves to edit mistakes out of the content. But the real value to this activity is that it helps contributors establish confidence and enjoy contributing to the program. Most people have never had an editor help them polish their writing before.
Since the early days of Hit Subscribe, one of the most common pieces of feedback that we'd hear from contributing authors is that they genuinely enjoyed the experience of working with our editors. Over the years, this has resulted in a number of people going from "unsure if I'm cut out for this blogging thing" to being long-time contributors.
4. Create a Large Pool of Topic Ideas to Seed the Program
If you preside over a blogging program, you'll learn that some folks love ideating about topics, while others face some blank page syndrome. Given that you're trying to nurture an ember into a fire here, you want to make sure you have something for either preference.
With the ideators, you'll be fine. They'll pitch topics to you, and given that they're sharing how they work, I'd recommend being pretty deferential about agreeing to those topics.
But for contributors who might not know what to write about offhand, having a big pool of ideas can be extremely helpful. They might pick up the topics straightaway, or seeing a backlog of ideas might serve as inspiration for them.
5. Establish a Backlog of Five to Ten Posts Before You Start Publishing
I would suggest building a backlog of content before you start actually publishing. The main idea here is to avoid launching with a single piece of content and then having nothing for weeks—the sad blog situation I talked about earlier.
But building up a backlog of a few pieces serves a few other subtle purposes as well. First, it provides a realistic sense of the kind of cadence that you can establish. If it takes you three months to collect five pieces of content, then you're probably looking at a monthly cadence, for instance.
Second, it also gives you a buffer in the beginning as you get the program up to its cruising altitude. As you get going, maintaining cadence becomes easier. But early on, it's better to have a buffer.
6. Facilitate Contributions Through Interviews or Found Content
One problem with the backlog idea that you might call out is that the very first contributor might start to get antsy. If they submit an article to you and you sit on it for three months, that can be discouraging.
The way I'd suggest avoiding this is to be as active as you can in facilitating content. Now this is written for an audience of marketers, so you're probably not going to fire up a REPL and start writing code. But there are other things you can do.
Engineers in an organization do a lot of communicating via emails and chat, but they also do so through flavors of memo, documentation, release notes, etc. They are routinely producing at least the seed of interesting content, so see what you can track down that you might help massage into a blog post.
Alternatively, you can go journalist mode and interview them. It might seem like cheating to have interview pieces on the engineering blog, but I'd argue it's worth it to keep things moving.
7. Create (And Gently Enforce) an Editorial Calendar
You're asking the engineers to create content, and they're quite likely doing it in their spare time unless some company-wide edict exists for them to help. At best, they might have approval to spend a few hours doing it, but it is certainly not a priority.
So you might think the natural way to approach this would be with infinite deadline slack. But I actually wouldn't go this route.
Instead, I'd suggest letting the due dates of the content be flexible but that contributors treat their commitments as commitments. In other words, explain to them that if they commit to having a draft by the end of next week, it'll throw their editor and anyone else facilitating the content for a bit of a loop.
There's obviously no organizational authority here, nor is there much leverage. But I think you'd be surprised how often articulating that a process depends on someone motivates them to be on time.
8. Help Contributors Build Their Personal Brands
The engineers contributing to the program are inevitably going to have more in mind than just the company. Perhaps they see a future career in dev rel, but maybe they just like the idea of building a brand and some notoriety.
Whatever their motivation, help them with it.
Having the editor will serve this purpose, but marketers can also teach them a thing or two about content distribution and promotion. You can also put the weight of your business's marketing apparatus behind their contributions.
This will serve to make their contributions truly a mutually beneficial arrangement, which will go a long way towards facilitating contributions.
Go For It—It's Worth a Shot
So that's the relatively short version of how I'd recommend setting up a program like this. You'll of course want to create an editorial calendar and figure out what kind of drafting and collaboration paradigms to use. But I didn't really feel like that was especially important to cover here.
I think the more important aspects of the program are the incentives and rules of engagement.
And I also think this sort of thing is an underused tactic for companies in tech. So my suggestion would be to give it a shot. Talk to the engineers, try to generate some buzz, and give it a go.
Top comments (2)
Wow, lots of good stuff in here. Thanks for sharing!
Thanks for the kind words!