Clever Geek Handbook

Dan Luu :(いくつかの）優れた企業エンジニアリングブログはどのように書かれていますか

画像




私は自分のメモを企業エンジニアリングブログを運営している人々と比較しましたが、私の個人ブログは、企業の企業ブログ全体の9/10桁よりも多くのトラフィックを獲得し 、私のブログは頻繁にトラフィックを獲得して いるようです。桁違いにトラフィック。



このクラスのテクノロジー企業は、数百人、場合によっては数千人の従業員を雇用していることが多いため、これは奇妙だと思います。ほとんどの場合、彼らは私よりも魅力的なブログを書くための準備が整っており、企業は私よりも魅力的なブログを持つことではるかに多くの価値を得ることができます。



まず、会社の従業員は、個人的なブログを持っている誰よりも、より興味深いエンジニアリング作業を行い、より面白い話をし、より深い知識を持っています。 2番目のケースでは、私のブログは私の就職活動に役立ち、企業が私を雇うのに役立ちます。しかし、私は1つの仕事しか必要としないので、ブログの大きな影響は、せいぜいわずかに良い仕事を私に与えることです。企業。さらに、私は面接で他の候補者と実際に競争することはありません（同じ仕事で面接している場合でも、会社が複数の候補者を好む場合、通常はより多くの仕事を生み出すだけです）。就職活動に関するこのブログ投稿の重要なポイントは、選択プロセスが面接以外の重要なフィードバックを受け入れることができるかどうかです。 彼らが定期的なインタビューを行っているためにインタビューに失敗し、追加のブログ投稿の限界値がおそらくそれに比べて非常に低い場合。一方、採用の際には、企業は比較的直接競争するため、他社よりも魅力的であることが非常に重要です。 CloudflareまたはSegmentがエンジニアリングの「ブランド」に使用したPlaybookを複製することは、採用上の大きな利点になります。プレイブックは秘密ではありません。これらの企業は自社の製品を世界中に放送しており、一般的にブログのプロセスについて喜んで話しています。



英語の「良い」企業ブログの明らかな利点にもかかわらず、ほとんどの企業ブログはエンジニアが読みたくない資料でいっぱいです。すべてがどれほど素晴らしいかについての漠然とした高レベルのおしゃべり、コンテンツマーケティング、最新の最新情報に関する投稿の拡大（今日では、不適切なアプリケーションにディープラーニングを使用している可能性があります。10年前は、不適切なアプリケーションにビッグデータを使用している可能性があります）など。 .d。



優れた企業エンジニアリングブログを持つ企業の共通点を理解するために、興味深い企業エンジニアリングブログ（Cloudflare、Heap、Segment）を持つ3つの異なる企業の人々と、平凡な企業を持つ3つの異なる企業の人々にインタビューしました。エンジニアリングブログ（名前は付けません）。



大まかに言えば、興味深いエンジニアリングブログでは、次の特性を持つプロセスが発生しました。



  • 簡単な承認プロセス、多くの承認は必要ありません
  • エンジニアリング以外の承認は必要ありません
  • 承認のための暗黙的または明示的に高速なSLO
  • 承認/編集プロセスは基本的に、投稿をエンジニアにとってより魅力的なものにします
  • ブログプロセスを促進するための直接的な高レベルのサポート（共同創設者、経営幹部または副社長レベル）


あまり魅力的でない技術ブログには、次の特性を持つプロセスがありました。



  • 承認プロセスが遅い
  • たくさんの承認が必要です
  • 重要な非技術的承認が必要です：

    • エンジニアリング以外の承認は、変更が著者の意見に失望していることを示唆しています
    • 前後に数ヶ月続くことがあります
  • 承認/改訂プロセスは、基本的に投稿へのリスクを軽減し、特定の情報へのリンクを削除し、投稿をより曖昧にし、エンジニアの関心を低下させます。
  • ブログの高レベルのサポートは事実上ありません



    • 経営陣は、ブログは抽象的な意味では良いが、具体的な行動を取るのに十分な優先度ではないことに同意するかもしれません。
    • ;
    • , « » (14 )

    • , .
      • (, - )


興味深いブログを持っている会社のある人は、承認者が1人、または主要な承認者が1人だけの欠点は、その人が忙しい場合、承認に数週間かかる可能性があることに気づきました。これは真実です。これは一元化された承認の裏返しです。ただし、別のプロセスと比較すると、ある会社の人々は、通常の承認プロセスには3〜6か月かかり、その後のケースには1年かかると述べています。



急成長している会社に慣れている人にとっては数週間は長い時間のように思えるかもしれませんが、成長の遅い会社の人々は、2倍の時間がかかる承認プロセスを望んでいます。



インタビューした3社について説明したプロセスは次のとおりです（sha512sumの順序で表示されます。これは、会社の規模を数百人の従業員からほぼ1,000人の従業員に増やすことによってランダムに順序付けられます）。



ヒープ



  • 誰かが投稿を書くアイデアを持っています
  • ライター（エンジニア）は、投稿を編集して承認するバディとペアになっています

    • バディは賢明なテキストを書いた経験のあるエンジニアです
    • これには数ラウンドかかる場合や、投稿の焦点が変わる場合があります。
  • CTOは読み取りと承認

    • 通常、マイナーなフィードバックのみを提供します
    • 「設計者はこのスケジュールを改善できる」などの提案を行うことができます。
  • 投稿を公開する


編集の最初の段階では、ドラフトをSlackチャネルに投稿し、「全員」が投稿にコメントしました。「みんな」がコメントを書いて、大変な手間がかかるので、イライラする経験でした。このプロセスは、「多すぎる」フィードバックを回避するように設計されています。



セグメント



  • 誰かが投稿を書くアイデアを持っています

    • 多くの場合、内部ドキュメント、外部ディスカッション、承認されたプロジェクト、オープンソースツール（Segmentによって作成されたもの）から来ています。
  • 著者（エンジニア）がドラフトを書く

    • たぶん、上級エンジニアが彼らと協力してドラフトを書くでしょう
  • 最近まで、フィードバックプロセスは誰も所有していませんでした。

    • Calvin French-Owen（共同創設者）とRick（テクニカルマネージャー）は通常、最も多くのフィードバックを提供します<
    • マネージャーや経営陣からフィードバックをもらうことも可能です
    • 通常、3番目のドラフトは完了したと見なされます
    • これで、投稿の編集を担当する社内編集者ができました。
  • また、エンジニアリングチームと話し合って、15〜20人からフィードバックを得ます。
  • PRと弁護士は、簡単な承認プロセスを見てください。


私たちが行った変更のいくつかは次のとおりです



  • 「エンジニアリングブランド」を作ろうとしたある時点で、詳細な技術記事が優先されました。
  • 「ブログのリトリート」があり、投稿を書くのに1週間かかりました
  • パフォーマンスを検討し、キャリアアップを促進するときに報われる明確な基準として、ライティングとスピーキングを追加しました


PRからの公式の承認と承認がありますが、Calvinは次のようにコメントしています。ブログの大きな問題は、投稿がないことや、面白くなく、あまり明らかにされていない漠然とした高レベルのコンテンツであると思います。」



Cloudflare



  • 誰かが投稿を書くアイデアを持っています

    • 内部ブログは文化の一部であり、一部の投稿は内部ブログから公開されています
  • John Graham-Cumming（CTO）が各投稿を読み、他の人が読んでコメントします

    • ジョンは投稿を承認します
  • マシュープリンス（CEO）も一般的にブログをサポートしています。
  • 「非常に高速な」法的承認プロセス、1時間以内のSLO

    • , , ( )


これは技術的なブログ投稿にのみ適用されることに注意してください。製品の発表は、コマーシャルやプレスリリースなど



に関連しているため、より複雑です。 マレクがブログのためにCloudflareにインタビューしたのは興味深いことでした（ 彼の注目は、サーバーの第4世代に関するこの2013年のブログ投稿に向けられました）。彼らの主要なエンジニアであり、魅力的なCloudflareブログ投稿の主な情報源の1つです。これまでのところ、Cloudflareブログは、ブログ投稿を見て説得力のあるブログ投稿を書いているためにインタビューした人々の少なくとも数世代を生み出しました。



一般的なコメント



人々が少しのフィードバックを得ることができる企業ブログの自然な状態は、かなり興味深いブログだと思います 。技術的な仕事についての半ばまともな、正直な、公開テキストを面白くする、本物の、深く、技術的な執筆の不足があり ます。



ブログが退屈であるためには、企業はエンジニアがそこに興味深いコンテンツを投稿することを積極的に阻止しなければなりません。残念ながら、大企業の自然状態はリスク回避的であり、法律、PR、またはその他の問題を引き起こした場合に備えて人々が書くことを妨げる傾向があるようです。個々の寄稿者は、エンジニアがリスクの低い技術的な投稿を書くことを禁止するのはばかげていると思うかもしれません。一方、上級管理職やVPは定期的にパブリックコメントを行い、PR災害になりますが、大企業のICには義務がないか、それが理にかなっているという理由だけで彼らが何かをする権限を持っているように感じます。そして、合理化されたプロセスを承認するためにサインアップする必要がある14の利害関係者の誰もたとえそれが最適化されたプロセスに関連するリスクの責任を取ることを意味すると思われるときではなく、実際には彼らに影響を与えずにはいられない方法で会社にとって良いので、プロセスを最適化することを気にしなかったでしょう。少し。リスクを冒すことをいとわないリーダーまたは上級副社長は、結果に対して責任を負うことができ、エンジニアの採用や士気に関心がある場合は、その理由を知ることができます。リスクを冒すことをいとわないことは結果に対して責任を負うことができ、エンジニアの雇用や士気に興味がある場合は、その理由を知ることができます。リスクを冒すことをいとわないことは結果に対して責任を負うことができ、エンジニアの雇用や士気に興味がある場合は、その理由を知ることができます。



より官僚的な企業の人々からよく耳にするコメントの1つは、「私たちの規模はすべての企業で同じです」というものですが、そうではありません。従業員1,000人の60億ドルの企業であるCloudflareは、ブログのプロセスがはるかに面倒な他の多くの企業と同じクラスです。企業のブログの状況は、実際のインタビューの回答のようです。 Interviewing.ioは、これには重大なプラス面と非常にマイナーなマイナス面があると主張しています。..。一部の企業は実際のフィードバックを提供し、それが彼らにほとんど欠点のない簡単な採用の利点を与えると考える傾向がある企業ですが、大多数の企業はそうではなく、それらの企業の人々はフィードバックを提供すると主張します。訴えられるか、会社は「キャンセル」されますが、これは通常、フィードバックを提供する会社では発生せず、インタビューでフィードバックを提供するのが通例である業界全体でさえあります。特定のリスクがあることは容易に理解でき、複数の組織からのリスクに関する漠然としたメッセージを拒否する権利を持っている人はほとんどいません。



これは小さな例であり、小さな例から一般化しすぎるのは危険ですが、官僚主義を打破するために高レベルのサポートが必要であるという考えは、ほとんどの大企業が苦労している他の分野で私が見たものと一致しています明白だが漠然とした価値を持つ何か軽いものを作成します。この投稿はすべてブログに関するものですが、さまざまなトピックについて同様の話を聞いたことがあります。



付録：クールなブログ投稿の例



これは、私がこの投稿に値すると思う理由についての短いコメントとともに言及されたブログからのいくつかの投稿です。今回は逆のsha512ハッシュ順です。



Cloudflare





Segment





Heap





これらのブログはすべて異なるスタイルを持っていることに注意してください。個人的には、「深い」技術的な投稿の割合が高いCloudflareブログスタイルを好みますが、人によって好みが異なります。動作することができる多くのスタイルがあります。


More articles:


All Articles