私は2010年にエンジニアとしてStripeに加わりました。まずバックエンドのインフラに取り組むことから始めました。サーバーアーキテクチャの設計、クレジットカードの金庫室の作成、人々の仕事を容易にするための内部の抽象化を作り出すことです。私はコードを書くことが好きでしたが、他のことにもかなりの時間を費やしました。求人プログラムの理解、企業文化の形成、あるいは最初の Tシャツ を作ることです（ 最初のデザイナー を雇ったのでこれはできなくなりましたが）。コーディングを好んだので、私はこれらのことを特にやっていた訳ではありませんでした。代わりに、この環境への非常に強いビジョンがありました。環境の一部になって、存続させるために尽力するつもりでいました。

時間が経つにつれて、厳密にはコードを書くこと以外で責任がますます増えました。 Nelson Elhage が望んだように、私の仕事はフルタイムの”初期の社員”になりました。私の日々は企業文化的なガイドを書くこと、新たな人々に慣れること、求人プログラムを履行することなどでした。私はコーディングについて完全に諦めるときだとたびたび考えましたが、どうにかそこへ戻る道をいつも見つけました。

およそ1年半後に私は最高技術責任者（CTO）として公式に任命されました。私がすでにやっていたことに一言添えただけでした。最も一般的な反応は「えっ、GregはもうCTOだと思ってました」でした。この投稿は任命後に起こった出来事の物語です。私たちのエンジニアリングチームを作り上げるパートナー探しと、組織の変化につれて私が自分役割を理解していった過程です。

去年の夏頃に、エンジニアリングチームの要求についていくために、私はあらゆる人と1対1になることを始めました。火曜日のすべてはそれを山積みにしていました。またその日の終わりには完全に燃え尽きていました。次の火曜日までに充電されて再び生産的になると、もう一度繰り返していました。

この期間を経て、私が技術ルートか管理ルートかの選択に直面していると知りました。コードを書くことよりもっと好きなことを全く見つけていなかったのですが、私たちが雇用した驚くべき人々を組織として支える責任があることを同時に知りました。私は別の企業でCTO(最高技術責任者)を務める友人の一人と話していました。技術担当副社長（VP Engineering）を雇ってきたことが彼にとってどれほど改革的かについて教えてくれました。私は以前にも VP Engineering について聞いていましたが、人々がそんな人材を積極的に探しているかもしれないとは全く考えたことがありませんでした。そこで私はVP Engineeringを見つけようと決心して、これが良い考えだと社内でCEOと他の人々を説得しました。

社内では誰もVP Engineeringの役割を担おうとしませんでした。私のような向上心が強く素晴らしい個人貢献者を、私たちは主に雇ってきていました。またそれに応じて、グループ全体を本当にマネジメントしていたい人を全く雇ってきませんでした。そのため私たちが外から雇わなければならないことは明白でした。

1年半前から、私は助言を求めるために大勢のプロのマネージャーと会っていました。その内一部の人は今にでも一緒に働きたいと思う人々でした。もちろん彼らが可能であればの話ですが。しかしタイミングは決してその通りにはいかなかったので、私は人材スカウト会社を利用する準備を始めました。

そして願ってもないことに、その頃マネージャーの Marc Hedlund が偶然雇える状態になりました。私はVP Engineeringを雇う考え一般についてと、特にこの候補についてチームの全員と話しました。そして25名のエンジニア全員がグループでそれについて話すために座りました。私たちはVP Engineeringが必要だろうという 一点 だけ知っていましたが、その役割が何なのか正確には分かっていませんでした。1対1でたくさん話しました（主に今現在のエンジニアと、主に調整中のマネージャーについて）。そして 最良の戦略 は候補者が1対1で 素晴らしい かどうかに焦点を合わせることであり、また彼がここにいたら役割の残りも一緒に分かると私たちは考えました。

私たちはMarcとの面接を設けました。会社全体と話すときと同様に、チーム全員と4日間続けて午前10時から午後6時まで1対1か1対2のミーティングをしました。このひどい仕打ちの立て続けの面接が実際に問題ないかどうか、私は彼に何度か尋ねました。それはスーパーマンのスタミナを要求するかのようでした。しかし彼はええ、全く問題ないですよと私を安心させました。思ったとおり、彼は素晴らしかったです。

以前彼と働いていた大勢の人々とも私は話しました。何人かはMarcが言及した人で、何人かは別ルートで知り合った人でした。フィードバックにはとてもはっきりした話題がありました。「彼は私にとって素晴らしい影響をもたらす助言者でした」　「まだ連絡を取り合っています」　「ぜひ彼と再び働きたい」。私は他の人々がこのように評価するMarcと働きたくてうずうずしていました。

最終的に重要なのはMarcと私が一緒に働くとどれほど良いか個人的に理解したことでした。私たち二人の間では、エンジニアリングチームの成長と形成に責任があり、協力して行動しないと面倒なことになりました。Stripeが直面する問題、マネジメントやリーダーシップについてのMarcの見解などについて話して、私たちはかなりの時間を一緒に過ごしました。

私は彼に尋ねました。「意見の相違をどうやって解決しましょうか？」　彼は答えました。「そのことについて話し合いましょう。今そうしてるように。理想的な段取りだと、エンジニアリングをよりよくするために私たちが信頼する人に働いてもらって、私たちのどちらかでもそのアプローチに著しい懸念があれば、それについて話し合って、その懸念が消えなければ、その解決法は保留しましょう」

のちにこの過程について彼が考えていたことを尋ねたとき、彼の答えは「皆さんはこれまでマネージャーを雇ったことが明らかにありませんでした」というものでした。彼は マネージャーの面接 を考案する職務を引き受けました。皮肉なことに私はずっと前の私自身の面接過程とほとんど同じ反応をして、 エンジニアリングの面接の考案 に取り組む気になりました。

ひとたびVP Engineeringを迎えて

私たちはMarcを呼び寄せました。彼が始めるに先立って、私は彼をメールのアドレス帳とIMに加えました。私たちは会社で何が起こっているかについての議論、特定の問題へのアプローチ法、お互いのメール草稿の見直しなどに何時間も費やしました。

ひとたび彼が働き始めると、私はすぐに1対1になるすべてを彼に任せました。彼はまた私の平皿から取り除きたいことなら何でも、彼へよこすことを気兼ねすべきでないと言いました（私はその時とても圧倒されて嬉しくなりました）。特に求人で彼が薦める人は道理にかなっていました。私はちょっと驚きました。求人がどこで一致するのか全く分かりませんでした。またプログラムをいつ打ち切れるのか全く予想できませんでした。しかし求人がVP Engineeringの役割の典型的な部分だと分かりました。具体的には、私が組織的に開発してきた役割はほぼ完全にVP Engineeringのよくある役割だと徐々に気づきました。

時間が経つにつれて、一つの重要な変化が確かになっていきました。人々は問題を私よりMarcへ持ち込むようになりました。この面で私にとって最も良かったのは、ハワイへの（初めての）休暇をとって、その後数人のエンジニアと CTF3 の構築を続けたことです。また私はさらに責任を移しました。というのもMarcは今やたくさんの人々と話していて、彼はあらゆるグループが直面する問題や、組織的な変化がどのように展開しているかを知る、ずっと良い位置にいました。

新たな幹部を迎えることは決して順調ではありません。出だしの失敗やあらゆる変化による岩だらけの道が先にあるかもしれません。ある側面では、その幹部に合わせるために企業文化を変える必要があります。またその逆も考えられます。多くのエンジニアが直面しそうな、「私がやってきた方法じゃない」と「間違っている」を区別する困難に私は苦しみました。Marcは私と非常に違ったやり方で求人プログラムを履行したり、チームを導く会議を開いたり、コミュニケーションをとったりしていました。そのためすべてが今も良好だとしっかり理解するにはしばらく時間がかかりました。

私がそこで得た最良の助言は、他人に任せる方法には2つの伝統的な選択肢があるということです。完全に任せるか（いくつかの原則を明確にしておくかもしれませんが、そうでなければ実行から手を引く必要があります）、すべての細部に関与し続けるかです。後者のモデルは機能します。Mark Zuckerbergによる製品全体への関与について想起しましょう。しかし皆さんは一つの領域にだけ実際にそうすることができます。（また伝統的ではないアプローチもあります。皆さんのまねをすることが本当に得意な人々を訓練して、役割を任せて実行させることです。これは機能するかもしれませんが、必ずしも健全ではありません）　しかし一般に”まばらなマイクロマネージメント”（ランダムな問題に飛び込んで、すべての決定をひっくり返して、姿を消すことを指す、私が聞いた中でも最良の解釈）は最悪です。

このときMarcと私が働いた方法は実際に極めて単純で、より多くの時間を一緒に過ごしただけです。私たちは1週間に2時間1対1になることを始めました。月曜日に1時間、金曜日に1時間です。十分といえる時間がないときもありましたが、私たちが何について心配しているか、何について働いているか、物事がどこへ向かっているかを述べるたくさんの時間を費やすことはものすごく重要でした。結果として、私はMarcがどう反応するか分からないたくさんの問題を抱える状態から、いつも数日以内に気づく持つ状態になって、彼ならどう答えるか基本的に分かるようになりました。私たちは電話でIMをやり取りしたり、「私はXを行う計画を立てました。24時間以内に反対がなければタイムアウトしてやってみるつもりです」といったパターンを使うような、他のいくつかのコミュニケーション法を用いました。

急速に成長する企業なら、組織自身が皆さんの周囲から常に変わっていく様子に気づくでしょう。組織においてMarcが改善することを学んだように、私自身が同じことを再学習する必要があると分かりました。私達は親密な友人で構成される組織から ダンバー数 を超えた大きな組織へと変貌しました。つまりはお互い面識のない社員がいるような組織規模でも、上手な経営方法を追求しなければならない企業となったのです。
パートナー（特により大きな組織をマネジメントしてきた人）を持つことはものすごく価値があって、私が彼らなしでどうやっていけたかは分かりません。

私の役割

私自身の役割が急になくなるだろうと予想して、私がしたいことなら何でも受け入れ始めました。これはとても効果的でした。およそ1年以内に、私の役割はほぼ完全にその日の問題への対応になりました。これは私が焦点を合わせたいことを定義する最初の機会でした。

私はCTOのビジョンクエストにちょっと興味を持ったので、20人のさまざまなCTOとVP Engineeringに彼らの役割を説明してもらいました。私はすべてのCTOが チーフアーキテクト （最高開発責任者）だと予想していました。しかし彼らがどうやって成功しているのか知りたいと思いました。私は”初期の社員”に加えてチーフアーキテクトであろうとしていました。またパートタイムでうまく仕事をする方法が分かりませんでした。（とても恐ろしいことに、私が問題の頂上にいると誰もが見なしていたので、私たちのシステムが本当のことを言わないでいると感じました）

しかし驚いたことに、私はそれが当てはまるCTOを一人見つけただけでした。誰もが彼ら自身を技術的な組織における進行役と見なしていました。あるときは上級エンジニアたちを結束させることが目的で、あるときは彼らにメンタリングをすることでした。私にとって示唆に富んでいたのはCTOが製品の事実上の代表というケースです。製品の代表とインフラの代表の間には大きな違いがあると気づきました。良い製品は単純で把握しやすいので、良いと悪いを素早く見分けられる傾向があります。対照的に、良いインフラは大規模な構築そのものだと言えます。そのためパートタイムのチーフアーキテクトであるより、パートタイムの製品の代表である方がずっとやりやすいです。

最も重要なのは 私たちのエンジニア が大きな変更と改善をできるようにすることだと実感しました（加えて、近頃私たちは特に驚くべきエンジニアを雇ってきましたが、他はちょっと無意味でした）。Marcと私はStripeの中心を改善するための主要なプロジェクトに権限を与えて促進する仕事に着手しました。これは他の人たちがより良いシステムを構築する手助けとなるためのエンジニアのグループであり、私たちのインフラを使っている場所を理解するためのフォーラムです。

しかしながら、予想していなかった一つの出来事が私のフィードバックループを突然奪いました。Marcが加わる前から私には組織のスナップショットがありましたが、更新された情報を全く得ていませんでした。もしXが問題だとかYが正しいアプローチだと誰かを納得させようとしても、私の話と証拠のすべては以前のものでした。これはかつて陸に上がろうと結び付けた船のようであり、誰かが縄を切ったあとでは漂流しているような状態でした。最も心配なのは、問題が日に日にきっちり悪くなっていくことでした。

組織内で起こっていることや、その日の問題が何であるかを、どうすれば誰もが理解できるか考えようと多くの時間を費やしました。私は多くて4つのあり得るメカニズムを考え出しました。

1. 仕事をする 。仮にコードを書いているとすれば、何が良くて何が悪いかを直接的に経験します。
2. たくさんの人と話す 。集合的な意見を得て、何が感傷なのかを見分けられます。
3. 仕事を観察する 。設計者のようになって、差異のすべてを読み取れるかもしれません。（私はそうすることに一か月を実際に費やしたことがありますが、時間の無駄のように感じました。作業のほとんどは作成者の心の状態を再構築することでした）
4. 仕事を計画する 。すべてを計画しようとすることはできます。とはいえ他の人のフィードバックループなしでこれを維持できるか実際には確かでありません。

私はどれもやってこなかったと実感しました。このリストを見て、どれが私を最も幸せにするかはっきり分かっていました。問題はどうやってそうなるかでした。

私はコードを書いてさまざまなパターンを試してみました。それらの多くは機能しませんでした。たとえば、「窮地では立ち去れ、プロトタイプを持って戻れ、やり通すためにエンジニアへダンプせよ（または単にそのままにしておけ）」　これを試すCTOがいることを知っていますが、素晴らしいと感じさせるバリエーションを見つけたことはありません（これが機能しているところを見たことがあれば、どうか 知らせてください ）。若干良いバージョンは「チームのエンジニアと共に働け、新たなプロトタイプを一緒に作れ」です。しかし人々の時間をめぐって常に争う必要があるので、これもまたちょっと苦しい戦いです。

私はある夕食会で、コーディングの道へ最近戻ったと話す別のCTOと会いました。彼の秘密を明らかにするために、私はそれをどうやったのか尋ねました。彼は私を見て「コーディングは私が大好きなことです。コードを書くことで他の何よりもはるかに良い仕事をします。私に必要だったのはそこから影響力を取り出す方法を見つけ出すだけでした」と言いました。彼にとって、彼らのインフラのためのオープンソースのプラットフォームを構築することは、彼の会社とその産業の両方を改善することでした。

これが先月のことでした。私はチームで働き始めて、再びコードを書き始めました。無数の他の出来事が起こっているので、容易ではありませんでした。しかしコードの生成に没頭してより多くの時間を費やして、組織についてより良い全体像を抱きました。また人々を支えて、彼らを私たちが作っているものに夢中にさせて、彼らの仕事を改善する手助けができました。

高い影響力の活動を失っていないか？　しかし私が（別のCTOから）聞いた最も価値のある助言の一つは、時間のマネジメントについてではなく、エネルギーのマネジメントについてです。影響力を消耗する物事を扱うためのエネルギーを持てるように、（影響力とは無関係に）再充電する活動を見つけることは重要だと。

これから私の役割についてどうなるか、まだ完璧な定義に至っていません。それは今コーディングに夢中だからです。