Dan Luu: Как пишутся (некоторые) хорошие корпоративные инженерные блоги

Я сравнивал свои заметки с людьми, которые ведут корпоративные инженерные блоги, и мне кажется любопытным то, что мой личный блог довольно часто получает больше трафика, чем весь корпоративный блог компании, которая оценивающейся в девяти/десятизначную сумму и мой блог нередко получает на порядок больше трафика.

Я думаю, что это странно, потому что в технологических компаниях этого класса часто работают сотни и даже тысячи сотрудников. В подавляющем большинстве случаев они будут лучше подготовлены для написания привлекательного блога, чем я, и компании получают гораздо большую ценность от наличия привлекательного блога, чем я.

Что касается первого, сотрудники компании будут выполнять более интересную инженерную работу, рассказывать больше забавных историй и обладать более глубокими знаниями, чем любой человек, ведущий личный блог. Во втором случае мой блог помогает мне в поиске работы и помогает компаниям нанимать меня. Но мне нужна только одна работа, так что большее влияние блога в том, что в лучшем случае он дает мне немного лучшую работу, тогда как все, кроме одной технологической компании, в которой я работал, отчаянно пытаются нанять кого-то и все время теряют кандидатов в пользу других компаний. Более того, я на самом деле не конкурирую с другими кандидатами на собеседовании (даже если мы собеседуемся на одну и ту же работу, если компании нравится больше, чем один кандидат, она обычно просто создает больше рабочих мест). Важнейший момент в этом блоге в отношении поиска работы заключается в том, сможет ли процесс отбора принять значительную обратную связь, не связанную с собеседованием, или если я провалю собеседование, потому что они проводят обычное собеседование, и предельная ценность дополнительной публикации в блоге, вероятно очень низка по отношению к этому. С другой стороны, при найме на работу компании конкурируют относительно напрямую, так что быть более привлекательными по сравнению с другой компанией крайне важно для них. Повторение Playbook, который Cloudflare или Segment использовали для своих инженерных «брэндов», будет значительным преимуществом при найме на работу. Playbook не является секретом: эти компании транслируют свою продукцию по всему миру и, как правило, с удовольствием рассказывают о своих процессах ведения блога.

Несмотря на кажущиеся очевидными преимущества «хорошего» корпоративного блога на английском языке, большинство корпоративных блогов полны материалов, которые инженеры не хотят читать. Расплывчатая, высокоуровневая болтовня о том, как все прекрасно, контент-маркетинг, натянутые посты о новеньких горячих штучках (сегодня это могло быть использование глубокого обучения для неподходящих приложений; десять лет назад это могло быть использование «big data» для неподходящие приложения) и т. д.

Чтобы попытаться понять, что общего у компаний с хорошим корпоративным инженерным блогом, я опросил людей из трех разных компаний, у которых интересные корпоративные инженерные блоги (Cloudflare, Heap и Segment), а также людей из трех разных компаний, у которых посредственные корпоративные инженерные блоги (которые я не буду называть).

На высоком уровне в интересных инженерных блогах происходили процессы, которые обладали следующими свойствами:

• Простой процесс одобрения, не требуется много одобрений
• Не требуется никаких одобрений, не относящихся к инженерным, или совсем не требуется
• Неявный или явно быстрый SLO для одобрений
• Процесс одобрения/редактирования в основном делает пост более привлекательными для инженеров
• Прямая поддержка высокого уровня (сооснователь, C-level или VP-level) для облегчения процесса ведения блога

В менее привлекательных технических блогах происходили процессы, которые обладали следующими свойствами:

• Медленный процесс одобрения
• Требуется много одобрений
• Необходимы значительные нетехнические одобрения:
  
  • Неинженерные одобрения предполагают, что изменения, по мнению авторов, разочаровывают
  • Туда-сюда может продолжаться месяцами
• Процесс одобрения/редактирования в основном снижает риски для публикаций, удаляет ссылки на конкретную информацию, делает посты более расплывчатыми и менее интересными для инженеров.
• Фактически нет поддержки высокого уровня для ведения блога
  
  • Руководство может согласиться с тем, что ведение блога — это хорошо в абстрактном смысле, но это недостаточно высокий приоритет, чтобы предпринимать конкретные действия.
  • Очень сложно реформировать процесс ведения блога; предыдущие попытки потерпели неудачу
  • Изменение процесса для сокращения накладных расходов требует, чтобы все «заинтересованные стороны» подписались (14 в одном случае)
    
    • Любая отдельная заинтересованная сторона может заблокировать пост
    • Ни одна заинтересованная сторона не может одобрить пост
  • Заинтересованные стороны опасаются одобрять все, что снижает накладные расходы.
    • Одобрение включает принятие на себя предполагаемого риска (что, если случится что-то плохое) без видимой выгоды для них

Один человек в компании, ведущей интересный блог, заметил, что недостатком наличия только одного одобряющего и/или одного основного одобряющего является то, что если этот человек занят, на одобрения могут уйти недели. Это справедливо, это обратная сторона централизованного одобрения. Однако, когда мы сравниваем с альтернативными процессами, в одной компании люди отметили, что типичный процесс одобрения занимает от трех до шести месяцев, а последующие случаи — год.

В то время как несколько недель могут показаться долгим сроком для тех, кто привык к быстро развивающейся компании, люди в более медленно развивающихся компаниях были бы в восторге от процесса утверждения, который занимает в два раза больше времени.

Вот описанные мне процессы для трех компаний, с которыми я беседовал (представленные в порядке sha512sum, который случайно упорядочен путем увеличения размера компании с пары сотен сотрудников до почти тысячи сотрудников):

Heap

• У кого-то есть идея написать пост
• Писатель (инженер) находится в паре с приятелем, который редактирует, а затем одобряет пост
  
  • Приятель — инженер, имеющий опыт написания разумных текстов
  • Это может занять несколько раундов, может измениться направленность поста
• Технический директор читает и одобряет
  
  • Обычно давая только незначительную обратную связь
  • Может вносить предложения вроде «дизайнер может улучшить этот график».
• Публикация поста

Первый этап редактирования включал в себя публикацию черновика на канале в Slack, где «все» комментировали пост. Это был неприятный опыт, так как «все» писали бы комментарии, и потребовалась бы большая доработка. Этот процесс был разработан, чтобы избежать «слишком большой» обратной связи.

Segment

• У кого-то есть идея написать пост
  
  • Часто исходит из: внутренней документации, внешнего обсуждения, одобренного проекта, инструментов с открытым исходным кодом (созданных Segment).
• Автор (инженер) пишет черновик
  
  • Может быть, с ними будет работать старший инженер, чтобы написать черновик
• До недавнего времени процесс обратной связи никому не принадлежал
  
  • Кальвин Френч-Оуэн (сооснователь) и Рик (технический менеджер) обычно дают больше всего обратной связи<
  • Возможно также получить обратную связь от менеджера и руководства
  • Обычно 3-й черновик считается завершенным
  • Теперь у вас есть штатный редактор, которому принадлежит ответственность за редактирование постов
• Также обсуждение с инженерной командой, чтобы получить обратную связь от 15-20 человек.
• PR и юристы посмотрят посто, простой процесс одобрения

Некоторые внесенные изменения включают

• В какой-то момент, когда осуществлялись попытки создать «инженерный бренд», подробные технические посты получили высокий приоритет
• был «ретрит по ведению блога», уходила одна неделя на написание поста
• добавленные письменная и устная речь в качестве явных критериев, которые будут вознаграждены при рассмотрении производительности и способствовать продвижению по карьерной лестнице

Хотя есть официальное одобрение и одобрение со стороны PR, Кэлвин отметил: «В целом мы стараемся сделать процесс одобрения достаточно легким. Я считаю, что более серьезной проблемой ведения блогов является отсутствие постов или расплывчатый высокоуровневый контент, который не интересен, и не раскрывает слишком много».

Cloudflare

• У кого-то есть идея написать пост
  
  • Внутреннее ведение блога является частью культуры, некоторые посты публикуются из внутреннего блога
• Джон Грэм-Камминг (технический директор) читает каждый пост, другие будут читать и комментировать
  
  • Джон одобряет посты
• Мэтью Принс (генеральный директор) также в целом поддерживает ведение блога.
• «Очень быстрый» юридический процесс одобрения, SLO в течение часа
  
  • Этот процесс настолько легок, что один человек на самом деле не думал об этом как об одобрении, а другой вообще не упоминал это (третий действительно упомянул этот шаг)
  • Комментарии вообще не задействованы

Следует отметить, что это относится только к техническим постам в блогах. Анонс продуктов — более сложный процесс, потому что они привязаны к коммерческим материалам, пресс-релизам и т. д.

Мне показалось интересным то, что Марек собеседовался Cloudflare из-за их блога (его внимание привлекла эта запись в блоге 2013 года на их серверах 4-го поколения), и теперь он является для них ключевым инженером, а также одним из основных источников привлекательных постов блога Cloudflare. На данный момент блог Cloudflare породил по крайней мере еще несколько поколений людей, которые проходили собеседования, потому что они видели пост в блоге и теперь пишут убедительные посты для блога.

Общие комментарии

Я считаю, что естественное состояние корпоративного блога, когда люди могут получить небольшую обратную связь, — это довольно интересный блог. Существует нехватка настоящих, глубоких, технических текстов, что делает интересным любой наполовину достойный, честный, публичный текст о технической работе.

Чтобы блог был скучным, корпорация должна активно мешать инженерам размещать там интересный контент. К сожалению, похоже, что естественное состояние крупных корпораций склонно к избеганию риска и запрету людям писать на всякий случай, если это вызывает юридические, PR или другие проблемы. Individual Cotributors могут придерживаться мнения, что нелепо запрещать инженерам писать технические посты с низким уровнем риска, в то время как руководители высшего звена и вице-президенты регулярно делают публичные комментарии, которые превращаются в PR-катастрофу, но IC в крупных компаниях не имеют полномочий или не чувствуют, что у них есть полномочия что-то делать только потому, что это имеет смысл. И ни одна из четырнадцати заинтересованных сторон, которой пришлось бы подписаться на одобрение оптимизированного процесса, не позаботилась бы об оптимизации процесса, поскольку это было бы хорошо для компании таким образом, чтобы на самом деле не смогло бы не повлиять на них, не тогда, когда это, казалось бы, означало принятие на себя ответственности за риск связанный с оптимизированным процессом, пусть даже с небольшим. Руководитель или старший вице-президент, готовый пойти на риск, могут взять на себя ответственность за последствия, и, если они заинтересованы в найме инженеров или в моральном духе, они могут увидеть причину для этого.

Один комментарий, который я часто слышал от людей из более бюрократических компаний, — это что-то вроде «каждая компания нашего размера такая же», но это неправда. Cloudflare, компания с оборотом в 6 миллиардов долларов, в которой работает 1 тысяча сотрудников, находится в том же классе, что и многие другие компании с гораздо более обременительным процессом ведения блогов. Ситуация в корпоративном блоге кажется похожей на ситуацию с реальным откликом на собеседование. interviewing.io утверждает, что в этом есть существенные положительные и очень незначительные отрицательные стороны. Некоторые компании действительно дают реальную обратную связь, а те, которые, как правило, считают, что это дает им легкое преимущество при найме с небольшими недостатками, но подавляющее большинство компаний этого не делают, и люди в этих компаниях будут утверждать, что дать обратную связь невозможно, так как на вас подадут в суд, или компания будет «аннулирована», хотя обычно этого не происходит с компаниями, которые дают обратную связь, и есть даже целые отрасли, в которых принято давать обратную связь на собеседовании. Легко понять, что определенный риск существует, и очень немногие люди имеют право отвергать расплывчатые сообщения о риске, когда он исходит от нескольких организаций.

Несмотря на то, что это небольшой пример, и опасно делать слишком много обобщений из небольших примеров, идея о том, что вам нужна поддержка высокого уровня, чтобы прорваться через бюрократию, согласуется с тем, что я видел в других областях, где большинству крупных компаний приходится нелегко в процессе создания чего-то легкого, имеющее очевидную, но расплывчатую ценность. Хотя этот пост посвящен ведению блога, я слышал похожие истории по самым разным темам.

Приложение: примеры классных публикаций в блогах

Вот несколько постов из упомянутых блогов с коротким комментарием о том, почему я считаю этот пост достойным. На этот раз в обратном порядке хеширования sha512.

Cloudflare

• blog.cloudflare.com/how-verizon-and-a-bgp-optimizer-knocked-large-parts-of-the-internet-offline-today
  
  • Разговоры о реальной технической проблеме, которая затронула множество людей, достаточно подробно
  • Своевременный, выпущенный всего через восемь часов после сбоя в работе, когда людям все еще было интересно услышать о том, что произошло; большинство компаний не могут так быстро развернуть убедительный пост в блоге или могут сделать это только в особых случаях, Cloudflare может публиковать своевременные сообщения почти регулярно.
• blog.cloudflare.com/the-relative-cost-of-bandwidth-around-the-world
  
  • Исследование некоторых данных
• blog.cloudflare.com/the-story-of-one-latency-spike
  
  • История про отладку
• blog.cloudflare.com/when-bloom-filters-dont-bloom
  
  • История про отладку, на этот раз в контексте разработки структуры данных

Segment

• segment.com/blog/when-aws-autoscale-doesn-t
  
  • Конкретное объяснение проблемы в широко используемом сервисе
• segment.com/blog/gotchas-from-two-years-of-node
  
  • Конкретный пример и объяснение ошибки в широко используемом инструменте
• segment.com/blog/automating-our-infrastructure
  
  • Публикация с конкретными подробностями о том, как работает компания; теоретически это могла бы написать любая компания, но мало кто это делает

Heap

• heap.io/blog/engineering/basic-performance-analysis-saved-us-millions
  
  • Разговор о реальной проблеме и решении
• heap.io/blog/engineering/clocksource-aws-ec2-vdso
  
  • Разговор о реальной проблеме и решении
  • В комментариях HN у инженеров (malisper, kalmar) есть технические ответы с реальными причинами, а не просто обычное лицемерие, которое вы видите в большинстве случаев.
• heap.io/blog/analysis/migrating-to-typescript
  
  • Реальный разговор о том, как первая попытка провести технические изменения в масштабах компании провалилась

Следует отметить, что все эти блоги имеют разные стили. Лично я предпочитаю стиль блога Cloudflare, в котором более высокая доля «глубоких» технических сообщений, но разные люди предпочтут разные стили. Есть много стилей, которые могут cработать.