My company [1] writes technical blog posts as a service [2]. We mostly work with Bay Area startups. Some key observations and learnings:

- Many companies have tried to create engineering blogs, but you'd never know because the first post was so unpleasant to create that the whole effort got called off.

- If a company does manage to publish a first post, the experience is often so personally traumatic to the engineer that they never try again and/or tell their team members to avoid the process. This is especially true when PR/Comms insists on reviewing posts. (Legal review typically goes more smoothly.)

- Coming up with ideas for posts is WAY easier said than done. Nobody, engineers included, likes staring at a blank page. A significant part of our work is refining ideas and creating outlines.

- Lest you thought otherwise, company engineering blogs are almost always justified as candidate lead gen. Posts are frequently used by recruiters in outreach emails. When a post and email are well written, response rates can easily double—effectively doubling the candidate pool for a growing team. (This assumes that engineers aren't applying to jobs unprompted, which is true for about 80% of startups in the Bay Area.)

- In our research with job seekers, we found that when senior engineers research a company, they seek the company's engineering blog before they seek the careers page, let alone a job description. This is probably obvious to folks here, but in the recruiting world this blows everyone's mind.

- Technical blog posts are expensive whether you DIY or work with someone like us. A detailed post, let's say 1500 words, can easily consume 25 hours of time from everyone involved. 50 hours isn't rare. And this is when the process works well. (Our value prop: we shift time from engineers to our writers.) Here's the process we've found works best. Everything here happens in Google Docs.

1. One of our writers, all former journalists, sits down with an engineer who has an idea for a post. In a 1 hour conversation, they work together to refine the idea and create a bare-bones outline. Assuming you're doing this yourself, my point is that pairing is helpful. This conversation gets recorded and transcribed by a transcription service. (4 hours total time)

2. The writer reviews the transcript and fleshes out an outline. They note locations for graphics and code snippets. The engineer then reviews the outline and leaves comments. (4–6 hours total time)

3. The writer creates a complete first draft, with assistance from 1–2 editors on our team. They leave space for graphics/code for the engineer to add on their own. (8–10 hours)

4. The engineer brings in 1–3 other engineers to review the post. The team adds illustrations and/or code. More comments/feedback. (6+ hours)

5. Our writer incorporates feedback. An editor on our team proofreads the post for clarity, grammar, etc. (2–4 hours)

6. Legal and/or team leaders review the post. (2+ hours)

7. Whomever runs the blog puts everything in the CMS and hits publish. (1 hour)

End of the day, we've ideally consumed fewer than 10 engineer hours. The rest is on us—anywhere from 15–30 hours.

Feel free to email me directly about any of this :) jackson@jobportraits.com

[1] https://www.jobportraits.com/,
[2] https://www.jobportraits.com/services/tech-blog-post-subscri...