Dan Luu: How (some) good corporate engineering blogs are written

image




I compared my notes to people who have corporate engineering blogs, and it seems to me curious that my personal blog quite often gets more traffic than the entire corporate blog of a company that is estimated at nine / ten figures and my blog often gets an order of magnitude more. traffic.



I think this is strange, because technology companies of this class often employ hundreds or even thousands of employees. In the vast majority of cases, they will be better equipped to write an engaging blog than I am, and companies get far more value from having an engaging blog than I am.



For the first, the company's employees will do more interesting engineering work, tell more funny stories, and have deeper knowledge than anyone with a personal blog. In the second case, my blog helps me in my job search and helps companies hire me. But I only need one job, so the bigger impact of the blog is that it gives me a slightly better job at best, whereas everyone but one tech company I worked for is desperate to hire someone and all the time lose candidates in favor of other companies. What's more, I'm not really competing with other candidates in interviews (even if we're interviewing for the same job, if a company likes more than one candidate, it usually just creates more jobs). The crucial point in this blog post regarding job search is whether the selection process can accept significant non-interview feedback or if I fail the interview because they are doing a regular interview and the marginal value of an additional blog post is probably very low relative to that. On the other hand, when hiring, companies compete relatively directly, so being more attractive than another company is extremely important to them. Duplicating the Playbook that Cloudflare or Segment used for their engineering "brands" would be a significant hiring advantage. Playbooks are no secret: These companies broadcast their products all over the world and are generally happy to talk about their blogging processes.



Despite the seemingly obvious benefits of a “good” corporate blog in English, most corporate blogs are full of material that engineers don't want to read. Vague, high-level chatter about how great everything is, content marketing, stretched posts about hot new things (today it could be using deep learning for inappropriate applications; ten years ago it could be using big data for an inappropriate application), etc. .d.



To try to understand what companies with a good corporate engineering blog have in common, I interviewed people from three different companies who have interesting corporate engineering blogs (Cloudflare, Heap, and Segment), as well as people from three different companies who have mediocre corporate engineering blogs. (which I will not name).



At a high level, in interesting engineering blogs, processes took place that had the following properties:



  • Simple approval process, not many approvals required
  • No or no non-engineering approvals required
  • Implicit or Explicitly Fast SLO for Approvals
  • The approval / editing process basically makes the post more attractive to engineers
  • Direct high-level support (co-founder, C-level or VP-level) to facilitate the blogging process


In the less attractive tech blogs, there were processes that had the following properties:



  • Slow approval process
  • Lots of approvals required
  • Significant non-technical approvals required:

    • Non-engineering endorsements suggest changes are disappointing according to the authors
    • Back and forth can last for months
  • The approval / revision process basically reduces the risks for posts, removes links to specific information, makes posts more vague and less engaging for engineers.
  • Virtually no high-level support for blogging



    • Management may agree that blogging is good in an abstract sense, but not a high priority enough to take concrete action.
    • ;
    • , « » (14 )

    • , .
      • (, - )


One person at a company with an interesting blog noticed that the downside of having only one approver and / or one main approver is that if that person is busy, it can take weeks for approvals. This is true, this is the flip side of centralized approval. However, when we compare with alternative processes, people at one company noted that the typical approval process takes three to six months, and the subsequent cases take a year.



While a few weeks may seem like a long time for someone accustomed to a fast-growing company, people in slower-growing companies would love the approval process, which takes twice as long.



Here are the processes I described for the three companies I interviewed (presented in the order sha512sum, which is randomly ordered by increasing the size of the company from a couple of hundred employees to almost a thousand employees):



Heap



  • Someone has an idea to write a post
  • The writer (engineer) is paired with a buddy who edits and then approves the post

    • Buddy is an engineer with experience in writing sensible texts
    • This may take several rounds or the focus of the post may change.
  • CTO reads and approves

    • Usually giving only minor feedback
    • Can make suggestions like "the designer can improve this schedule."
  • Publishing a post


The first stage of editing involved posting the draft to the Slack channel, where “everyone” commented on the post. It was a frustrating experience as “everyone” would write comments and it would take a lot of work. This process was designed to avoid “too much” feedback.



Segment



  • Someone has an idea to write a post

    • Often comes from: internal documentation, external discussion, approved project, open source tools (created by Segment).
  • The author (engineer) writes a draft

    • Maybe a senior engineer will work with them to write a draft
  • Until recently, the feedback process was not owned by anyone.

    • Calvin French-Owen (co-founder) and Rick (technical manager) usually give the most feedback <
    • It is also possible to get feedback from the manager and management
    • Usually the 3rd draft is considered complete
    • You now have an in-house editor who is responsible for editing posts.
  • Also discussion with the engineering team to get feedback from 15-20 people.
  • PR and lawyers just take a look, simple approval process


Some of the changes we made include



  • At some point when there were attempts to create an "engineering brand", detailed technical posts were given high priority.
  • there was a "blogging retreat", it took one week to write a post
  • added written and spoken language as explicit criteria that will be rewarded when considering performance and promote career advancement


While there is official endorsement and approval from PR, Calvin commented, “Overall, we try to make the endorsement process fairly easy. I think the bigger problem with blogging is the lack of posts or vague high-level content that is not interesting and doesn't reveal too much. "



Cloudflare



  • Someone has an idea to write a post

    • Internal blogging is part of the culture, some posts are published from the internal blog
  • John Graham-Cumming (CTO) reads each post, others will read and comment

    • John approves of the posts
  • Matthew Prince (CEO) also generally supports blogging.
  • "Very fast" legal approval process, SLO within an hour

    • , , ( )


It should be noted that this only applies to technical blog posts. Product announcements are more complicated because they are tied to commercials, press releases, etc.



I found it interesting that Marek interviewed Cloudflare because of their blog ( his attention was drawn to this 2013 blog post on their servers 4th generation ), and he is now a key engineer for them, as well as one of the main sources of attractive Cloudflare blog posts. So far, the Cloudflare blog has spawned at least a few more generations of people who interviewed because they saw a blog post and are now writing compelling blog posts.



General comments



I find the natural state of a corporate blog where people can get a little feedback is a pretty interesting blog. There is a dearth of real, deep, technical writing that makes any half-decent, honest, public text about technical work interesting.



For a blog to be boring, a corporation must actively prevent engineers from posting interesting content there. Unfortunately, it seems that the natural state of large corporations tends to be risk averse and prevent people from writing just in case it causes legal, PR or other problems. Individual Cotributors may be of the opinion that it is ridiculous to prohibit engineers from writing low-risk technical posts, while senior executives and VPs regularly make public comments that turn into a PR disaster, but ICs in large companies have no mandate or don't feel like they have the authority to do something just because it makes sense. And none of the fourteen stakeholders who would have to sign up to endorse the streamlined processwould not have bothered to optimize the process, as it would be good for the company in a way that in fact could not help but influence them, not when it would seem to mean taking responsibility for the risk associated with the optimized process, even with a little. An executive or senior vice president who is willing to take risks can take responsibility for the consequences, and if they are interested in hiring engineers or in morale, they can see a reason for doing so.willing to take risks, can take responsibility for the consequences, and if they are interested in hiring engineers or in morale, they can see a reason for it.willing to take risks can take responsibility for the consequences, and if they are interested in hiring engineers or in morale, they can see a reason for it.



One comment I've often heard from people in more bureaucratic companies is "every company our size is the same," but that's not true. Cloudflare, a $ 6 billion company with 1,000 employees, is in the same class as many other companies with a much more cumbersome blogging process. The corporate blog situation seems to be like a real-life interview response. interviewing.io claims there are significant positives and very minor negative aspects to this.... Some companies do give real feedback, and those that tend to think it gives them an easy hiring advantage with little downsides, but the vast majority of companies don't, and people in those companies will claim to give feedback. impossible, as you will be sued or the company will be "canceled", although this usually does not happen with companies that give feedback, and there are even entire industries in which it is customary to give feedback in interviews. It is easy to understand that there is a certain risk, and very few people have the right to reject vague messages about risk when it comes from multiple organizations.



While this is a small example and it's dangerous to generalize too much from small examples, the idea that you need high-level support to break through the bureaucracy is consistent with what I've seen in other areas where most large companies having a hard time creating something light that has obvious but vague value. While this post is all about blogging, I've heard similar stories on a wide variety of topics.



Appendix: Examples of Cool Blog Posts



Here are some posts from the blogs mentioned with a short comment on why I find this post worthy. This time in reverse order of sha512 hashing.



Cloudflare





Segment





Heap





It should be noted that all of these blogs have different styles. Personally, I prefer the Cloudflare blog style, which has a higher proportion of "deep" technical posts, but different people will prefer different styles. There are many styles that can work.



All Articles