スタートアップが成長するにつれて、そのワークフローを変更する必要があります。これはエンジニアにとって特に重要であることに気づきました。共同創設者およびCTOとしての私の役割は、ここ数年で大きく変わりました。私の日々の責任と仕事は変わり、会社が次のレベルに到達するのを助けるために、私は仕事へのアプローチを何度か変えなければなりませんでした。
会社の初期の頃、チームは夜と週末に働いていた3人の男で構成され、地下で後にザピアになるものを見ました。発売前に、3つまたは4つのバージョンの製品を作成しました。それから6年が経過し、現在APIへの数億件のリクエストを処理しており、チームには世界中から80人のスペシャリスト（20人以上のエンジニアを含む）が雇用されています。
私たち3人の時代から現在までの成長は非常に困難でした。必要に応じて、この間に私が引き出した結論を読むことができます。それ以外の場合は、私が初心者のCTOとして成長していたときに得た教訓をよく理解しておくことをお勧めします。
スタートアップの技術管理開発ツリー
行き過ぎる前に、それを理解しましょう-一体誰がCTOですか？これは、チームの最初の数人のエンジニアを雇ったときに私が自問した質問です。 CTO-ソフトウェアの世界でコードに従うのと同じことをする慈悲深い永遠の独裁者？それとも、ある種のスーパーマネージャーまたはスーパーハッカーですか？
多くの人にアドバイスを求めました。 Buffer、Unbounce、および私たちよりわずかに大きい他のスタートアップのCTOに連絡しました。そして私は答えを得ました：誰も本当に知りません。これはあいまいな役割であり、どのフレームワークにも組み込むことはできません。コミュニケーションの過程で、私は小規模なテクノロジー指向のスタートアップの一般的な成長パターンをいくつか発見し、開発の各段階でCTOが何をすべきかを策定しました。
私はオタクでビデオゲームをするのが大好きなので、開発ツリーは私にとって最も明白なようです。ゲームの経験を積むにつれて、レベルが上がり、特定の時点で開発のさまざまなブランチを選択できます。
これは、スタートアップのSTOツリーがどのように見えるかを示しています。
孤独なハッカー（1-2エンジニア）
これはまさに私たちが地下で働いていた時です。楽しくてつかの間の時間でした。あなたはたくさんのことをします、誰もが同期して働くので、コミュニケーションとコミュニケーションのオーバーヘッドはほとんどありません。何が機能し、何が機能しないかを理解しようとしているだけです。
コーダーの小さなチーム（2〜6人のエンジニア）
スタートアップの創設者として、あなたはチームを成長させたいので、人を雇い始めます。通常、誰もが友達を雇うことから始めます。友達を雇う価値はないと言う人もいますが、この早い段階では素晴らしいと思います。あなたは彼らと一緒に働くことができることを知っています、あなたは彼らがどれほど賢いかを知っています、そして彼らはちょうど完璧にフィットします。小さなチームフェーズは、CTOがハッキングから他の何かに移行することの苦痛を感じ始めるときです。エンジニアが数人しかないので、それでもかなり良いです。通信のオーバーヘッドはかなり小さいです。あなたはまだほとんど同期しています。あなたは何が起こっているのか理解しています。驚くことは何もありません。
チームの成長（6〜12人のエンジニア）
その後、すべてが少し奇妙になります。チームメンバーのそれぞれと話すのをやめます。管理の恐ろしい謎に取り組む必要があります。私にとって、それは根本的に新しいものでした。私にとって理解可能で自然なプログラミングとは対照的でした。コードを書くことによる通信のオーバーヘッドが大幅に増加するのはこの段階です。友達ではない人を雇うことを検討する必要があるかもしれません。あなたが存在することを知らなかったことが起こり始めるので、物事はより複雑になります。この段階では、すべてが非常に迅速に行われ、開発ツリーの最初のブランチにも出くわします。
チーム編成（12人以上のエンジニア）
この規模のチームでは、おそらくさまざまな分野で働いています。人とコードを同時にうまく処理することはできないため、次の選択肢を選択する必要があります。
エンジニアリング担当副社長：
CTOの管理に 重点を置く：コーディングとアーキテクチャに重点を置く
エンジニアリング担当副社長は、プロセスを設定し、ツールを実装する人です。全体的な生産性を向上させ、エンジニアの開発を支援します。CTOのままでいる場合は、直接コーディングに関連する作業を続行します。システム全体に精通しており、スケルトンがクローゼットのどこに隠されているかも知っているのはCTOです。
あなたはCTOになるべきですか？
私はそのような決定の準備ができていませんでした。私は自分が選択をしなければならないことさえ知りませんでした。 CTOが事実上のマネージャーになると思いました。これは、私が話したスタートアップの半数以上に当てはまるようです。どちらの道を進むか（管理または技術）に関係なく、2番目のブランチを引き継ぐ人を見つける必要があります。
決定を下すには、あなたの起源を覚えておく価値があります。どこでより多くの時間を過ごしましたか、どの程度自信がありますか、そして何に戻りたいですか？
最初は、チームには1人か2人のエンジニアしかいません。すべての時間はコーディングに費やされます。これは素晴らしいことです。チームの人数が約6人の場合、すべてがうまくいきます。時間の約80％はコーディングに費やされ、20％は通信に費やされます。そして、ワークフローはまだ良い感じになります。あなたはすべての約90％の確信があります
そして、物事ははるかに困難になります。新入社員の採用に忙しいため、半分の時間で直接業務に従事することになります。助けを必要とする従業員はますます増えますが、これはそれほど素晴らしいことではありません。以前と同じように、それを実行してコードを作成する必要があるからです。この段階で、何をしたいのか、つまり管理または開発を決定する必要があります。開発の木に沿ったこの動きはどうですか？
あなたはただあなたのドーパミンを作るものを見つける必要があります。
これは、あるスタートアップの創設者からの素晴らしいアドバイスです。誰かが仕事に取り組むのを手伝うことができれば、気分がいいですか？それとも、技術的な問題の解決を楽しんでいますか？これらの質問に対する答えが、どの道をたどるべきかを理解するのに役立つはずです。
さまざまなスタートアップのCTOからの4つのレッスン
何に焦点を合わせるかを決めようとしている15人の創設者とCTOと話をしました。私は彼らに、途中で気づいたことと直面した困難について尋ねました。これらの会話では、4つのトピックが絶えず浮上しました。
1.転換点を受け入れる
私は皆に彼らの最大の間違いについて尋ねました-彼らがそれからどのような経験をし、何をそしてどのようにそれを修正したか。それから私は彼らにどうやってそれを防ごうとするのか尋ねました。誰もが答える前に少し考えて、「あなたが知っている、私はおそらくそうしないだろう。私たちがやろうとしていることを本当に理解するには、このような瞬間を経験する必要があります。それを正しく行う方法を学ぶには、反対側に精通する必要があります。
CTOの用語では、屈曲点をサービスのスケーリングとして扱います。ボトルネックに遭遇した場合は、それらを修正する必要があります。特にスタートアップでは、それらの発生を予測することが非常に難しいため、これははるかに効率的です。
2.人間の土地はありません
これが、6人から12人のエンジニアで構成されるチームと呼べる方法です。そのようなチームでは、すべてのほんの少しが起こり、それは非常に混乱します。 「なぜこの人はこれを知らなかったのですか？」のようなフレーズを言っていることに気付くでしょう。そして、彼は本当に何をすべきかわからなかったのですか？」そのような質問に直面した場合、責任を組み合わせることができなくなります。1つのことを実行し、残りの半分のタスクをそれらに対処できる人に転送する必要があります。あなたは一度に2つの役割を処理するほど天才ではありませんが、この状況を無視するほど愚かではありません。あなたは途中で立ち往生しているようです。
この段階で、コミュニケーションは橋を架けるのに役立ちます。「なぜXがこれをしたのか」のようなフレーズを言っていることに気付いた場合は、特定のことをもっと頻繁に言い始める必要があります。人々が目を転がして「また同じ」と言うまで繰り返します。これは、すべての従業員の間で平等なレベルの理解を確保するのに役立つため、重要です。
3.構造的模倣
多くの場合、CTOが「Spotifyでどのようにそれを行うかを見ました」または「Amazonがどのようにそれを行うかを見ました」のようなことを言うのを聞いたことがあります。これらの人々は他社の構造を採用しました。テクノロジー企業として革新するのであれば、革新的な管理方法を発明するべきではありません。あなたはあなたの会社の構造の中で何か新しいものを思い付くべきではありません。あなたはあなたの技術、コード、そして製品を通して革新する必要があります。
あなたが面白いと思うものを見つけて、あなたの会社にそれを適用してみてください。時間が経つにつれて、あなたの会社は、他の誰も持っていないアイデアと組織化の方法を混ぜ合わせることによってユニークになります。あなたは自分で何かを思いつくことができるかもしれませんが、これはあなたの目標ではありません。他の人が何をしているのかを理解し、手間を省くように努める必要があります。
4.フォーカス
最後のレッスンは私の個人的な過ちに基づいています。エンジニアを雇い始めたとき、もっと多くの人が私たちにもっと多くの仕事をさせてくれるだろうと思いました。当初、創設者と雇用された従業員の最初のペアは文字通りジャグリングしました。誰もが2つか3つのプロジェクトに取り組むことができるように思えましたが、それは問題ありませんでした。つまり、4人のエンジニアが同時に8〜12のプロジェクトを実行できますよね？いいえ、それはひどい考えでした。
プロジェクトが多いほど、通信スレッドも多くなります。すべてのプロセスを追跡し、すべての人がすべてを理解していることを確認することははるかに困難です。振り返ってみると、より多くの人を雇うと、ワークロードを同じレベルに保つか、少し下げるだけの価値があったと思います。
誰もが注目しているプロジェクトを1つ選びました。これが私たちの最優先事項であることを皆に明らかにしました。二次的なタスクもいくつかありましたが、それらは二次的なものであり、私たちの主な目標は主なものでした。
私の経験が、特にCTOとして、スタートアップの初期段階の濁った海をナビゲートしようとしている人々に役立つことを願っています。これらすべてを事前に知っていれば素晴らしいのですが、そうすると、このすべての経験を得ることができないかもしれません。それにもかかわらず、混乱し、後で決定を延期し、外出先でそれを整理することは絶対に正常です。初期の段階ではスタートアップにはさまざまなニーズがあるため、これはすべて正常です。