管理不要：初期段階のエンジニアリングチームにおけるアンチパターン

93日前原文(www.ablg.io)

概要

本記事は、SeedやSeries A段階のスタートアップ創業者向けのエンジニアリングマネジメントに関する提言。
初期段階では「管理」よりもプロダクト開発とユーザー対話を優先すべきという主張。
エンジニアのモチベーション管理やマネージャー採用は早すぎる場合が多い。
Google流など他社の管理手法の模倣も初期には不要。
「退屈で堅実」なマネジメントを推奨し、例外的な管理活動のみを紹介。

初期スタートアップにおけるエンジニアリングマネジメントの誤解

Seed/Series Aの創業者向けのエンジニアリングマネジメント課題への提案
エンジニアチーム構築やモチベーション管理、プロジェクトの優先順位付けなどの悩み
結論：管理に時間を使わず、プロダクト開発とユーザー対話に集中
創業者自身が管理者として振る舞うことの非効率性
よくあるアンチパターンと、より良い時間の使い方の提案

エンジニアのモチベーションを「管理」しない

エンジニアのやる気を引き出そうとする行為（長時間労働の奨励、週末ミーティング、細かな進捗報告の要求）は逆効果
優秀なエンジニアの離脱を招く文化形成リスク
本質的な問題解決ではなく、表面的な対症療法に終始しがち
モチベーションは採用段階で見極めるべき資質
創業者自身が最もモチベーション高く行動することがチームの雰囲気醸成につながる

マネージャーの早期採用は避ける

プロダクト開発フェーズでの管理職導入は時期尚早
**管理職がやるべき「管理業務」**自体が未成熟な段階では不要
最適なタイミング：20〜50名規模に成長し、現状の管理体制が限界を迎えたとき
5〜15名規模ではフラットな組織と単一リーダー体制が最適
**必要に応じてハイブリッド型（手を動かすマネージャーや非公式テックリード）**の活用

Google流マネジメントの模倣は不要

大企業の管理手法やイノベーション文化の模倣は初期段階では逆効果
「node & postgres」的な堅実で普遍的な管理手法を推奨
組織構造やタイトル、1on1の新規性にリソースを割くより、プロダクト開発に集中
初期スタートアップの文化は「顧客課題解決の速度」でユニークさを出すべき

初期段階における「退屈な」管理活動例

モチベーションの高い人材の採用を最優先
採用ミスは早期・円満に解雇し、管理でカバーしない
非同期型の進捗報告（スタンドアップやレトロスペクティブの形式的な導入は不要）
Slackの過剰利用を避け、集中時間の確保
1on1は必要時にトピックベースで実施、定期的な関係維持目的の1on1は不要
構造化されたタスク管理システムよりも、柔軟なドキュメント（NotionやGoogle Docs）を活用
極端な透明性の実践（顧客ノート、投資家レター、予算など全員に公開）
これらの手法は20〜25名規模まで有効、それ以上では再検討が必要

まとめ

初期スタートアップの本質は「管理」ではなく「実行と学習」
管理コストを最小化し、優秀な人材と共にプロダクト価値を最大化
組織成長に伴い、管理体制の見直しを段階的に検討
最も重要なのは、創業者自身の率先垂範と、持続的なモチベーション維持

Hackerたちの意見

996スタイルの文化について読むと、ヨーロッパ人でよかったなって思う。ここでは無理だよ。週40時間が上限で、ほとんどのエンジニアは週32時間以上働きたくないからね。だから、いいワークライフバランスが保てる。今は週に4時間しか働いてないよ。

└

初期段階のスタートアップで働く必要はないよ。実際、大多数の人はそうしてないし。でも、初期段階のスタートアップに参加したい人もいるし、ヨーロッパでもたくさんいるよ。 > だから、いいワークライフバランスが保てる。今は週に4時間しか働いてない。だから、私がPMだったとき、アムステルダムのオフィスを閉鎖して、プラハ、ブカレスト、ワルシャワに移転したんだ。週40時間働いて€80kの報酬を得ることに文句を言う人はあまりいないよ。

└

だから、ヨーロッパではますます少ない企業が採用しているんだ。

└

アメリカでは全員が996ってわけじゃないけど、ここには悪いマネジメントのパンデミックがあるよ。というか、悪いマネジメントというよりも、数万のエンジニアを抱えるアマゾンのプロジェクト管理についての記事を読んだ人たちが、自分たちの4人のスタートアップも同じように管理しようとすることが多いんだ。彼らはそれを「グロースハッキング」だと思ってるからね。アメリカのテックスタートアップは、しばしば相続税を回避するための手段に過ぎないし、VCマネーを夢を売ってより大きな愚者に変えるための手段でもある。もちろん、デメリットもあるよ。

└

>「今、週に4時間働いてるよ。」どこの雇用主が4時間の契約を出すの？

└

4はめっちゃ低いね。ちょっと異常だと思う。お金持ちか、コストがすごく低いか、時給がめちゃくちゃ良いか、もしくはそのティム・フェリスの本をうまく活用できた一人なんじゃないかな。

└

EUにいるけど、これがほとんどのエンジニアを表してるとは思わないな。ここでも過労文化があって、たくさんの会社に利用されてるよ。

└

これってどういうことなの？報告するのに4時間分の仕事があるってこと？4時間以上の給料もらってるの？こういう全然理解できない発言をする人がいると、すごく気になるんだよね。

└

この記事から誤解しないでほしい。996はアメリカでは非常に稀だよ。アメリカのエンジニアのほとんどは、普通の40時間労働をしてる。

モチベーションが生まれつきの特性だってのは明らかに間違いだと思う。それは、脱モチベーションも生まれつきだってことを意味するし、それはもっと明らかに間違ってると思う。

└

人を脱モチベートするのは難しくないよ。でも、ここがポイントなんだ…みんなが同じことでモチベートされるわけじゃない。マネージャーとして人をモチベートするコツは、彼らが何にモチベートされるかを見極めるために時間をかけることだよ。そして、もし脱モチベートすることだけができるなら、最終的にはチームの全員が脱モチベートされちゃうんだ。

└

27歳で人を雇う頃には、モチベーションにかなりの差が出てくると思う。25年の経験（それは雇う人にとって「内在的」なものだよね）は、特に人生の初期には大きいよ。うつ病や皮肉、過去の経験など、モチベーションの基準が低くなる要因はいろいろあるしね。これも文脈によると思うけど、それが君が言ってることだと思うし、100%同意するよ。ある人は役割Aで活躍するけど、役割Bでは壁に頭をぶつけたくなるかもしれない。逆も然り、どちらでも「まあまあ」な人もいるしね。

└

人をやる気をなくさせるのはすごく簡単だと思う。ディルバートの漫画に出てくるPHBを見てみて。だけど、人をやる気にさせるのも簡単だとは限らない。両者は同じじゃない。人をやる気にさせるには、彼らの心理や価値観、人生から何を望んでいるかを理解して、その知識を使って職場文化を作る必要がある。やる気をなくさせるのは、それを理解しないか、自己中心的な心理を優先するだけで済むから、ずっと簡単なんだ。

└

やる気は内発的なものと外発的なものに分けるのがいいよ。内発的なものは内側から来るもので、遺伝的な性格特性として説明されることが多い。外発的なものは、通常お金や報酬、ポジティブなフィードバックなどの外部要因から来る。やる気を失うのは、ほとんどの場合、管理が悪いせいだと思う（メンタルヘルスの問題は別として）。

> モチベーションは雇われた特性だ。マネージャーが人をモチベートするのは、マネジメントの本の中だけだ。初期のモチベーションは雇われた特性だ。人を脱モチベートするのはとても簡単なんだ。そのトリックは、そうならないようにすることだよ。

└

そうだね、みんな色んなモチベーションの源があるよね。一番のポイントは「所有感」だと思う。多くの人が大企業じゃなくてスタートアップに参加するのは、そこで声を持ったり影響を与えたりしたいからなんだよね。これを認識しないで、創業者やマネージャー、リーダーが台無しにしちゃうのをたくさん見てきたよ。もちろん、モチベーションのある人を見つけて雇うことはできるけど、特定の問題に対してその人たちがモチベートされる保証は全くないんだよね。

└

「人をやる気をなくさせるのはとても簡単」本当にその通りだよね。逆転させるのはすごく難しいし。

└

「雇われた」という言葉には色んな意味があるね。モチベーションはその人に内在するものなのか、それとも人と状況の組み合わせなのか。それとも人、状況、そして理由（面接での理由）なのかな。面接プロセスで「ハッ」とする瞬間があったときが一番モチベートされてた気がする。あるいは「クール！」って感じ。私にとっては、技術スタックよりも最終製品に関することが多いかな。自分が使いたいものに取り組むのが好きなんだ。

└

著者と同じ「モチベーション」の定義を使ってるわけじゃないかもしれないけど、チームの人が何にモチベーションを感じるか理解して、適切な人を集めて正しい問題に取り組ませること、そして人を最善のパフォーマンスに導くために圧力をかけるタイミングを知ることは、マネージャーがチームをモチベートするためにできることだよね。

└

悪いマネージャーは素晴らしい社員を普通の社員に変えちゃう。そうなると、元に戻るのは本当に難しいよ。

└

それ、100%同意！マネージャーとしての自分の哲学の一つは、基本的に邪魔しないことだと思ってる。そこから、一番大きな問題を特定して解決する。優秀な人を雇うことに成功してるなら、なぜマイクロマネジメントしたいのか全然理解できない。996みたいなやる気を削ぐようなことをしたり、彼らを誤解させたり、マーケティングしたり、悪いことを隠したりするのは馬鹿げてるよ。人を大人として扱うのが、インフルエンサーのブログが教えたくない「一つの秘訣」なんだ。

└

「従業員は仕事を辞めるんじゃなくて、マネージャーを辞めるんだ」ってよく言ってた。アマゾンではすごく楽しかったけど、最適じゃないマネージャーの下に移動させられて、1ヶ月も経たずに辞めた。そのマネージャーは昇進したけどね。これがアマゾンで働くことについて知っておくべきことだよ。もしかしたら、辞めさせようとしてたのかも。あるいは、そのエリアのディレクターが無能だったのかも。両方かもしれないけど。

> 15人のエンジニアがいれば、一人の人がみんなの仕事を把握して調整するのは十分可能だ。私の過去の経験は全く違うけどね。確かに15人のエンジニアがいるけど、150人のビジネスをサポートしてるんだ。これはかなり一般的な比率だよ。その規模になると、ノイズがすごく大きくなって、自主管理のエンジニアが前に進むのはほぼ不可能になる。少なくとも、所有権の境界を超明確に定義する必要がある。それはビジネスプロセスやワークストリームの所有権のことで、コードの所有権じゃないんだ。

└

チーム構成については『神話のマン・マンス』を読む価値があるよ。ブルックスが新しいことを言ってるわけじゃないけど、チームをどう構成するかの良いアイデアを見つけるために人々がどれだけ長い間試行錯誤してきたかの視点を得られるからね。

└

+111111 マネージャーが15人の直接報告を持つのは効果的じゃないと思う。物事を維持するのは可能かもしれないけど、そのチームを半分に分けて別のマネージャーを雇った方がずっと良い状況になるよ。ここでよく起こるのは、チームの最もシニアなメンバーがICの仕事をする代わりにマネジメントの責任を引き受けてしまうこと。もちろん、メンターシップや方向性、文化などには貢献すべきだけど、15人のエンジニアを深く理解するにはやりすぎだよ。リーダーがダメな時だけ、こういう状況が起こると思う。報告が多すぎると、マイクロマネジメントが難しくなるけど、他の面で邪魔をしてる可能性もあるよね。

└

そうだね、15人は多すぎる。プロジェクトが同時にいくつあるかにもよるけど、10人でもギリギリな感じがする。

└

僕の経験則では、マネジメントの複雑さは「直接の部下の数 × プロジェクトの数」で決まるんだ。プロジェクトはステークホルダーのセット（PMとか、ビジネスによって変わるけど）として定義される。具体的には、1人のPMがいる明確なプラットフォームチームで12人のICを管理するのは、6つのビジネスで働く6人を管理するよりずっと簡単だよ。データサイエンティストのチームを管理する時によくあるパターンだね。

> 私はバレーでトップ1%のエンジニアを何人か知っているけど、996やそれに似たことが言及されると、リクルーティングプロセスから disengage しちゃう。数年前、この掲示板で、996は中国の企業がやってるって報道されたときに、みんながそれを笑いものにしてたよ [1]。で、今、このブログが主張できる最強のことは、アメリカの一部のエンジニアがリクルーティングから disengage するってこと？土曜日に働くことの問題がデイリースタンドアップだって？この数年で何があったんだろう、こんな変化が起こるなんて？！ [1]: https://news.ycombinator.com/item?id=19507620

└

何が起こったの？マスクが半分のスタッフをクビにしたところから始まったね…。この業界に長くいるから、振り子が何度も行ったり来たりするのを見てきたよ。2020年/2021年のピークは「甘やかされたテックワーカー」の典型だったけど、今はもう反対側に向かってると思う。

└

何が起こらなかったかを見る方がいいよ：労働組合化。アメリカ人は、スティーブ・ジョブズがダイエットや鍼治療で癌を治そうとしていたことを思い出させることが多い。解決策は分かってるのに、それが気に入らないだけなんだよね。

└

996は赤信号だってリクルーターに直接言うよ。前は、クラックした（旧10x（旧ニンジャ））エンジニアとかシグマグラインドセットとか、そういうのが多かった。パフォーマンス重視なんだよね。人を集めて、彼らが本当に大事だと思うものを作らせれば、恐れから働くグループよりもパフォーマンスが良くなるよ。バズワードばっかりの人たちよりも、絶対にね。

└

> そして今、このブログが主張できる最も強いことは、アメリカの一部のエンジニアがリクルートから disengage するかもしれないってこと？その発言は特にシリコンバレーのトップ1%のエンジニアについてのものだよね。それはアメリカのエンジニア全体の中では非常に小さなサブセットだ。シリコンバレーの才能の尖った部分は、仕事が人生であるエンジニアが多いから、すごく変わった場所だ。オフィスに住んで、24/7働く同僚がいるのが好きな人もいるかもしれない。これを肯定するわけじゃないし、一般的だとも言わない。一般的ではないよ。ただ、才能の分布の極端な外れ値に絞ると、仕事に対して非常に執着している人がたくさんいることがわかる。彼らの仕事は、株式を含めて年収100万ドル以上だから、好きなテーマでエネルギッシュな人たちと数年996するのは悪い取引じゃない。一般的に、リクルーターが普通のエンジニアに996が期待されると言ったら、その会話は終わりだろう。アメリカの普通のエンジニアは、普通の報酬で996には参加しないから。

└

雰囲気が変わってきてる。もし僕の投稿履歴を遡る時間があったら、2021年や2022年には、労働組合を作ったり、労働者協同組合を築くためにできることは何でもやるべきだと大声で叫んでたのがわかるよ。でも、その時は誰も気にしてなかった。毎回叩かれてもそれはそれでいいんだけど、今は雰囲気が変わってきてる。これに対処するのはイライラするけど、この話題でヘクターになるのは入場料みたいなもんだと思ってる。ペースや規模、リーダーや組織の欠如にすごく不満を感じてるから、次の2年は本当に厳しいと思う。でも、みんなが目を覚まして何かに影響を与えられる規模になることを期待してるけど、あまり期待はしてない。僕が言ってるのは本当のアクティビズムじゃないと思うけど、少なくとも雰囲気が変わってきてるのは実感してるよ。

└

ある時期、アリババで働いてたことがある。次の文には気をつけないといけないんだけど、ネットでは人々が文脈を無視して最悪の解釈をすることが簡単だから、そういうことはしないでほしい。996の時間は生産的な仕事じゃない。見た目だけの生産性だよ。

モチベーションが必要なら、組織の設計が悪いのかもしれない。ローマ軍団について「軍団は英雄で構成されているわけではない。英雄は軍団が倒すものだ」と言われたことがある。第二次世界大戦で中国・ビルマ・インド戦線を指揮したスリム元帥は「戦争は普通の部隊の平均的なパフォーマンスで勝つ」と書いている。彼は特殊部隊について否定的で、普通の歩兵を使って、超人的ではないけど良い基準まで育てることを好んだ。ニュージャージーで労働組合を持つトラック会社を経営していたアーサー・インペラトーレは、「Perfecting a Piece of the World」（1993年）で、普通の労働力でもトラック会社を成功させた方法が紹介されている。着実に管理された進行で勝つという主張もある。管理がうまくいくのは難しいけどね。スティーブ・ベクテルは、自社の限界は現場に出て実行できるボスを見つけることだと言っていた。失敗は管理の問題であって、労働者の問題ではない。

└

この投稿はすごく小さな会社について話してるね。20人以上の部署では確かにそうだ。創業者が全員を知らないチームになると、平均が重要になってくる。15人のチームがあれば、15人を雇って、うまく雇えば自然に組織できる。質問があれば、みんなが何をやっているか分かっているし、コードベースも小さいから、ドキュメントが悪くてもみんなで解決できる。グループが大きくなるほど、全員が仕事をするために必要なコンテキストを持っているか確認するのが大変になる。そこで管理が重要になるんだ。正直、私が最初のマネージャー（17人のチーム）として入ったとき、私はコードを書いたり、自分のプロジェクトを進めたりしながら、「スケールするために何をする必要があるか」を考え始めていた。17人のチームに私のような人を入れるのは、すぐにスケールが必要になるからで、次の段階の問題を解決するための最初のプロセスを構築する必要があるからなんだ。間違ったやり方をすると、すべてが悪化するからね。

└

軍隊では「望む軍隊で戦うんじゃなく、持っている軍隊で戦う」と言われていた。そのため、訓練や計画に多くの努力が注がれた。ほとんどの戦闘部隊の役割は、チームの大半が decent なレベルで動く必要がある。多くの訓練の背後にある考えは、最もパフォーマンスが悪い人たちのレベルを上げれば、全体のユニットパフォーマンスが劇的に改善できるかもしれないということだ。マーケティングマネージャーの言葉で言うと、戦闘部隊の多くのタスクでは、個々のパフォーマンスは満足度を高めるもので、驚かせるものではない。ユニットの一人が悪い仕事をすると、ユニット全体が失敗する。みんなが「まあまあ」な仕事をすれば、ユニットは失敗しない。その二つの結果は劇的に違う。でも、みんなが「まあまあ」なユニットを持っていて、全員を特別にしようと努力しても、パフォーマンスの向上は感じられないだろう。ソフトウェア開発に置き換えると、ユニットに誰を雇うかをもっとコントロールできる。でも、誰にでも悪い週やスキルのギャップがあるから、訓練（人に時間を与えて勉強させたり、テストプログラムを書かせたりするだけでも）も重要になる。ラインの軍隊のように、開発チームが計画通りに機能するためには、全員が全力を出さなきゃいけない。能力はあるけどパフォーマンスが低い既存の開発者にスキルアップに投資する方が、最高の開発者を超スキル化するよりも良い戦略かもしれないし、彼らを解雇して、より生産的になれる人を見つけるのを期待するよりもね。冗談を言うと、アマゾンで私のマネージャーは私が元軍人だと知って、「おお！君は海兵隊員だったの！？軍隊のようにチームを管理したい」と言った。でも、私の返事は「何！？予算の80%を訓練と物流に使いたいの！？」って言っちゃった。それはその状況で言うべきことじゃなかったかも。あと、軍のメタファーを製品開発に適用するなら、ジョン・ボイドのOODAトークを調べる価値があるよ。全部に同意するわけじゃないし、直接的には適用できないけど、読む価値はあると思う。ボイドは私の父の友人だったから、子供の頃に会ったときは彼がクレイジーだと思ったけど、彼は確かに知的なアウトサイダーで、成功することが多かった。

どうやら、面接官を精神分析医にする流れに戻ってるみたいだね。採用時にモチベーションを見極める具体的な方法については別の投稿で詳しく書くけど、簡単に言うと、以下のポイントを探してみて。まずは明らかなやつ：過去の仕事で無理なくモチベーションの外的なサインを示していた証拠。キャリアや人生の中でのグリットのサイン（逆境にどう対処したか、過去の成功や評判を新しい挑戦のためにどう活かしたか）。趣味や熱中できるオタク的な興味を通じた知的好奇心。これがうまくいくとは思えないし、「趣味やオタク的な興味を通じた知的好奇心」を探すのは逆効果だと思うけど、みんなでコードを一緒に書く時間にSlackチャンネルを活気づけるにはいい方法だね。

└

10年前、モチベーションの代理としてオタク的な興味や趣味で採用するアイデアに賛同してた。確かにその時、素晴らしい人たちに出会ったけど、振り返ると、同じ人たちはその実績で普通に採用されてたと思う。> みんなでコードを一緒に書く時間にSlackチャンネルを活気づけるにはいい方法だね。ちょっと辛口な意見だけど、これは100%僕の経験と一致してる。オタク的な興味や趣味でたくさんの人を採用すると、会社のコミュニケーションがオタク的な話題で溢れちゃう。一方で、「つまらない」人たちはコードを出して家族（ペットでも何でも）に帰るために頑張ってる。オタク的な興味や趣味は仕事の能力を示す良い指標じゃない。オタク的な興味や趣味だけで誰かを採用するのは多分、赤いニシンだね。大事なことに集中しよう。

> モチベーションは雇われた特性だ。マネージャーが人をモチベートする場所はマネジメントの本だけだ。これ、全く間違ってると思う。正直言って、これが間違ってると、この記事全体の信頼性が疑わしくなる。1. 僕は確かにマネージャーにもっと頑張るようにモチベートされたことがある。逆に、完全にモチベーションを失わせて辞めさせられたこともある。業界で働いたことがある人が「マネージャーが人をモチベートする場所はマネジメントの本だけだ」なんて言えるのはどういうこと？ 2. もちろん、この記事で言われてる簡単な戦略（996やマイクロマネジメントなど）はほとんど機能しないよね。この記事はこれをすべての戦略に一般化してるけど、「ひどい方法が解決できないなら、他の方法も無理だ」というのはせいぜい不安定な主張だと思う。良いマネージャーはこれを理解して、君がやっていることがチームや会社の成功にどれだけ重要かを理解させることでモチベートする。（会社の成功に興味がないなら、モチベートするのは難しいだろうね。）悪いマネージャーは、君の努力が完全に無駄だと感じさせたり、なぜそれが重要なのかを説明できなかったりする。

└

じゃあ、そのマネージャーたちは君をどうやってもっとモチベートしたの？

└

自分は、マネージャーからのやる気を失う経験しかしてないな。少なくとも自分にとっては、やる気はオーナーシップ、影響力、自立、リスペクトから来るんだよね。やる気を失う方法はいろいろあるけど、逆にやる気を引き出すのは、すでにやる気を失わせてる場合じゃないと難しい。やる気を失わせる例を挙げると、 - 自分や同僚を自分のミスのせいにする - 他の人の仕事を自分の手柄にする - すでにやる気があるのに「やる気を出させよう」とする - 緊急感を作り出す、これが続くと特に最悪 - AIや市場の状況を使ってチームを脅かす - 明らかにコネを使うこんな感じで、まだまだ続けられるけど、思いつくのはこんなところかな。

└

そうだね。やる気って本当に気まぐれなものだよ。多くの開発者がゲームに惹かれる理由は、火を吹くモンスターや肌が白いセミヌードの人魚じゃなくて、ユーザーの要求が変わらないままタスクを最初から最後までやり遂げる体験なんだ。リーダーやマネジメントとして、自分の最優先事項は、(a) 目標を明確にすること (b) チームが余計な気を散らされずに仕事できる環境を作ること (c) その「必要な」気を散らす要素を減らすことこれって本当に難しいし、感謝されないことも多い。自分は夜警のような存在を目指してて、チームが「何もしてないのに給料もらってる」と思ってくれるとすごく誇らしい。でも、構造が大きくなるほどドラマも大きくなって、そんなのには関わりたくないんだ。一方で、利害関係者が「さあ、もう高層ビルを建てたんだから、駐車場を地下から2階に移動するだけでしょ、そんなに難しいことじゃないよ、全部揃ってるんだから、ただ動かすだけでいいんだよ」って言ってくるのに苦しんでる。

└

もう30年以上働いてるけど、マネージャーにやる気を失わされたことはあっても、やる気をもらったことはないな。唯一もらったのは、自由に働けるスペースを確保してくれたことだけ。やる気は常に内面的なものだった。自分もマネージャーだけど、誰かをやる気にさせることはできなかった。彼らがやりたいと思っているならうまくいくけど、やる気は自分の中にあるものだと思う。もちろん、これは一人の意見だから、感じ方は人それぞれだね。

└

その手の本は、やる気よりも説得についてのものが多いよね。遠くから見ると似てるように見えるけど。

└

あなたの言う通り、著者は要点を明確にするためにキャッチーなフレーズを入れようとしたけど、失敗してるね。著者は、オーナーシップの価値を示した早期のエンジニアを雇うことを主張してるんだ。そういう人たちのために「極端な透明性」を確立する（投稿の後半を見てね）、他の人と高レベルの計画を合わせるためのGoogleドキュメントや、カジュアルに話せるキッチンを用意して、あとは彼らの邪魔をしない。そういう環境は、特定のタイプのエンジニアにとっては本当にやる気を引き出すものだよね。もちろん、これが大企業にスケールするわけじゃない。最終的には、キッチンに料理人が多すぎる。実際、大多数のエンジニアは、何をすべきかを正確に指示してくれる人を求めてるから、彼らは構造化された9-5の仕事に来て、家のローンを払って家族を養うための給料を得たいと思ってる。著者の提案は、大企業やほとんどのエンジニアには当てはまらないし、著者もそれを明確にしてるね。

└

> 良いマネージャーはこれを理解し、あなたがやっていることがチームや会社の成功にどれほど重要かを理解させることでやる気を引き出す。あなたの「良いマネージャー」の定義は、基本的に「部下の仕事を積極的に妨害しない人」ってことだね。それはやる気を引き出すことじゃなくて、単にやる気を失わせないことに過ぎない。自分の仕事がユニットや全体の成功にどう貢献しているかを知っていることは絶対的な基本で、それを知らないなら、マネージャーが無能か、敵対的であるかのどちらかだよね。あの「福利厚生」欄に「給料が時間通りに支払われる」なんて書いてある求人広告を思い出す。それは福利厚生じゃなくて、そんなのは基本中の基本だから、そんなことを言うこと自体がその会社のすべてを疑わせるよ。

└

自分は両方の経験があるけど、やる気を引き出すのは本にしか書かれていないマネージャーではないと思う。毒のある機能不全のチームを修復できるマネージャーが必要なんだ。毒のあるチームは、結局良いマネージャーを壊してしまって、彼らは問題の一部になったり、去ってしまったりする。『フェニックスプロジェクト』に出てくるヒーローマネージャーは神話だと思うけど、やる気を引き出すマネージャーは本当に存在すると思う。ただ、彼らも他の人と同じように良いプラットフォームが必要なんだよね。

良さそうに聞こえたけど、具体的な例が出てきたら… > 「採用時にモチベーションを見極める具体的な方法について、投稿を専用に作るつもりだけど、要するに、面接を受ける側が全てをゲーム化するのを見極めることが大事。これがHNのフロントページに載る頃には、もう午後だ。」（例えば、テック面接の準備では、何年も前から人に情熱や好奇心を偽るように言ってるしね。）やるべきことはこれだ： 1. 早期のスタートアップは、初期の雇用者にも属しているってことを考えよう。彼らのスタートアップでもあるんだ。君が最終的な決定者だけど、君だけのスタートアップじゃない。彼らのものでもあってほしい。これを信じて、そう行動しよう。 2. それを株式の分配に反映させよう。「0.5%」なんて、オプションとして希薄化される上に、行使を抑制するISOルールがある… 一方で共同創業者たちは70%の創業者の実際の株を分け合ってる… これは、君が同じくらいモチベーションを持ち、貢献してほしいと思う創業エンジニアにとってはナンセンスだ。 3. 本気で株式を渡すなら、給料は少し低めに設定しよう。家族の生活費として全く無理なほど低くはしないけど、会社の成功にコミットしていない人や、実際に会社を信じていない人を自動的にふるい落とせるくらいには低く。 4. 実際に期待できる会社と創業チームを持っていないと、経験豊富な人たちが集まらないよ。

└

ちょっと皮肉っぽいけど、これ全部公平に聞こえるよ。控えめな報酬と良い株式分配は、候補者がゲーム化するのも難しいしね。

モチベーションについての話はナンセンスだ。 1. モチベーションは感情で、来たり去ったりするもので、ボーナスみたいなもの。大きな違いを生むのは、規律とプロ意識だ。多くの人が「自分のプログラミング言語を作りたい」とか、「スタートアップを立ち上げたい」とか、「NBAに行きたい」とか、「40ポンド痩せて健康になりたい」と夢見てるけど、そのモチベーション、感情は、楽しむことやリラックスすること、友達と遊びに行くこと、ストレス解消のためにゲームをすることへのモチベーションと常に戦ってる。モチベーションは規律とプロ意識を高める素晴らしい助けだけど、その二つはモチベーションが消えても生き残る。 2. モチベーションで人を雇うことはできないし、その特性を求めているなら、自分のバイアスを投影することになるだろう。ブログの著者はオタク的なホビットだから、候補者に自分を投影してるんじゃないかな。ナンセンスだ。確かに、オタクなエンジニアはクラフトや全体的なエンジニアリングに興味があるかもしれないけど、それがB2B SaaSを作ることに対するモチベーションとは全く関係ない。 3. スタートアップに参加する優秀なエンジニアは、数年で金持ちになりたいという暗黙のモチベーションを持っているべきだ。そうでなければ、もっと給料のいい楽な仕事に就くはずだから。

ハクソク