「議論する価値のないバイクシェッドだから」と言った方がいいかも。正しい答えがないことも多いけど、決断は必要だよね。

これは私が苦労して学んだ教訓だよ。初めてのマネージャーの時、全てのことについて合意を築こうとして、自然にみんなが同意するだろうと考えてた。最初は良いチームでうまくいったけど、その後、他のチームの一部を引き継いで、すべての現代のものはゴミだと思っている知ったかエンジニアたちがいて、25年前のやり方でやるべきだと言ってた。彼らが全てをストーンウォールするのを許しすぎて、最終的には合意に達するだろうと思って無駄に時間を使ってしまった。ある時点で、彼らの意見を聞いた後は、しっかりと足を踏み入れて方向性を決める必要があることに気づくんだ。

スティーブ・ジョブズは、チームを部屋に閉じ込めて共通のビジョンに到達させることで知られていたよね。みんなを揃えるのは難しいけど、私の限られた経験では、そうしないとすごく非効率な実行になっちゃう。さらに言うと、意見を無視されると人は小さく感じたり、拒絶された気分になるんだよね。時には人の気持ちや考えを無視してでも物事を進める必要があるけど、それを長続きさせるのは無理だよ。

いい指摘だね。「みんなの意見が聞かれる」と「みんなに拒否権がある」ってのは大きな違いがある。決定を下すのはリーダーの仕事の一部だよ。もちろん、すべての問題でリーダーが決定を下さなきゃいけないなら、マネジメントかインセンティブの問題か、あるいはみんなが戦略を理解していないってことだね。

時間はかかったけど、F50での仕事を始めて数年後に、ドメイン内でバスナンバーが3の状況に直面したんだ。解決策Aは見た目は良さそうだけど、実際はひどいことになるってみんな知ってた。でも、チームの他のメンバーはそれに夢中で、私たちの理論的な説明は全然説得力がなかった。人気投票の結果、ちょっとした緊急事態が増えて、いくつかの部門が遅れちゃうことになり、最終的には上司に相談して投票を無視することになった。これをうまく収めようとしたとき、決定の影響を受ける人たちが解決策Cを望んでいて、他のみんなが解決策Aを望んでいるってことに気づいたんだ。未来の決断において、実際に影響を受ける人たちが人気投票に拒否権を持つ必要があるってことを覚えておく価値があると思う。プロジェクトの勢いを失いたくないならね。大きなプロジェクトでは、異なるドメインを担当するリーダーがたくさんいて、彼らは主要なアーキテクチャの決定、特にコンウェイの法則に基づくモジュール化の間のインターフェースについて合意に達するんだ。上司は合意が得られないときだけ決定を下せばいい。ほんとに「必要」なんだよ。私が今までで二番目にひどい上司は、決定を下すことを拒否して、リーダーが偶数だったから、何度も同じことが起こった。毎月数時間、彼についての不満を言い合って、ある参加者は本当に彼を殺したいと思ってたし、私たちに遺体を隠す手伝いを頼もうとしてた。

「俺がリーダーだから、こうやってやるぞ」 「わかった。終わったら教えて。」

みんながあなたがしているトレードオフの理由を理解できるようにしないとダメだよ。それに、もしあなたが間違っていて彼らが正しかった場合、あなたが責任を取るってことも伝えないと。

100%同意。素晴らしいリーダーのもとで働いたことがあるけど、彼は優秀なエンジニアたちを率いていた。でも、ソクラテス式の方法にこだわって、考えさせる質問をして私たちに解決させようとしてた。重要な議論がぐるぐる回って、イライラすることもあった。時には、決断を下す必要があるよね。

人間は時々、リーダーにしっかりしてほしいと思うことがある。静かな人たちは、進展ができるようにおしゃべりな声を黙らせてほしいと思ってるかもしれない。そして、おしゃべりな人たちは自分のスキーが前に出すぎて、引き下がる優雅な方法がわからないから、リーダーが間違ったときに「ほら、言ったでしょ」って言う準備ができてても、閉じ込められるのもまあまあ受け入れちゃうんだよね。

「みんなを幸せにしたいなら、リーダーにならない方がいい。」これが一番大事な言葉だよ。誰かの気持ちを傷つけることを恐れちゃダメ（もちろん、意図的にではなく、できるだけ優しくね）。みんなを幸せにしたいと思ってたら、何も進まないから。

これは受け入れるのが難しい教訓だけど、理解しなきゃいけない。地元でこの問題を解決するための努力がもっとないように感じて、まだ少しフラストレーションが残ってる。例えば、一般的には聴衆に話しかけて感情的なアピールをする必要がある。でも、上司である私がそれを超えて事実に基づいて働く方法を理解するべきだと思う。少なくとも可能な限りはね。それがあまり見られないんだ。

もっといい聴衆を得る必要があるよ。最近、コロナは嘘だと思っている良い開発者に会ったけど、できるだけ避けるようにしてる。彼の周りを丁寧にやり過ごせると思ってるかもしれないけど、それがワクチン懐疑論者がCDCを崩壊させる原因になるんだ。

方向性としては合ってるけど、完全に正確とは言えないと思う。もっと正確に言うと、あなたの聴衆は事実を意思決定基準に変えるための経験や文脈を持っていないってことだね。「生のデータ」を「消費可能な洗練された事実」に翻訳する必要がある。それが良いコミュニケーターの役割だよ。元の言い回しだと、決定が事実に基づいていないか、感情的であるかのように聞こえて、目をひっくり返したくなる。

目をひっくり返したくなるのもわかるよ。だって、これは大きな単純化だからね。事実で人を納得させる状況は決して珍しくないし。その人は、特に役に立つわけでもない人気のフレーズを繰り返してるから、目をひっくり返されてるんだと思う。

倫理、論理、感情が必要だね。論理だけじゃダメだよ。

それって、ただのずる賢い感じがして、信頼を壊すだけだよね。

代わりに何をするの？

航空宇宙の世界では、「システムエンジニア」って呼ばれてるよ。リードの役割は、1: システム全体を理解してるけど、細かいところまで知ってるわけじゃない。2: プロジェクト全体を計画すること。編集: ソフトウェアの世界では、タイトルが「アーキテクト」ってこともある。これって、階層やキャリアアップのための人工的な昇進にこだわる組織以外では、あまり「マネージャー」にはならないことが多い。マネージャーは通常、人やスケジュール、リソースに関心があって、技術的な問題にはあまり深く関わらない。でも、リードとマネージャーは、どちらかが休暇中、病気、辞めた時なんかにはお互いに補完し合うこともあるよ。