How to reliably get your team to write articles for your engineering blog

You probably already know why it's so helpful to have your team write engineering articles:

  1. They're massively useful for recruiting, even if only a few people read them
  2. If many people read your articles, you'll get tons more applicants
  3. If you sell to developers, your articles create trust and lead to more sales, on top of the above

How do you get an engineer to write an article?

You don't. Instead you ask them over email:

"How does X work?"

This tip is from Melinda Jacobs, CEO of Lucent Sky. Her company automatically finds vulnerabilities in your code and fixes many of them (which is great for banks who have so many vulnerabilities that their security teams can't possibly fix them all manually :). Thanks Melinda!

Now, ask an engineer on your team and you'll get a detailed explanation of how some part of your product works. If you know they left out something impressive, ask again after their initial answer:

"I was really impressed with your work on Y, can you explain how that works too?"

Then you take their answers, edit them with these tips, run it by them to see if they have any suggestions, and publish. If you're an engineer like me, I'd recommend you don't let them make the edits themselves–they may get hung up on them. Instead ask them for feedback over email or in a quick read-through and make the changes for them.

It's up to you to make remember to ask your team to write articles after they finish interesting projects. Remember, to an outsider, boring projects can be just as interesting because they demonstrate mature, boring technology. Projects with large business impact are also very interesting, especially to engineers who care about business results.

Take a minute right now to add a link to this article in your sprint retrospectives (or planning cycle retrospectives). Otherwise you may forget to put this advice into practice.

A published article is worth more than 1,000 unpublished articles

Work on the article until you're 80% happy with it, then publish it. If you're being ruthless with yourself, one hour total invested in the article is a reasonable timeline. If you have extreme difficulty with a particular sentence, the easiest way to fix it is to delete it :).

Why does Melinda's method work well?

That's it, good luck!

PS Do you have an engineering hiring tip you'd like me write up? Email me: david att dtrejo dot com.

† Boring Technology, for example Choose Boring Technology (slides) by Dan McKinley, Founder at Skyliner; "The boring tech revolution is here" by Reddit CTO Marty Weiner; Non-fancy Node by Yoshua Wuyts, author of 372 node modules.

David Trejo

Engineer at Chime & consultant. Past clients include Credit Karma, Aconex, Triplebyte, Neo, the Brown Computer Science Department, Voxer, Cloudera, and the Veteran's Benefits Administration.