CTOの告白：スタートアップにおけるCTOの開発パス

急成長している新興企業における創設者の自己開発の重要性について多くのことが書かれています。原則として、そのようなトピックに関するテキストは、CEOの役割に専念しています。一般的なリーダーシップのヒントは他の役割にも役立つ可能性がありますが、技術の創設者を支援する資料を見つけることができませんでした。たくさんのS-1フォームを読んだ後、MVPからIPOに移行したCTOを最初から見つけることは非常に難しいことが明らかになりました（創設者-CEOの場合、状況は正反対です）。この事実は私には興味をそそられるように思えました-私はもっと深く掘り下げることに決めました。私はこの状況の本質と理由の根底に行きたかったのです。それはまた私を少し悩ませます：私が急速に成長することができない場合はどうなりますか？実際の問題が発生する前に、それを理解する必要があります。 RevenueCatを公開会社にするCTOになりたいです！ （1）



CEO以外の創設者が急速に成長するのは難しいですか？ CEOは通常重要なサポートを持っているということでしょうか？とはいえ、すべてに独自の理由があります。たぶん私は質問を間違えただけです。多くのCTO創設者と話し合った後、CTOの標準的な定義がないことが明らかになりました。このポジションにいる人の責任は、会社とその発展段階によって完全に変わる可能性があります。 CTOはおそらく最初は多くの個人的な入力を行いますが、これはすぐに変わる可能性があります。異なる人々の経験は非常に異なる可能性があります。残念ながら、CEO以外の創設者には答えがありません。初めてCTOになった方にも答えがないのかもしれません。とはいえ、学んだことを振り返ってみるといいと思いましたが、そして、RevenueCatでの3年間で私の責任がどのように変わったか。

ジレンマ：CTOとエンジニアリング担当副社長

簡単に言えば、CTOの役割はアーキテクチャとコードに近く、VPEがプロセスと管理を担当します。アナロジーは、シニア/フルタイムのエンジニアとエンジニアリングマネージャーのパスを比較することです。



早い段階で、MVPを作成するパフォーマーを集めて整理できるCTOが必要です。この段階では、製品のビジョンと技術プロセスの文化を定義する必要があるため、創設者は非常に役立ちます。理想的には、CTOは彼のスタートアップが解決する問題を理解する必要があります。



製品が成功した場合はどうなりますか？製品が市場に出回った場合はどうなりますか？この場合、消費者からの需要を満たすために、より多くのエンジニアを雇う必要があります。これは素晴らしい挑戦です。おそらくあなたは幸運で資金を見つけるでしょう、あるいはあなたはすでに利益を生み出しているかもしれません。ただし、スタッフが大きいほど、卓越したプロセスに対する要件は高くなります。誰かがエンジニアリングのVPにならなければならない時は必然的に来るでしょう。この瞬間の始まりは、既存の（または存在しない）プロセスが機能しなくなるとすぐに明らかになります。このような状況では、いくつかのオプションがあります。 CTOがエンジニアリング担当副社長の役割を引き継ぐことも、会社が追加の従業員を雇用することもできます。この決定は、個人的な好みと管理経験の問題である可能性があります。この種の課題に取り組むには、まったく異なる一連のスキルが必要であり、非常に急速に成長する必要がある環境では、これらのスキルを習得するのは難しい場合があります。これが、CTOが通常外部委託されている理由です。



創設者は柔軟に対応できます。彼は会社がたどる道を決定する権限を持っているかもしれません。おそらく、人を管理するのが嫌いで、テクノロジーを直接操作するためにスキルと知識を継続したいと考えています。または、管理スキルを向上させたい場合もあります。最初のタイプは、一般的に、創設者の管理上の欠陥をより寛容にしています。彼らは創設者を信頼し、彼らのアイデアを信じ、彼らが善意を持っていると確信していたので、チームに加わりました。最初は、外部の人とではなく、直接あなたと仕事をすることを好むかもしれません。いずれにせよ、将来、会社にはいくつかのレベルの管理があります。したがって、この道を進みたいと思っていて、経験がない場合は、学び、すばやく学ぶ必要があります。



Zapierの共同創設者兼CTOであるBrianHelmigは、ドーパミンがあなたに与えるものを見つける必要があると言います。個人的には、人よりもコンピューターとのコミュニケーションの方がずっと簡単でした。開発の道の選択についてはよくわかりませんでしたが、私はコンピューターに関連することをすることを好みました。私はいつも彼らと一緒に仕事をするのが大好きで、マネージャーよりもエンジニアの方が効率的だと言えます。新機能を統合した後は、直接会った後よりも元気になりました。



しかし、創業者として、会社が順調に進んでいるとき、私は高用量のドーパミンを手に入れます。購入者が当社の製品を推奨する場合。収入目標を達成したとき。私よりも優れたエンジニアを雇うとき。これらのエンジニアがすべてに満足し、野心的なタスクをうまく解決したとき。コードレビューは疲れますが、怒りではなく、コラボレーションの雰囲気の中で行われます。



それで、結局、私は自分の好みに従うだけでなく、会社の発展のさまざまな段階で会社にとってより効果的なことをすることに決めました。結局のところ、私は問題を解決することができます。これが私の役割について話しました。創設者としての私の資質は、CTOとしての私の立場よりも重要です。長期的には、大株主として、会社のために最善を尽くさなければなりません。



通常、チームに8〜12人のエンジニアがいる場合に骨折が発生します。ただし、それは別の瞬間に発生する可能性があり、すべて製品と環境によって異なります。完全に分散した企業として、ワークフローに新しいタイムゾーンを組み込む際に、いくつかの転換点に直面しました。当時、多くの人がCTOとエンジニアリング担当副社長を同時に務めなければなりませんでした。私は他の人がリソースを欠いている仕事を引き受けようとしました（私は一時的にそれをしました、そしてあまりうまくいきませんでした）。それは私が問題点を見つけ、プロセスを確立し、そしてこれらのタスクを引き受けることができる誰かを雇うのを助けました。







他の創設者が仕事のさまざまな段階で時間を管理する方法を学んだとき、私は自分の役割をよりうまくナビゲートすることができました。会社設立以来、日記をつけています。これらのメモに基づいて、私が焦点を当てたタスクと、私の役割がどのように進化したかについて話します。

2018年：YC、MVP、最初の従業員

YCombinatorに来たとき、それはJacobと私だけでした。 JacobはSDKとフロントエンドに取り組み、私はバックエンドに取り組みました。 YCの後、最初の2人のエンジニアを雇って、ジェイコブの責任を引き継ぎ、フルタイムで働きました。私たちは皆サンフランシスコに住んでいて、すでにこれらの人々を知っていました。シンプルな（そしてほぼ完全な）コントロールがありました。オーバーヘッドはなく、毎週スプリントがあり、非常に迅速に移動しました。



最近は強烈でしたがとても楽しかったです。私たちはエンジニアリング文化の基礎を築き、顧客が次々とやってくるのを見ました。ほとんどの時間、私は顧客が話している機能の最初のバージョンの開発に費やしました。私たちはできるだけ早く彼らの要求に応えました。ほとんどのリクエストは同じ日に処理されました。



そのとき私が最も疑ったのは、人々が本当に必要としている製品を作成していて、それが150万ドルのシードラウンドを開発して正当化できるということでした。



主な結論：それらの数が多すぎて、一般化するのが難しすぎます。YCombinatorを体験したとき、私たちは多くのことを学びました。おそらく、クライアントとのコミュニケーション、クライアントを幸せにし、ニーズを満たすものを作成する能力を強調する価値があります。これと非常に速い配達が私たちのコアバリューになっています。

2019年：私たちはクライアントと歩調を合わせ、テクノロジーを開発します

私たちは市場でニッチを取っているようです。クライアントが私たちのところにやって来て、サポートのリクエストが蓄積し始め、私たちのAPIのパフォーマンスは毎日向上しました。台湾からの最初のリモートエンジニアがチームに加わりました。当初、タイムゾーンの違いが問題を引き起こし、作業プロセスを適応させる必要がありました。しかし、すべてがうまくいきました。私たちは顧客からの問い合わせと監視で良い仕事をしました。



適応は単純で一度限りのプロセスでした。私は対面式の会議を行いましたが（あまり頻繁ではなく、月に1回程度）、管理は非常に簡単でした。会話のほとんどはまだ技術的でした。私はまだ普通のパフォーマーとして貢献していました。私はいくつかの会議にも出席しました。







当時、私は主に技術的な懸念を持っていました。主に私は私たちのシステムのスケーラビリティについて考えました。すべてのエンジニアが製品の使用経験があり、明確な障害点がありました。私はいつも何も壊さないことを考えていました。スケールは常に私の快適ゾーンから外れていました。最も一般的なシナリオの最適化、インフラストラクチャの移行に対処し、重要なポイントを回避しました。また、過去1年間に蓄積された技術債務を返済しました。



実際、第4四半期まで、私はコールエンジニアでした。営業時間外に他のチームメンバーの邪魔をしたくなかったので、最大限の信頼性を確保するのは技術部門の創設者としての私の責任だと感じました。私は自分のラップトップを文字通りどこにでも持っていきました。最終的には回転を確保しました。振り返ってみると、もっと早くやるべきだったと思います。



重要なポイント：スケーラビリティにこだわる必要はありませんが、監視することを忘れないでください。潜在的なボトルネックと障害のポイントに注意してください。これらの問題はストレスが多いですが、それらに対処することはそれほど悪くはありません。コールエンジニアをできるだけ早く雇って訓練し、既知のインシデントの解決策を文書化します。あなたのチームに頼ってください。責任を持ってアプローチし、市場で需要のある製品を見つけようとすれば、技術債務に問題はありません。

2020年：将来の組織の委任と計画

2020年に、私たちのチームは再び2倍になりました。ヨーロッパとラテンアメリカからエンジニアを雇いました。年末までに、各チーム（SDK、フロントエンド、フロントエンドなど）に数人の従業員がいました。私たちは何とかいくつかのプロジェクトに取り組み、最終的にはより野心的な仕事を引き受けました。ただし、調整を改善する必要がありました。この段階では、ガバナンス構造に関する作業は避けられませんでした。



第1四半期と第2四半期の間、私はほとんどの時間をコードレビュー、アーキテクチャガイドラインの提供、およびサイドでのコードの作成に費やしました。私はまだ私たちのシステムを理解している人でした。年の半ばまでに、私が新機能をリリースするためのボトルネックであることが明らかになりました。また、1対1の会議を開催し、ブレインストーミングのディスカッションに参加しましたが、コードを記述して時間どおりに実装する時間がなくなりました。



プログラミングを完全に停止しました。代わりに、私は自分の仕事を他のエンジニアに任せ、知識の伝達により多くの時間を費やし始めました。最初は時間がかかったように見えましたが、代表団は多くのプロジェクトを軌道に乗せ、多くのエンジニアに強いオーナーシップを与えました。最初はコードを書かないのはとても不思議でした。私は自分の仕事をしていない（または非生産的に働いている）ように感じました。これは完全に自然な感覚です。プログラミングから解放されたことにすぐに気づき、全体像を見ることができるようになりました。エンジニアリング構造の将来について考えることができました。



管理の面では、私はキャリアの成長について話すことにもっと時間を費やし始め、成長と発展のためにエンジニアと協力し始めました。製品側では、スプリントに適切な優先順位を付け、計画し、調整するためのリソースが不足していました。私は人々を解放し、コミュニケーションを確立するために最善を尽くしました。



また、資金調達ラウンドAを経て、取締役会の開催を開始しました。私も募集に多くの時間を費やし始めました。



重要なポイント：新しいタイムゾーンは、重複する場合に実装が容易になりました。バスファクターを減らすことは、エンジニアリングチームを拡大するために非常に重要です。ワークフローを確認して機能している場合は、可能な限り自動化します。木の森が見当たらない場合は、プログラミングを終了して委任してください。

未来

来年はまたチームを2倍にする予定です。従業員数を20人から40人にするのは、10人から20人にするより難しいようです。2021年末までに、会社は大きく変わるでしょう。



チームのスケーラビリティに集中すると思います。私を誤解しないでください。もちろん、私たちは深刻な技術的問題に直面します。私たちの計画には非常に野心的な仕事がたくさんあります。過去数年間で、私たちはお客様、問題、およびソリューションの基礎となる技術スタックについて多くのことを学びました。問題を解決するためのスキルと熱意を持った才能のあるエンジニアと仕事をすることは、私にとって大きな部分です。



今後も優秀な人材を採用し、健全なエンジニアリング文化を維持していきたいと考えています。簡単なことではありません。調達、採用、オンボーディング、コミュニケーションの各プロセスを合理化および自動化するには、HRマネージャーと緊密に連携する必要があります。紹介はチーム開発を加速するのに役立ちましたが、チームの多様性に焦点を当てる時が来ました。後輩を雇う機会があると思いますので、彼らの可能性を最大限に発揮できるようにお手伝いしたいと思います。



エンジニアを幸せにし、力を与えるために、エンジニアリング管理を改善する必要があります。さらに、野心的なタスクに取り組みたい場合は、計画プロセスに投資する必要があります。製品の開発と発売。



来年はどうなるかとても楽しみです。もちろん、既存の問題に加えて、新しい問題が発生します。しかし、それ以外の場合は決して起こりません。簡単なことではありません！



このテキストが面白くて参考になったと思います。この投稿に戻って、新しい知識で補足する予定です。 CTOとして初めての場合は、できる限りのお手伝いをさせていただきます。ツイートまたはメールでお気軽にどうぞ。



Alex Plugar、Calvin French-Owen、Xavi Santana、Adam Houghton、Sam Lown、Saul Diez、Will Larsonのアドバイスと、時間を割いて経験を共有してくれたことに特に感謝します。そしてもちろん、RevenueCatエンジニアリングチーム全体に、私がそれらを実験できるようにしてくれて、私の欠点と彼らの率直なフィードバックを受け入れてくれました。



（1）時が経つにつれ、不安や恐れは主に詐欺師症候群が原因であり、根拠がないことを学びました。会社があなたを超えたとしても、それは必ずしも悪いことではありません。実際、これは深刻な問題です。創設者はそれに直面する必要があります。あなたよりも優れた人材を採用することに焦点を当ててください。彼らはあなたが成長し、会社をより良くするのに役立ちます。私はまだRevenueCatの公開を支援したいと思っています。それが成功した場合、私の責任と立場はそれほど重要ではなくなります。

• HackerNewsに関するディスカッション
• 電報チャンネル「ロシア語のHackerNews」