#define CTO の別訳～CTOと技術担当副社長の協働

• https://blog.gregbrockman.com/figuring-out-the-cto-role-at-stripe
  • Stripe社のCTOのエントリ。
• http://postd.cc/figuring-out-the-cto-role-at-stripe/
  • に訳があるのだけど、細かいニュアンスが納得いかなかった＆深く理解したかったので自分でも訳とまとめ。

以下、まとめ

• CTOとVP Engineeringの協働体制
  • VP Engineeringの役割(得意だったこと)
    • 1on1
    • 採用
  • それらをVP Engineeringに任せることができた時のCTOの役割は？
    • チーフアーキテクトを志向する(期待されている)
      • でも、ほとんどのCTOは全うできてない
    • 別の選択としてのプロダクトのトップ
      • よいプロダクトは簡素で理解しやすいもの。よい構造は違う。
        • digestable：理解(消化)しやすい(→この言葉、流行ってもよさそうｗ)
      • だから全うしやすい？
  • 組織に重要だったのは
    • エンジニアのファシリテート(empower)
    • すごいエンジニアの採用
    • の2つ
• 会社を理解するためのフィードバックのループ(その中でも実用的なもの)
  • ①コードを書く
  • ②たくさんの人と話す
  • VP Engineeringは、②でそれができる。
  • CTOはどうするか。①でできるのか。
• (自身の影響力について)コードを書くことは、
  • てこを大きく保つことができる活動
  • 充電できる活動

自身の感想

• 1on1で「すごい」ってどんなん？
• この分担(協働)アリだなぁ。
• コードを書くことで状況にキャッチアップできる、この感覚もう少し理解を深める必要がある。

---

私は、2010年にエンジニアとしてStripeにjoinした。
バックエンドのインフラについての業務から始めた。それは、サーバー構成の設計、クレジットカード情報の保管庫を創る、みんなの仕事を楽にするための内部の抽象化といったことだ。コードを書くことは好きだったけど、他のことに多くの時間を費やした。採用プログラムを理解したり、企業文化の形成、最初のTシャツを作ったり(最初のデザイナーを雇ったのでボツになったけども)といったことだ。コードを書く方が好きだったし、とりわけこれらばかりやっていたわけではないが、その代わり、自分が参加する組織に対して強いビジョンを持っていたし、実際にそうなるように自分のやり方を実行したかった。

時間が経つと、コードを書くということそのもの以外の責任が増えていった。私の仕事は、Nelson Elhage言うところの、フルタイムの"初期の社員"になった。日々、文化の解説書を書き、新入社員を馴染ませ、採用を走らせ、といったことで手一杯だった。コードを書くのを完全に諦めることを考えたことも多かったが、何とかしてコードを書く方法を見つけてきた。

1年半後、公式にCTOとなった。実際、これまでやっていることにCTOという言葉を1つ充てただけだった。"あれ、すでにGregはCTOだと思っていたよ"という反応が多かったし。この投稿はその後に何が起こったか、についてだ。それは、我々のエンジニアチームを一緒に作るパートナーを見つけたこと、組織が変わる時に自分の役割を理解したこと、だ。

技術担当副社長を雇う

去年の夏ごろ、エンジニアチームの要求についていくため(把握し対応するため)、全員と1on1(1対1)ミーティングを始めた。火曜日一日にそれを積み上げ、その日の終わりには完全に燃え尽きていた。次の火曜日までに充電して生産的になり、またそれ(燃え尽きるの)を繰り返していた。

この間、私は、技術のキャリアか、人々(マネジメント)のキャリアか、の選択に向き合っていたのだと思っている。コードを書くのが何よりも楽しいことだったけれども、それと同時に、雇った驚異的な人々をサポートするという、組織としての責任を負っているということも知っていた。別の会社のCTOの友達と話していて、技術担当副社長を雇ったことが、彼にとってどんなに変化をもたらしたか話してくれた。以前も技術担当副社長のことは聞いたことがあったが、(人々が)そんなに積極的に探しているとは思ってなかった。なので、私は技術担当副社長を見つけることにして、CEOや内部の人々に、それがよい考えだと説得した。

内部の人々は、だれもその役割をやりたがらなかった。私たちは、まずもって私のように建設的な偉大なる個人貢献者を雇ってきたし、グループ全体をmanageしたいと本当に思う人は雇ってこなかったので、外部から雇わないといけないことは明白だった。

その1年半前から、アドバイスをもらうために、かなりの数のプロのマネージャと会っていた。もし可能ならすぐにでも一緒に働きたいと思わせる人はほんの少数だった。しかし、タイミングはうまく行かず、採用会社に頼み込む準備をした。

あっけない結果ではなかったけども、その間に、(一緒に働きたいと思う)managerの1人のMarc Hedlundが、偶然雇える状況になった。チームの全員にそもそも技術担当副社長を雇うという考えについて話をし、この候補者が格別だという話をし、それから、25人のエンジニア全員がチームとしてこのことについて話すために話し合いの場に座った。我々は、その役割がどんなものか正確に知らなかったけれども、1つだけその役割が必要とされることを知っていた。それは、(第一に、今のエンジニアにとって、そして我々が大きくscaleする際にmanagerにとって)たくさんの1on1(1対1)ミーティングのことだ。なので、最善の戦略は、その候補者が1on1についてすごいかどうかに焦点を当てることであり、あとの役割は入ってもらってから一緒に決めようという風にした。

それから、我々は、Marcと面談を設定した。4日間にわたってam10時～pm6時まで立て続けに、まるで会社全体へ話しかけるかのように、チーム全員との1対1または1対2の面談だった。私は彼に何度も、この、へとへとになる連続ミーティングは本当にOKかどうか確認した。超人的なスタミナを要求されると思うし。でも彼は、全く問題ない、といって私を安心させた。そして、実際のところ彼はすごかった。

一方で、私は、以前に彼と働いた人と、かなりの人数話した。幾人かはMarcがリファレンスとして提供してくれた人だったし、幾人かは、それ以外の裏ルートで話を聞いた。フィードバックからとても明らかなことがあった。"かれは驚くべき影響を与えてくれたメンターだった"、"今でも連絡取っているよ"、"また一緒に働きたいよ"。私は、周りの人がそこまでいう彼とぜひ働いてみたいと思った。

最終的に重要なのは、Marcと私がそれぞれ、一緒に働くとどれほどよいか、を理解したことだ。2人の間で、エンジニアチームを成長させ、形作っていくことに対する責任を持っていて、協調して行動できないとやっかいなことになった。我々2人は、かなりの時間を費やし、Stripe社が直面している問題のいくつかについて話した。

私は彼に尋ねた。"意見の相違をどうやって解消しようか"。彼は答えた"今やっているように会話しましょう。理想的な土壌は、エンジニアリングをよくするために働く上でお互いを信頼していて、進め方についてどちらかが著しい気がかりを感じたら、それについて話しましょう。そしてその気がかりが解消しない場合は、その解決策は保留しましょう"

後に、(訳注：彼自身の)採用のプロセスに対してどう思ったか彼に聞いた時に、彼の答えはこうだった。"君たちはmanagerを雇ったことがなかったんだね"。彼は我々のmanagerの面談の(訳注：マネージャを採用するための面談の)設計をするタスクを引き受けた。皮肉なことに以前、私も、自分自身(訳注：自分自身(エンジニア)が採用された時)のインタビューの進め方に対してまさに同じ反応をしたことがあり、私はエンジニア面談の(訳注：エンジニアを採用するための面談)設計をやる気になった。

(訳注：ここまでずっと、Marcの採用～入社までの話)

技術担当副社長を得てから

そしてMarcを迎え入れた。始めるにあたって、私は彼をMLとメッセンジャーに追加した。会社で何が起こっているのか、個別の問題にどう取り組むか、メールの下書きのレビュー、などをたくさんの時間をかけて話した。

彼が働き始めると、私は直ちにすべての1on1を彼に移行した。彼はこうも言った。自分の目の前から消え去ってほしいものは何でもためらいなく彼に送りつけて、と。私はとても圧倒された。彼が提案することは理にかなっていて、とりわけ採用はそうだった。私は実際びっくりしたのだけれど、採用がこんなにもぴったりハマって、採用計画を止める(完了する)ことができるなんて知らなかった。しかし、採用は技術担当副社長の役割の典型的な一つとなった。実際、私が自然と開拓してきた役割は、ほぼ完全に通常なら技術担当副社長の役割だったと、遅ればせながら気づいた。

時間が過ぎると、重要な変化が確実になった。みんな問題を私よりMarcに持ち込むようになった。これによる一番よかったことは、Hawaiへの初めての休暇を取れたことで、それから、数人のエンジニアとCTF3を構築するためにこもったことだ。私は、もっともっと責任を移行した。Marcは今やたくさんの人々に話しかけているので、あらゆるグループが直面している問題を知れるし、組織の変化がどう進んでいるかを知れる立ち位置にいた。

新しい重役が組織に根付くのは決してスムーズではない。開始から失敗することもあるし、あらゆる変化が行き詰ってしまうこともある。場合によっては、組織文化が新しい重役のために変化する必要があったりもするし、企業文化に合わせるために新しい重役が変化する必要があったりもする。多くのエンジニアが行っていることだと思うけど、"ダメなこと"なのか、"やったことないこと"なのかを見分けるのが難しいややこしい問題に悩まされた。Marcは、私とは全然違うやり方で、採用を実行し、チームのミーティングをリードし、コミュニケーションを取り、すべてちゃんとうまく行ってると悟るのには時間がかかりました。

ここで私が受け取った最善のアドバイスは、委譲には伝統的に2つの選択があるよ、というもの。完全に委譲する(そして原則を決めて、実行からは手を引く)が1つ、あるいはすべての詳細に関与し続ける、が1つ。後者のモデルがうまくいく(Mark Zuckerbergが引き続き製品に関わっているのを思い浮かべてみて)。でも1つの箇所しかそうできないよ。(伝統的でないやり方もある。それは、自分を真似するのがうまい人を何人か訓練して、委譲したところをやらせる。これは機能するけど不健全だ)。しかし一般に、"まばらなマイクロマネジメント"(ランダムに問題に飛び込んで、すべての決定をして、そして去る、というのをもっともうまく表現した言葉)が最も悪い。

Marcと私がやったのは、きわめて単純。たくさん時間を費やした。毎週、月曜1時間と金曜1時間の1on1を始めた。たくさん話すことがない時もあったけど、それでも、何を心配しているか、何の仕事をしているか、物事の進みはどうか、といったことを言うのにかなりの時間を費やすことはきわめて重要だった。その結果、Marcがどう反応するか分からない問題をたくさん抱える状態から、気付くのに数日以上かかるものはなく、ついには基本的に彼がどう反応するか分かっているようになりました。あとは、電話のIM(メッセンジャー)を使ったり、"Xを実行しようと思っている。24時間以内に明らかな反対がなければ実行しちゃうよ"、といったいくつか小さなコミュニケーション方法を使った。

あなたが急速に成長する会社を持っているなら、組織自体が、あなたの手中にある状態から、絶えず変化していくのが分かるだろう。Marcが組織において変化をもたらすことを学んでいる時、私も同じことを再学習した。私たちは、親しい友だちだけの組織から、ダンバー数を超えた会社へと変わりました。それは、人々は体験したことないかもしれないけれども、どうやったらうまく運営できるのかを理解しなければなりません。パートナー(特により大きな組織での経験がある人)を得ることはきわめて価値があることで、それなくしては、成し遂げられなかった。

私の役目

私は、急にやることがなくなったかのように感じ、やりたいことは何でもこなしにいきました。これはとても効果的でした。約1年のうちに、私の役目はほぼほぼ、日々の問題に対処することになった(訳注：それ以外のやることが片付いた？)。私が、自身が集中したいことを決める機会を持つのは初めてだった。

CTOのビジョンの探究を続けた。つまり、20人ほどのCTOと技術担当副社長におのおのの役割を聞いた。ほとんどCTOがチーフアーキテクトであることを期待されている、と理解した。しかし、しかし私は、どうやってそれをやり遂げているのか知りたかった。なぜなら、私も"初期の社員"に加えて、チーフアーキテクトでいたかったが、それを片手間で(非常勤の時間で)やる方法が思いつかなかったから。(そして、恐ろしいことに、みんな私が問題の最前線にいると思っているので、私は、(訳注：自分が率いることができないことで)我々のシステムが停滞しているように感じてしまっていた)

驚いたことに、それ(訳注：チーフアーキテクトを全うできている)が当てはまったCTOは1人だけだった。みんな、自身を技術組織のファシリテーターとして見ていた。時には、シニアエンジニア同士をつなげること、時にはメンターになること。私にとって示唆深かったのは、効果的なプロダクトのトップとしてのCTOだった。プロダクトのトップと、構造(インフラ)のトップはとても違うと気づいた。よいプロダクトは簡素で理解しやすく(digestible:消化できる)、悪いことと良いことが素早く識別できる傾向がある。対照的に、よい構造(インフラ)は、拡張性高く組み立てられているかという点のみだ。だから、片手間のチーフアーキテクトであるよりも、片手間のプロダクトのトップである方が、扱いやすい(訳注：担いやすい？)

やるべき最も重要なことは、エンジニアが大きな変化や、改善を実施するのを後押しすることだと気づいた。(加えて、我々は極めてすごいエンジニアたちを雇ってきたこと。それ以外のことはほぼ無意味でさえあった)。Marcと私は、Stripeのコアな部分を改善する主要なプロジェクトを実現し、励ますべく仕事をしてきた。さらに、"アーキテクチャWG(ワーキンググループ)"を始めた。それは、他のエンジニアたちがよりよいシステムを作るのを助けることができる、数人のエンジニアのグループで、また、私たちのインフラがどうなっているか理解するための(？)会合だ。

しかし、一つ予期していなかったことは、フィードバックのループを失ったことだった。Marcが参画する前は、組織のスナップショットを持っていた(訳注：その時その時の最新の状況が分かっていた？)が、なんら更新された情報を得られなくなった。Xが問題だよね、Yが正しいアプローチだよね、と誰かを説得しようとしても、私の逸話や証拠は古くなっていた。まるで、以前は岸につながれていた船だったのに、今や誰かが綱を切ったことによって漂っているかのようだ。そして、最も悩ましいことに、日に日に問題がシビアになっていた。

組織で何が起こっているか、その時点の問題は何か、をどうやって知るのかについてかなりの時間考えた。4つのメカニズムを思いついた。

1. 仕事の中で：そう、コードを書いているのであれば、何がよいか、何が悪いかについて、直接の経験を得ることができる
2. たくさんの人と話す：色々な視点を得て、どんな感情か口にすることができる
3. 仕事を観察する：おそらくアーキテクトの視点で、すべての差分を読む。(実際は、私はそれに1ヶ月を投下したが、時間の無駄遣いだった。ほとんどの仕事は、それをした人の(訳注：組織の、ではなく)心理の状態を再構成するだけだから)
4. 仕事を計画する：すべてを綿密に計画するだろうが、他からのフィードバックのループがなければ持続しないと思っている。

私はそのどれも行っていないことに気づいた(訳注：なので組織の最新の状況が追えなくなった)。そしてリストを眺めて、どれが私にとって一番幸せか考えた。問題はどうやってそれを手にするかだ。

コードを書くことに対して、たくさん試してみた。多くは機能しなかった。たとえば"窮地では立ち去り、プロトタイプを作って来て、それをエンジニアにメンテするよう投げつける(あるいはメンテしないで放っておく)"とか。それをやるCTOがいることは知っているが、素晴らしいと感じさせるような類のことは見つけられなかった。(もしこれが機能しているところを知っていたら、知らせてください)。少しよいものは、"チームのエンジニアとして働き、一緒にプロトタイプを作り上げる"ことだ。でも、みんなの時間と常に戦わないといけないので(訳注：時間の投下量の話？)、これも苦しい戦いだ。

ディナーで会った別のCTOは、最近コーディングに戻った、と話した。どうやってやったの？秘訣を聞いてみた。彼は私を見て言った。"コーディングは私の大好きなことだ。コードを書くのは、他の何よりもはるかによい職業をやっているって分かっている。私に必要だったのは、コーディングからどうやっててこの力を引き出すかだけだった"。彼にとっては、彼らのインフラとなるオープンソースのプラットフォームを書くことが、彼の会社と産業の両方を改善することだったのだ。

これは先月の話で、私は再び、チームで働きコードを書き始めた。それは簡単なことじゃない。他にやらなきゃいけないこともたくさんある。でも、コードを生み出すことに没頭する時間を使えば使うほど、組織に対して持てる視界は広がり、人々を助け、作るモノについて興奮させることができ、彼らの仕事を改善することができました。

---

コードに集中することによって、高い"てこ"の働く活動を失っていないか、この選択をすることがもっともなことかどうか時々疑問に思う。しかし、また別のCTOから聞いた珠玉のアドバイスは、これは時間管理の話ではなく、エネルギーの管理の話だ、ということ。(てこの話とは独立した)自分が充電できる活動を見つけることは重要で、それがあるから、"てこ"を消耗させてしまう物事を片づけるエネルギーを得ることができる。

私の役割はここから分かるように、まだ完全に定義できてない。今はコーディングで忙しい。