4 ms·

> One person at a company with a compelling blog noted that a downside of having only one approver and/or one primary approver is that if that person is busy, i

by drob 7y ago

> One person at a company with a compelling blog noted that a downside of having only one approver and/or one primary approver is that if that person is busy, it can takes weeks to get posts approved. Heap CTO here. I'm pretty sure this quote is about me! Or if it's not, it would be equally true about me. This is why we rolled out the "buddy" system described in this post. That way 90% of the iteration can be between the engineer writing the post and someone else who will be a lot more available than I am. This matters a lot if a post requires three or four round trips to really get it right. Plus, in a lot of cases, that other person is better at technical storytelling than I am to begin with. I'd also note that this post and HN discussion focus a lot on reducing friction, as if having a really good blog is the state of nature. In my experience, this has not been true. A good blog won't just happen if you get out of the way. Someone senior at the company needs to actively prioritize the engineering blog. You also need eng leadership that respects that writing posts is real work and is willing to have engineers spend time on-the-job working on them. At Heap, we do this down to the level of taking this into account in sprint planning. Also, a lot of the good ideas for posts come from working with engineers to find the kernel of a story in something they're working on. This is an active process, not something spontaneous that you just have to permit to happen. We also benefit from having a lot of legitimately interesting technical work to talk about. This is more true at some companies than others, and is a big multiplier on how compelling you can make your blog. The success of a blog post is pretty non-linear – either it gets wide readership or not much at all. Having something interesting to talk about is pretty important, and is hard to manufacture.

craigkerstiens 7y ago
Dan, having been that exact same bottleneck it's common for many. And echo everything your said. In terms of getting something out the door as soon as you do that you've diminished the impact of the post. It's similar to quality engineering you ship it when it is ready, not because you said it'd take a week and you spent a week on it. Most engineers hate artificial marketing deadlines, being able to work on a post to get it into a good state can be equally as unclear in terms of timing as engineering. I've found that a dedicated mentoring process, similar to your buddy system can work well. As you're growing the people that are able to review/drive content having them follow along as I review posts and provide feedback helps for them to internalize some of the steps. In my experience after shadowing for about 5 posts they're able to start guide someone else with still some need for support and final reviews. A final note, as someone that has written a lot of content I can crank out a post in anywhere from a day to an hour. For someone that has an interest in a topic you shouldn't expect the same output (time wise) as someone that does this more frequently, a quality blog post for someone not used to the process can spend multiple days up to a week in total on it. This comes down over time and with practice, so you shouldn't assume it's always that high, but it does take repetition. Finally, everyone has interesting technical things to talk about. Anytime an internal email is sent to engineering@ about some interesting tip, how some problem was solved, or a guide to how to accomplish something it's a great candidate for a post.
- drob 7y ago
  :wave: hi Craig! I'll also note that we asked Craig for eng blog advice way back in Jan 2017, and he was very helpful. :)
swyx 7y ago
> A good blog won't just happen if you get out of the way. true, but if you get in the way, you have a lifeless/corporate-feeling blog, which is (subjectively) worse. as someone who has worked in the blogging trenches, i can say that overzealous/overconservative processes can really stifle blogging flow and the primary alternative you're competing against is the engineer writing for their personal blog, which they know has long term career value as well. usually not all participants in the review chain are equally bought in to growing the blog and you eventually get your best writers self selecting out if you aren't careful i do like the buddy system you propose, that seems like a nice solve! what are your thoughts on having dedicated content writers - like technical writers or developer advocates - working on/owning the blog, vs "all engineers are explicitly encouraged to blog"?
- drob 7y ago
  > what are your thoughts on having dedicated content writers - like technical writers or developer advocates - working on/owning the blog, vs "all engineers are explicitly encouraged to blog"? I like this, and I think a good developer relations person who is prolific, sufficiently technical, and can get the tone right can be very valuable for building up a company's visibility. It's a good way to take 80% of the work of writing a post off the relevant engineer's plate and also produce great posts, because the person writing them is a professional writer. We're small enough right now that we can do well enough with some ad hoc stuff, e.g. periodic slack posts to shake the tree. But this is something we discuss every now and then and the timing will be right at some point, as we scale. It's easier to justify the cost of a full-time employee if your buyers are also primarily engineers. For someone like Stripe or Twilio, an active eng blog doubles as marketing.
gowld 7y ago
This concern applies to every process that a CxO inserts themself into. You have 200 employees and only one person you trust to publish communications to the public? Why not put a little trust in your teammates?
- drob 7y ago
  To be clear we're talking about the state of the world around two years ago. I'm not a bottleneck for this anymore. :) Also, this is a bit of an uncharitable read. The calculus at the time wasn't about trust per se, and more about the fact that the relationship between quality of blog content and the content's reach is nonlinear. That means it's worth taking the time to get it right, even if the people best suited to make that happen aren't super available, because the difference between getting on the front page of HN vs not is multiple orders of magnitude. (But I think we get the best of both worlds now.)

by drob 7y ago

craigkerstiens 7y ago

Dan, having been that exact same bottleneck it's common for many. And echo everything your said. In terms of getting something out the door as soon as you do that you've diminished the impact of the post. It's similar to quality engineering you ship it when it is ready, not because you said it'd take a week and you spent a week on it. Most engineers hate artificial marketing deadlines, being able to work on a post to get it into a good state can be equally as unclear in terms of timing as engineering. I've found that a dedicated mentoring process, similar to your buddy system can work well. As you're growing the people that are able to review/drive content having them follow along as I review posts and provide feedback helps for them to internalize some of the steps. In my experience after shadowing for about 5 posts they're able to start guide someone else with still some need for support and final reviews. A final note, as someone that has written a lot of content I can crank out a post in anywhere from a day to an hour. For someone that has an interest in a topic you shouldn't expect the same output (time wise) as someone that does this more frequently, a quality blog post for someone not used to the process can spend multiple days up to a week in total on it. This comes down over time and with practice, so you shouldn't assume it's always that high, but it does take repetition. Finally, everyone has interesting technical things to talk about. Anytime an internal email is sent to engineering@ about some interesting tip, how some problem was solved, or a guide to how to accomplish something it's a great candidate for a post.

drob 7y ago
:wave: hi Craig! I'll also note that we asked Craig for eng blog advice way back in Jan 2017, and he was very helpful. :)

swyx 7y ago

> A good blog won't just happen if you get out of the way. true, but if you get in the way, you have a lifeless/corporate-feeling blog, which is (subjectively) worse. as someone who has worked in the blogging trenches, i can say that overzealous/overconservative processes can really stifle blogging flow and the primary alternative you're competing against is the engineer writing for their personal blog, which they know has long term career value as well. usually not all participants in the review chain are equally bought in to growing the blog and you eventually get your best writers self selecting out if you aren't careful i do like the buddy system you propose, that seems like a nice solve! what are your thoughts on having dedicated content writers - like technical writers or developer advocates - working on/owning the blog, vs "all engineers are explicitly encouraged to blog"?

drob 7y ago
> what are your thoughts on having dedicated content writers - like technical writers or developer advocates - working on/owning the blog, vs "all engineers are explicitly encouraged to blog"? I like this, and I think a good developer relations person who is prolific, sufficiently technical, and can get the tone right can be very valuable for building up a company's visibility. It's a good way to take 80% of the work of writing a post off the relevant engineer's plate and also produce great posts, because the person writing them is a professional writer. We're small enough right now that we can do well enough with some ad hoc stuff, e.g. periodic slack posts to shake the tree. But this is something we discuss every now and then and the timing will be right at some point, as we scale. It's easier to justify the cost of a full-time employee if your buyers are also primarily engineers. For someone like Stripe or Twilio, an active eng blog doubles as marketing.

gowld 7y ago

This concern applies to every process that a CxO inserts themself into. You have 200 employees and only one person you trust to publish communications to the public? Why not put a little trust in your teammates?

drob 7y ago
To be clear we're talking about the state of the world around two years ago. I'm not a bottleneck for this anymore. :) Also, this is a bit of an uncharitable read. The calculus at the time wasn't about trust per se, and more about the fact that the relationship between quality of blog content and the content's reach is nonlinear. That means it's worth taking the time to get it right, even if the people best suited to make that happen aren't super available, because the difference between getting on the front page of HN vs not is multiple orders of magnitude. (But I think we get the best of both worlds now.)