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
> 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.
I feel like this glosses over the fundamental question. You've just written a 500 word comment about your company's business; it's grammatical, well-formatted, communicates both overall scope and low level details, even has an introduction and conclusion. But I'm sure your team didn't spend 25/3 ~= 8 hours on it, and I'm pretty confident you skipped the majority of the listed steps. Why does scaling up by a factor of 3 require such a huge paradigm shift?
Good points all around! For the record, if you (or someone on your team) can write great posts quickly solo, that's awesome and I'd never dissuade it. But a lot needs to go right for that to be possible. For an individual to pull it off, IMO you need to meet these criteria:
- You yourself are doing something technically interesting
- You know enough about the project and/or topic to write on behalf of your team members and company. (Because posts on company blogs are perceived to represent everyone.)
- You need to be a competent writer. Sub-skills matter, too: editing, proofreading, creating visuals, and more. This simply takes practice, especially if you expect to move fast.
- It helps if you're a native english speaker, which many engineers are not.
- If you're truly doing it all yourself, you need to know your way around whatever CMS your company uses. Most engineers don't.
- You need to know enough to anticipate the repercussions. Love them or hate them, this is what Legal/PR/Comms are for.
If all this is true, yes, an individual can write a great post in a single day.
To answer your question directly, I was able to write my main comment quickly because:
- I was responding to something. I wasn't writing from scratch. Hot takes are easy ;)
- I'm a cofounder. AKA: I'm comfortable writing on behalf of my company. It's actually part of my job.
- HN comments are lower stakes than a blog post. No long-term SEO impact, for example.
- I've been doing this for 10+ years. And my 500 word comment still took me 90 min to write and edit.
- Yup, I'm a native english speaker.
- Probably some other factors I'm blind to at this point.
It typically takes me 2-3 hours for a well written ~1500 word post. These posts get 3k / mth organic views and many subscribers to my email list, so I know they perform well.
Spending an order of magnitude more time on each post seems ridiculous to me.
Ack, unfortunately not publicly. Confidentiality agreements :/ We are permitted to share work privately though. Feel free to email me: jackson@jobportraits.com
- 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...