記事は面白かったよ、CTOの定義が幅広い中でね。CTOの一般的な定義について、どうやってやるかではなく、やるべき仕事の観点から合意できるのか気になるな。例えば、CTOの仕事は会社が技術的に競争力を保つことだと言えるかもしれない。それを組織を作ることで実現するならそれでいいし、自分でコードを書くことで実現するならそれもありだよね。

創業者が持てるタイトルで「創業者」よりも重要なのは「CEO」だけだよ。彼は自分をCTOと呼んでるけど、それはいいとして、実際には彼は技術的な共同創業者で、そう振る舞ってる（そして、それは会社にとって非常にポジティブなことのようだね）。CTOの肩書きやこの記事の全体のポイントはあまり関係ないし、彼が共同創業者でなければこの状況は成り立たなかったと思う。創業者は必ずしも望まない役割に押し込まれるべきではないという良い教訓だと思うけど、CTOの肩書きは本当に関係ないよね。

このコメントは、今までのコメントの中で一番理にかなってると思った。さらに言えば、多くの企業にはエンジニアリングのVPとCTOがいることも強調できるよね。その場合、CTOはもっと「戦略的」な大局的な仕事をすることが多くて、VPEが日常のSWE管理や基準設定を担当するんだ。でも、それにもいろんなスタイルがあるよね。

以前、Cレベルの人たちが一般社員と一緒に働いてる会社で働いてたことがあるんだ。ケンブリッジの優秀なEE学位を持ってる、知的な人たちだったよ。彼らは自分の強みを理解していて、自分たちが作った会社をより良い人に任せることにしたんだ。

「CTO」というタイトルには明確な意味がないからです。私たちの「CTO」はコードを書いています。アーメン。私はCTOですが、ほとんどの時間をコーディングに費やしています。中小企業に呼ばれて、彼らの基盤技術を現代にアップデートし、ワークフローを改善するためのLOBアプリを作り、最終的にはその分野で使っているEMRを置き換える新しいものを構築するために来ました。私には直属の部下はいません。臨床医や医者がいる会社で、技術者は私を含めて2人だけです。予算やレポートを作成する必要もありません。でも、その特定の会社での私の役割を考えると、このタイトルが唯一意味のあるものでした。誰かに聞かれるたびに「でも、実際にはCTOの仕事はしてないんだけど」と付け加えなきゃいけません。

また、「CTOの責任リスト」なるものがあるかのように示唆してるね。企業はCTOにxやyのポートフォリオを与えることができるけど、会社がタイトルの重要性に達する頃には、VP/EやVP/PMがカバーしない「本質的なCTOの責任」を考えるのは難しい。私が思いつく唯一のことは「組織全体のアーキテクチャの監視」で、これはかなり毒性のある役割だと思う。CTOがいろいろやってる組織では、彼らを別の形の帽子をかぶったVP/E（またはVP/PM）として考える方が通常は理にかなってると思う。まだコードを書くVP/Eについての面白い記事が書けそうだね！

特定の機能のMVPを開発して「水をパイプに通す」ために、それを他のチームに渡して「本番準備完了」にすることがある？あなたの考え方が気に入ったし、CTOがここで何をすべきだと思っているのか知りたい。

こういう「CTOは自分の好きなことをやるべきじゃなくて、責任のリストをこなすべきだ」っていうロボット的な考え方には、いろいろ問題があるよね。君は、テック企業でコーディングが高いレバレッジにならないと思ってるの？ 会社が存在する理由をもう覚えてないの？ 君の言う通り、ただ人に生活を提供して、仕事で幸せにさせるためじゃないよね。絶対にそうじゃない。会社の唯一の目的は価値を提供することだけど、その価値をROIや四半期の数字を良く見せるための曖昧な影響以外に定義できないんじゃない？ どんな会社でも、難しい機能を合理的な時間内に出荷できる開発者は少数で、その中には創業者で半分のコードを書いたCTOも含まれることがほとんどだよ。特定のコードベースでの経験が何年も必要だから、どんなことをしても、他の誰かが同じレベルに達するまでには何年もかかるかもしれないし、製品が大きくなりすぎて、もう誰もそれができなくなるかもしれない。もしCTOが1日で大きな機能を出荷できる立場にいるなら、彼らがそれをやるべきじゃないと主張するのは非常に難しいよ。彼らのスケジュールで1日をもっと価値のある使い方があるとしたら、CEOとKPIについて話し合うこと？ そんなのクソだね。これは君も気づいてるかもしれないけど、私にとっても近い話だよ。でも、時々Cレベルの人たちが trenches に戻って、サラリーマンが直面していることを感じるのは賛成だよ。彼らは第三者の意見だけで物事を解決できないからね。

テクノロジーの肩書きは文脈がないと意味がないからね（特にテクノロジーに限ったことではないけど、私たちは他の人よりもそれをよくやってる気がする）。ある場所では、私は8-9人の開発者の2つのチームを運営するシニア開発者だった（ラインマネージャーとしても日常のマネージャーとしても、さらにメンターとしても）。別の場所では「ソフトウェアエンジニアリングの責任者」だったけど、その会社には開発者が9人しかいなかった。まあ、変な肩書きのおかげで給料は上がったからそれは良かったけどね。2つのチームを管理するシニアの役割は、各チームに1人のシニアがいて、パンデミックが起きたときに製造開発チームのシニアが辞めちゃったから、私が一時的に引き継いだんだ。その後、パンデミックが予想以上に長引いて、リードの役割になったけど、正直言って各チームには能力や経験から見てシニアが数人いるべきだったのに、変な組織だったな。

私はコードを書くCTOです。部下はゼロ、従業員もゼロ、収益もあまりないです :-) 人を雇うことになったら、役割が変わると思うけど、それはあまり好きじゃないな。でも、あなたの言ってることは間違ってないと思う。

CTOの役割って、責任感や自立性が大事なんだよね。会議は必要最低限にして、みんなが次の目標を共有できるようにしてる。そこからは、チームと一緒にスプリントを進めるために頑張ってるよ。確かに、シニアリードデベロッパーみたいに聞こえるけど、小さなスタートアップだと、そういう面もある。CTOとしての役割は二重で、プロジェクトが遅れてるときは、何が原因かを見つけて解決するのが私の仕事。パフォーマンスが悪い人は解雇したこともあるし、燃え尽きそうな人を見つけて、休みを取らせてリフレッシュさせるのも私の役目。株式の約束については、最初に最大限の株を持ってるから今は満足してる。CTOにもいろんな形があるよね。

この記事は「私の仕事はコードを書くことで、CTOと名乗っている」ってタイトルでも良かったかも。これが組織にとってうまくいくなら、問題ないと思う。例えば、ビジネスの共同創業者がCEOで、技術担当がCTOっていうのもアリだし。それでも、日常的には高レベルのマネジメントをしてるのに、型破りだって言ってコードを書き続けるのはちょっと不誠実に感じる。トビアス・ルトケがまだRubyで作業しているのとはちょっと違うよね。

彼らの言い分もわかるけど、「部下がいない」ってのは、コードの責任よりもラインマネジメントの側面を指してるのかもしれない。ただ、いくつか気になった点がある。 > 新しいアイデアを推進するのはすごく重要だよ。意図的で持続的な努力が必要だから。組織構造やロードマップのインセンティブ、限られたリスク予算の中で、あまりの不確実な賭けを追求するのに数ヶ月かかるエンジニアは少ない。これはCTOが解決すべき問題だよ。 > 最近の例: 私たちは顧客のためにAIチャット製品を作ることについてずっと話してた。明らかに価値があるけど、 dauntingなタスクに感じて、チームの誰もが既存のコミットメントの中でそれを引き受ける時間と余裕がなかった。なんで？それは今一番ホットなテクノロジートレンドの一つだよ。もしあなたがAI会社なのに、誰もこれに飛びつかないなら、技術的な懸念があったのかな？誰も余裕がないなら、なんで？あなたはC-suiteの役員で、明らかに価値があると言ってるのに、なぜ誰かに数日間作業させられないの？この投稿は求人広告だけど、私には機能不全の会社の叫びに聞こえる。なぜ他の開発者はこれをできないの？なぜ時間や余裕がないの？なぜ会社が合理的だと思っている不確実な賭けを引き受ける安全がないの？ > 先月、年間100万ドルの顧客が、コンプライアンスの理由で私たちの統合の完全なデータ削除が必要だと切実に求めてきた。私たちのチームは、顧客が私たちのAPIの上に独自の統合を構築することを検討したこともあったけど、それを適切にスコープするには、製品、法務、エンジニアリングの間で多くの会議が必要だった。私は1日で動作するバージョンを作って出荷した。考えられる説明は二つある（「嘘」以外で）：1. あなたのチームには、コンプライアンスの理由でデータ削除を1日でまとめるべきではないという正当な理由がある。2. あなたの会社には、1日で出荷できる機能に対する顧客のニーズが膨大で、会社が完全におかしくなっていて、それが多部門にわたる悪夢の会議に変わる理由がない。 > 私たちは顧客サポートを変革するためのAI駆動のツールを構築していて、手を汚すことを恐れない技術者が必要です。もしこれがあなたの環境に合いそうなら、オープンポジションをチェックしてみてください。いいえ、結構です。CTOとしての役割は楽しそうだけど、貴重なタスクを引き受ける余裕や時間がないのは最悪だと思う。全体的に見ると、他の誰かがCTOで、ジョンは共同創業者でコードを書いてるからその肩書きを持ってるだけのように感じる。でも彼はソフトウェアエンジニアだ。それはいいけど、それを楽しんでほしい。大規模な戦略や他のことをやりたいわけじゃないんだから。でも、その仕事をする人は必要だよね。

一日中戦略について考えるって、どうやってるの？ ただ座って考えるだけ？

それを公に共有するつもりなの？あなたの会社の技術プロセス（あなたが完全にコントロールしている、CTOさん）があまりにも煩雑で、実行能力を著しく妨げている。これは、簡単に排除できない人が会社でやるべきことそのものだよ。中間管理職に対して、彼らが構築したプロセスがクソだと示して、納品しない言い訳を奪うこと。CEOや創業チームの他のメンバーも、営業やマーケティングに対して同じことをやるべきだよ。

土曜日と日曜日にコードを定期的にチェックしてる。保険のSaaSをやってるなら、同意するよ。でも、ハードテクノロジーを作ってるなら、全然反対だね。

週末は創業者/CTOとしてコーディングしてるけど、他の誰にも週末に仕事を期待してないし、ほとんどの人は週末にチェックインすることはほとんどないよ。創業者-CTOの職務は、個々の貢献者と重なる部分があまりないから、模範を示すのも難しいし、シニアエンジニアリングリーダーシップでも重なりは狭いんだ。最近まで[3]、以前にコーディングスキルを持っていたリーダーは、コードへの貢献を避け、管理に専念するように言われていたよ。君が言ってる理由のいくつかのためにね。-- 私は普段、自分はパートタイムのコーダーであって、プロではないって言ってるし、自分のやってることを基準やシグナルとして見ないように警告してる。私が書くコードの大部分は、内部チームのためのDevExやQoL、または誰も時間がなくて対処できない技術的負債のリファクタリングだよ。[4] 中規模のスタートアップでも、このタイプの仕事のために専任チームを投資するほど大きくないかもしれない。時々、OP[1]のような統合を作ることもあるけど、通常はデモ用のPoCで、実際の顧客向けのプロダクション用ではない。完全なツールやドキュメントなしで、他の誰かにプロダクション統合をサポートさせるのは不公平だし、失敗のリスクが高いよ。-- それは微妙なラインだし、間違った側に転ぶこともあるよね。プロダクションコードに焦点を当て始めるのは簡単で誘惑的だけど、創業者としての多くの決定がそうなんだ。私は決して最良の創業者-CTOではないけど、金属に近いことの価値は重要で、初期から中期のスタートアップではリスクを取る価値があると思う。個々の貢献者が何をしているかを理解し、結果についてもっと現実的になれるCTOにも価値があるかもしれないね、ただ上の方にいて何も知らないのではなく。-- [1] 法律をスキップするのは馬鹿げてると思う。たとえ私がそうしたいと思っても、パートナーがそれに同意するとは思えない。 [3] 今は新しいツールを試すことを奨励してるけど、それがプロダクションに貢献するわけでもないし、ICになるわけでもない。何が可能で何が不可能かを理解するためなんだ。業界では多くの夢物語が売られていて、新しいツールを使った実体験がないと、マネージャーは実現可能なことを過大評価したり誤解したりすることがあるよ。[4] これがCTOの仕事の核心で、コーディングは生産性のボトルネックになることはめったにない。生成コーディングツールが登場する前からもそれは真実で、周りのすべてが摩擦を生んでいるんだ。もしそれを減らせるなら、たとえそれをするために少しコードを書くとしても、問題にはならないはずだよ。 - 簡潔さのために編集したよ（いくつか）。

"C"は「カウボーイ」の略だよ。

組織を作ったり、人のことを考えたりするのはあまり楽しめないんだ。エンジニアリングマネジメントは、人間関係のダイナミクスやパフォーマンスレビュー、組織設計をナビゲートすることが含まれる。これらは重要な機能だけど、私の強みがあるところじゃないんだ。これ、私も共感した。リンク先の投稿からの直接の引用だよ、読んでない人のために。

あなたの仕事は、何よりもまず健全な文化を育むことです。CTOの役割は、ビジネス目標をサポートするために技術者たちを導くことですが、その文化もその一部です。健全さは主観的なものです。

それがポイントなんだよね。私や他の人は逆の反応をすると思うし、自己選択的だから、ちゃんと機能してる。記事も読まなかったよ。「つまらない、コードを書くCTOなんて特別じゃない、みんなやってるし」って思ったから。

彼はエンジニアリングチームを軽視しているようにも見える…「一日で作った」って言うのは、他の誰もできなかったって示唆してる。個人的には、顧客が必要としている機能を迅速に出荷すること自体には何の問題もないと思うけど、それについてブログ記事を書くのは疑問だね。

ゆっくり後退するだけじゃダメだ。命がけで逃げろ！予言：これはAIブームの中で崩壊する部分だ。

CTOにもいろんなタイプがいるんだから、どれが正しいとか間違ってるとか、あなたが言うことじゃないよ。