ポッドキャスト：AI時代におけるマインドフル・リーダーシップ
シリコンバレーベテランのSam McAfeeは、AI時代のリーダーシップにおいて、成功による組織の亀裂を修復し、実験的マインドセットとレジリエンスを融合させる必要性について語っている。
キーポイント
「Day Two」の課題と組織の亀裂
Sam McAfeeは、スタートアップや企業が成功し成長した段階（Day Two）で、かつての成功要因が機能しなくなり組織に亀裂が生じることを指摘し、その修復のためにリーダーシップ介入が必要だと主張する。
実験的マインドセットの重要性
大規模な設計 upfront（Big Design Upfront）に代わり、アジャイルやリーンスタートアップに基づく反復的な開発と実験的アプローチが現代の製品管理の基盤となっている。
AIとリーダーシップの融合
Sam McAfeeはAI主導のリーダーシッププラットフォーム「Humanize」を共同設立しており、現代のプロダクト開発とマインドフルなリーダーシップ、組織変革を統合するアプローチを提示している。
大企業における新規事業の阻害要因
規模拡大に適した組織構造、プロセス、文化は、新規事業の創出において摩擦を生み、既存の「ビジネス・アズ・-usual」スタイルのリーダーシップとプロセスが新 initiatives を支援・保護するのを困難にする。
大企業とスタートアップのリーダーシップの違い
成功している大企業が新製品や収益源を追求する際、既存事業の維持に最適化された組織は、スタートアップのような効果的なリーダーシップやプロセスに適応できず、新旧の間で大きな軋轢が生じる。
投資判断における規模の誤解
多くの大企業は革新を促されても、経済的な思考単位が大きすぎ、「10億ドル規模のプロジェクトでなければ関心がない」というような極端な投資判断を行い、初期段階の小規模な試行錯誤を軽視する傾向がある。
大企業におけるイノベーション手法のシフト
大規模組織はスタートアップのような内製イノベーションが困難だと認識し、M&A（企業買収）を通じて革新を実現する傾向が強まっている。
影響分析・編集コメントを表示
影響分析
この記事は、AI技術そのものよりも、それを導入・運用する組織文化とリーダーシップの在り方に焦点を当てています。AIがもたらす変革を成功させるには、技術導入だけでなく、組織の成熟度に応じたリーダーシップの変容と、失敗を許容する実験的文化の定着が不可欠であることを示唆しており、技術リーダーにとって重要な示唆を含んでいます。
編集コメント
技術トレンドの解説ではなく、AI導入における「人」の部分、特に組織変革とリーダーシップの重要性を論じた貴重な対談です。技術選定だけでなく、組織文化の整備がAI成功の鍵であることを再認識させます。
トランスクリプト
イントロダクション [00:37]
トーマス・ベッツ：こんにちは、The InfoQ Podcast へようこそ。私はトーマス・ベッツです。今日はサム・マカフィー氏にお話しを伺います。サムはシリコンバレーのベテランで、25 年以上にわたり技術組織を率いてきました。グローバル企業からスタートアップまで、幅広い相手と協力してきました。サムは『Startup Patterns』という書籍の著者であり、創業者や経営者がレジリエントで高パフォーマンスな組織を構築できるよう支援するリーダーシップおよび戦略ファームである Startup Patterns 社の創設者でもあります。また、AI を活用したリーダーシッププラットフォーム「Humanize」の共同設立者でもあります。サムの専門知識は、現代的な製品開発、マインドフル・リーダーシップ、そして組織変革が融合しています。
サム、The InfoQ Podcast へようこそ。
サム・マカフィー：お招きいただきありがとうございます。とても楽しみです。
トーマス・ベッツ：それでは、あなたの経歴には多くのことが書かれていますが、具体的にサムさんは何をしているのでしょうか？通常、どのようなタイミングで組織に招かれ、どのような目標を掲げるのですか？
サム・マカフィー：通常、私は初日から関わるわけではありません。昔ながらの手法による初期段階のスタートアップや市場参入戦略については多くの経験があります。しかし最近では、ある程度の成功があり、事業が成長してさまざまな問題が発生し始めた後に招かれることが多いです。つまり、「日付 2」のようなタイミングですね。かつては機能していたことが、成功の結果として、あるいは様々な理由から基盤にひび割れが生じ始めた時こそ、私が招かれる時なのです。
スタートアップ対エンタープライズ：大企業がイノベーションに苦戦する理由 [02:04]
トーマス・ベッツ：はい。ここに至るまでの成功要因が、未来へ導く鍵になるとは限りません。多くのスタートアップや、MVP（Minimum Viable Product：最小実行可能製品）に取り組む組織において、この転換点こそが重要です。最初は「プロジェクト思考」で、何かを立ち上げ、MVP を世に出すことに注力します。数人の顧客が使ってくれるようになると、スケールが必要となり、最初の 1 つを作るプロセスから、n 番目のものを作るプロセスへと、異なる段階を経る必要があります。この移行期に業界で見られる障壁は何でしょうか？また、AI の時代において新たな動きはありますか？
サム・マカフィー：大企業でも新しいものを構築しようとする際に同様のことが起こると指摘いただき、大変感謝しています。私たち業界関係者は、現代のスタートアップがどのように機能すべきかについて多くの知識を持っています。私の著書は約 10 年前のものですが、もちろんそれが最初ではありません。ベストプラクティスも数多く存在し、その多くは実験的マインドセットに焦点を当てています。かつて私たちは、すべてのものを一度に作り上げ、ドットコム・ブームの時期に一斉にリリースしていました。私が技術の世界に入ったのがまさにその時代です。あれは「大規模な事前設計」と「一斉リリース」の時代であり、結果として成功するか失敗するかの二者択一でした。通常は失敗しました。
もちろん、私たちは長い間反復開発を行ってきました。アジャイルはリーンスタートアップにおいてそれを反映しており、これが現代の製品管理と私たちが考えるものの基礎を基本的に形成しています。そこには多くの実験、顧客との対話、そしてアイデアに価値があることを検証できるまで最初はスケーラビリティが保証されないかもしれないものの構築が含まれます。人々が購入したいと思うものであること、実際にあなたが思うように機能することです。その精神は存在しており、最近のスタートアップの多くがそれを非常にうまく実行していると感じています。私は間違いなく、ある市場で一定の成功を収めた大規模組織が、同じ市場または隣接する市場において新製品や新たな収益源の追求を試みる多くのイニシアチブの一部となってきました。
私は長年にわたり、多くの同僚と共に自らコンサルティングを行い、大規模組織に対してスタートアップのように再び行動する方法や、私が先ほど説明したような形で何かを構築できるチームを形成する方法を教えることに努めてきました。そして私たちが当時発見し、現在もなお大きく当てはまるのは、スケールしてうまく機能するために作られた組織構造、プロセス、さらには文化が、新しいものを構築しようとする際に足かせとなってしまうということです。新しきものと古きものの間には多くの摩擦が生じ、そのため企業は新たなイニシアチブを支援・保護することに苦慮してきました。インキュベーターやラボ内であっても、スピンオフされたチームであったとしても、彼らは完全に「通常通り」の運営や維持に最適化されており、スタートアッププロジェクトや製品、サービス、収益源にとって効果的なリーダーシップスタイルで導くことが難しいのです。これは全く異なるリーダーシップやプロセスのあり方であり、そのような事柄が数多く見受けられます。
したがって、私たちはこれを頻繁に目にします。
Thomas Betts: はい。ゼロ日目から一日目、二日目へと移行する話として触れましたね。新しいものへ到達する必要がありますし、スケールアップも必要です。あなたはまるで循環して戻ってくるかのようなことをおっしゃっていますが、成功している大企業であれば、今やっていることをやめなければなりません。なぜなら、レガシーソフトウェアをサポートするためにあらゆる取り組みをしているからです。しかし、何か新しいことを行う場合、現在の地点から始めることは必ずしもできません。異なる発想が必要です。そして、それが常に大組織の思考様式に適合するわけではないとおっしゃっています。
Sam McAfee: 間違いなく、それもさまざまなレベルで起こります。投資の観点からも、イノベーションを迫られる多くの大企業は、経済的な規模が小さすぎるという視点を持っていません。つまり、十億ドル規模のプロジェクトでない限り、手をかける価値すらないと考えるようなポートフォリオを見ることがあります。私は世界のいくつかの大組織と仕事をしたことがありますが、彼らが資金調達について考える際、非常に大きな数字を基準にしているため、小規模で初期段階の事柄について考えるのが難しいのです。
私は、そのレベルではイノベーションの購入の方がむしろ多いと考えています。まだイノベーションを試みている組織もいくつかあります。確かに先ほどの十年間には、誰もがイノベーションラボを持っていたという光景をよく見ました。つまり、彼らは今でも部分的にそれを続けているようなものです。しかし、大規模な組織がスタートアップのように構築する方法を知らないことを認める方がはるかに一般的であり、通常はそのために買収や M&A（合併・買収）を通じて行うのが主な方法です。しかし、私たちが説明してきたこれらの実践も、徐々に大規模組織に吸収されつつあり、少しずつ浸透しています。私は時としてそのプロセスを手伝うように努めています。
AI 圧力波：イノベーションか義務か？[07:08]
トーマス・ベッツ：最後に付け加えたのは、AI によって何かが変わっているのかという点です。私がこの点を理解するのは、あなたの例にあるような「製品に AI を追加して革新的に見せなければならない」という状況においてです。しかし、それを実行する体制が整っていません。これらの企業はこれまで AI の開発を行ってこなかったのです。もしそれを単なるソフトウェアと捉え、それが異なることを認識しない場合、まだ同じように機能するとは限りません。あるいは、これらのエージェントが暴走しないようにするため、新たなセキュリティポリシーを通過しなければならないという課題もあります。このイノベーションマインドセットの採用における障壁として、他にどのようなものが現れてくるとお考えですか？
Sam McAfee: AI が私たちのソフトウェア開発の世界に与える影響には、私の頭の中で二つの側面があります。一つは、AI の機能を私たちが提供するもの、つまり製品やサービスに組み込むことであり、これには多くの示唆があります。もう一つは、それが実際に私たちのツールセットや、それらのシステム自体を構築する方法にどう影響するかという点です。これらは確かに重なり合う部分もありますが、異なる二つのトピックです。私は最初の側面の方が少し扱いやすいと考え、おそらく後者の側面に時間をより多く割くことになるでしょう。
最初の側面は、これまで続いてきた他のあらゆるトレンドと非常に似ています。私は Web 1.0 の時代を覚えており、誰もがウェブサイトを持つ必要があり、次に誰もがモバイルアプリを持つ必要があり、その後誰もがクラウドに移行する必要があり、さらに誰もがブロックチェーンというものを理解する必要があるようになったことを覚えています。この AI ブームがすべてを変えてしまうという叫び声や過剰な反応にもかかわらず、少し長く業界に身を置いてきた者たちには、これらのパターンが認識できます。したがって、企業が AI を搭載した何かを急いで提供しようとしているとき…私たちはこれを見てきました。今では使用するすべてのアプリケーションにチャットボットがあり、あらゆる種類の生成機能が備わっています。その中には非常にクールなものもあれば、有用で価値のあるものもあります。素晴らしいことです。
しかし、それはまさにそのゴールドラッシュの精神です。あるいは実際には、常にゴールドラッシュとは限りません。私の親しい友人であり同僚でもあるリッチ・ミロノフ（Rich Mironov）は、プロダクトマネジメントに関する書籍の著者で非常に賢い人物ですが、最近私にこう言いました。彼は多くのチーフプロダクトオフィサーをコーチングしているそうです。彼によると、過去1年間に彼が話したすべてのチーフプロダクトオフィサーは、取締役会から指示されたため、AI を組み込んだ何かを必死に立ち上げようとしているか、あるいはそれを行わなかったために解雇されているのだと。つまり、ウォール街や見出し主導の「AI で生産せよ」という圧力が少しあることは明らかです。私たちはそれが起きていることを知っています。
私の考えでは、単純な答えはプロダクト開発の他のすべての側面と同じだということです。まずは顧客から始め、この技術の導入によって彼らがどのような価値を得るのかを考える必要があります。今日に至るまで、アジャイル（Agile）が25年あるいは30年間続いているにもかかわらず、計算方法によりますが、リーンスタートアップ（Lean Startup）も少なくとも15年間行われているにも関わらず、依然として組織の多くが顧客から始めることは驚くほど一般的ではありません。しかし、それは真実です。そして、人々が市場で競争するために自然と大きなプレッシャーを感じているのだと思います。それが私たちが今暮らしている世界です。「AI について先手を打たなければならない」という言葉は、取締役会やCEO から下りてくるものであり、その結果、組織からは何らかの方法でプロダクトにAI を組み込むか、あるいは新しい種類のAI プロダクトを構築するという強い圧力が下方から押し寄せます。
そこで、技術分野のリーダーやエンジニアリング部門の責任者、製品部門の責任者、中堅から上級レベルの担当者は、少し立ち止まってプロセスを遅らせるか、少なくとも慎重になる必要があるのです。なぜなら、これらの製品が成功するのは、請求書を支払う顧客、つまりサービスに対して支払いを行う顧客が実際に感じるニーズに応えている場合に限られるからです。私たちが目にしてきた AI の爆発的成長については、健全な部分がまだその必要性を満たしていない、あるいは価値を実証できていないと言わざるを得ません。あらゆる場所にチャット機能を搭載するとか、「お手伝いしましょうか？この手紙やコピーの作成をお手伝いできますよ」といった機能が、どこにでも存在することが必ずしも最も有用なこととは限りません。
もちろん、そこには多くの価値があります。しかし、私たちが果たすべき役割は、構築したい機能に対して支払いを行う顧客が本当にそれを望んでいることを検証することです。したがって、最初の側面は他の技術的転換点と同様で、何かをリリースする圧力がかかる中で、私たちは AI を製品に組み込む際にも、これまで多くの人が実践しようとしてきたベストプラクティスが依然として適用されるべきだと考えます。
実験と失敗、そして誤解されがちなアジャイルの核心 [12:03]
トーマス・ベッツ：はい。あなたがウェブの初期に「製品全体を構築するか、あるいは完成品を出荷する」とおっしゃった時に戻って考えてみましょう。当時はパッケージ化されたソフトウェアでした。一度きりのチャンスで、それが完了するとすぐに市場に出るのです。それは配送手段の問題もあり、ある程度やむを得ないことでしたが、現在は1日に数百回リリースできるため、ソフトウェアを絶えず更新することが可能になりました。一部の企業では常に「アジャイルである必要がある」「アジャイルを適用しよう」という葛藤がありました。「スプレー缶でアジャイルに塗り替えるだけだ。スクラムに従っているのだから、私たちはアジャイルだ」と。しかし、彼らはあなたが述べたような実験的マインドセットを受け入れていませんでした。それは単に新しい手順に従えば良くなるというものではなく、実験的な姿勢こそが重要なのです。
その背景にあるのは、これらの小さな取り組みを行い、対話を持つことができるようにするためです。そして、私は多くの企業でこの実験的マインドセットが見失われていると感じています。アジャイルのプロセスに従っているかもしれませんし、スクラムを実践しているかもしれません。デイリースタンドアップを行ったり、顧客やプロダクトオーナーとコミュニケーションを取っていたりすることもあります。しかし、「それが機能したか」「機能しなかった場合にどう小さな実験を行い、ロールバックして別の方法を模索するか」という視点で考えていない可能性があります。なぜなら、時には実験が失敗するからです。「必ず成功するはずだ」という前提に立ってしまいがちですが、実際にはそうとは限りません。
それは、CPO が求めたから、取締役会が求めたから、あるいは市場が求めたからといって、製品に AI を組み込まなければならないというお話をされているのでしょうか？しかし、そこには本当の実験はありません。まるで『これは行わねばならない』と命じられているかのようです。
サム・マカフィー：その通りです。実験はほとんど成功しないことを認めることが私たちにとって重要だと考えます。それは 50/50 の確率ではありません。つまり、科学的手法を用いて実験を行うほとんどの環境では、実験の多くが失敗すると予想されるべきなのです。目的はすべての実験を正しく行うことでも、あるいは成功する結果を得ることでもありません。重要な点は、実験的な思考とアプローチを持つことで、より速く学習し、不確実性を減らすことができるということです。
これらすべてはビジネスの文脈内での話であり、ビジネスとは不確実性に関するものですよね？そして、取り組みに資金を提供する責任を負う人々は、可能な限り多くの不確実性を排除したいと考えています。アジャイル（Agile）についてはもちろんのこと、アジャイルソフトウェア開発がどこで成功し、どこでそれほど成功しなかったのか、またその理由について数多くの議論や論争が行われてきたことは間違いありません。しかし、私が即座に思いつくこの問題に対する見解は、大規模な標準的なフォーチュン 500 企業のトップ経営層における文化に関係していると考えます。そのような組織を運営する際には、失敗しないことこそが文化とインセンティブの中心となるという、非常に異なるマインドセットが存在します。
アジャイルは、手探りの IT やテックスタートアップの仲間たち、クリエイティブな人々、そしていじくるのが好きな人々の間から生まれました。アジャイルがますます人気を博し、大規模組織にも採用されるにつれて… もちろん、経営コンサルタントもその普及に役割を果たしましたが、善悪は別として、むしろ悪い方へ影響したと言えます。私は、文化の衝突が生じていると考えています。アジャイルは物事をより速く進めたり、ある程度の不確実性を減らしたりする方法として捉えられてきました。しかし、経営陣が欠落しているのは、一定の柔軟性が必要であるという点です。また、小さな単位でリリースを推進する理由は、単に素早く継続的に出荷できるからだけでなく、安全かつ迅速により頻繁に間違いを犯し、そこから素早く回復できるからです。
私たちは一季限りの賭けで全てを失うようなことはしません。毎日、多くの小さな賭けを行います。プロダクションにプッシュするコードの各行は、ある意味では実験です。ユーザーが実際に使い始めるまで、それが正しい方向だったかどうかを確実に知ることはできません。したがって、「試してみて、どうなるかを見る」という文化は、私たちの経営やエグゼクティブ層の文化とは一致していないと考えます。彼らの文化は産業時代から生まれ、テイラーやガントに由来するものであり、大規模な組織では「確実でなければならない」「正確でなければならない」といった思考が支配的です。また、間違いを犯せば多くの場合、罰せられるという風潮もあります。
つまり、現代の企業におけるシニアエグゼクティブの世界がどのようなものかを考える必要があります。それはそれほど寛容なものではありませんよね？製品開発やサービスイノベーションを行うために必要なマインドセットとは異なるものです。いかなる種類のイノベーションにも創造性が必要です。柔軟性も必要です。失敗を学習のプロセスとして受け入れる姿勢も不可欠です。しかし、ウォール街や取締役室にはそのような環境は存在しません。
摩擦の発見：システムが破綻し、意思決定がボトルネックとなる場所 [17:02]
トーマス・ベッツ：あなたがイノベーションマインドセットを築こうとしている際の話についてですが、これは双方向に機能するものだと考えています。つまり、大企業であればより多くのイノベーションを加えようとするか、あるいは小規模企業であればより安定した状態へ移行しようとするかです。重要なのは、そのマインドセットの転換です。摩擦について話しましたが、あなたが指摘されたように、それはスピードを鈍らせる要因となります。ソフトウェア開発プロセスにおいて、それがソフトウェア開発そのものであるにせよ、チームや官僚主義に由来するにせよ、どのような摩擦ポイントが存在するかを特定し、それをどう解決すればよいのでしょうか？
サム・マカフィー：システムが機能しなくなるのは、どこからかという視点で考えています。より多くの努力を投入しても、スループットが同じかそれ以下になる場合、それは構造的な問題がある兆候であることが多いです。理想的な環境では、チームはある程度の自律性を持って運営されます。そして自律性は無料ではありません。それは明確さと能力の必要性を伴うものです。デビッド・マルケットの言葉を借りれば、「明確な目標を持ち、その後に明確なガイドラインと制約が必要だ」という考え方です。この2つが揃い、人々が職務に必要なスキルや訓練、能力を持っている場合、非常に高いレベルの自律性を持って運営でき、非常に速く動き、不確実で確率的な環境にも迅速に対応して仕事を完了させることができます。
私たちが breakdown（崩壊）を目にするのは、通常は明確さの欠如が原因です。会話の冒頭で私が通常いつ招かれるかについて質問がありましたが、その中で特に重要なのは「意思決定の明確さ」に関する点だと考えています。私は意思決定に関する文脈を整理するのを本当に支援しています。誰が決定を下すのか？どの決定が必要なのか？組織のどのレベルで行うべきなのか。なぜなら、決定にはコストがかかるからです。また、通常はタイミングも重要になります。私が早期に製品開発のヒーローとして尊敬しているドン・ライナーセンは、意思決定のコストについて語るのを好みます。
先ほど、コードの各行が潜在的に実験となり得るという話をしていました。私がコンサルティング業務でよく言っていたのは、「コードの各行はすべてビジネス上の決断である」ということです。チームや組織が製品を構築してリリースする過程全体を、個人レベル、チームレベル、部門レベル、そして組織レベルで常に行われている一連の決断として捉えることができます。組織がつまずきやすいのは、この決断が誰のものなのか、その決断がどのような影響をもたらすのかについて明確さがない場合です。もし決断をより上級の管理職にエスカレートしなければならないとしたら、それは通常は機能不全の兆候です。
エスカレーションが頻繁に行われる場合…つまり、エスカレーションが当然のこととして見なされている組織もあります。これは機能不全であり、アンチパターンと言えるでしょう。エスカレーションが行われるのは、これらの決断のロジックを事前に計画していなかったからです。すべての決断を事前に下すことはできませんが、異なる種類の決断に対するロジックを事前に検討することは可能です。これらが私たちの目標です。「このようなことが起きたら、私たちはこの種の決断を下したい」「あのことが起きたら、別の方向に進みたい」という方針を持つのです。そうすれば、外れ値が発生した際にも、経営陣は「ああ、こうした奇妙なことが起きたら私に連絡してほしい。それらはエスカレートすべきだ。私が決定を支援しよう」と言うことができます。しかし、多くの場合、チームは自らの力で運営されるべきです。
つまり、これらの崩壊が最も顕著に現れるのは、エスカレーションが多く、混乱が生じ、膨大な圧力と努力が注がれているにもかかわらず、追加の採用やリソースの投入、残業による労働が行われているにも関わらず、成果やアウトカムが十分に改善されていない、あるいは十分な速度で進展していない場合です。もちろん、私はそのような状況を推奨しているわけではありません。しかし、より多くの努力をしても結果が出ないということは、構造的な問題が存在することを意味します。ここで言う「構造」とは、通常、建物のコンクリートのような物理的なものを指すのではなく、組織がどのように構成されているか、役割の定義、プロセス、あるいはそれらのような要素を指しています。
心理的安全性のために声を上げる [21:32]
トーマス・ベッツ：はい。明確性と有能さが基本であると指摘されましたが、これらは心理的安全性という概念と密接に関連していると考えられます。チームおよび個々のメンバーは、十分な自律性を持っていると感じています。その上で行動しても安全だと感じています。また、「この意思決定を支援したい」といったように、オープンな異議申し立てを行い、実際に挑戦することもできると考えています。これは「上司に報告して承認を仰がなければならない」「自分たちで何も決めることはできない」という状況とは対照的です。そこで伺いますが、心理的安全性の定義は何でしょうか？また、それがチーム内に実際に存在しているのか、それとも単に見た目が良いだけの皮膜（ベニアー）に過ぎないのかを、どのように見分けることができますか？
Sam McAfee: チーム、特に個人貢献者（IC）のメンバーが、リーダーから出た悪いアイデアに対して完全に安心して異議を唱えられる状態であれば、心理的安全性が存在していることがわかります。リーダーが「さて、私たちはこの方向に進もうと思う」と言ったとき、会議参加者の誰かが「実はそれは間違いだと思います。その理由はこうです」と言え、誰も解雇されたり公の場で恥をかかされたりせず、それが問題視されることもない場合、組織でそのような様子が見られるなら、それは通常良い兆候です。
心理的安全性という概念は以前から存在していましたが、技術者向け環境においてより真剣に受け止められているのをとても嬉しく思います。なぜなら当初は、「これはあれば便利なもの」「単なるふわっとした、感情的な話だ」という誤解が少しあったからです。実際にはそうではありません。人々がそのような判断を下せるためには、その権限と責任を持って決定を下せるという安心感を持つ必要があるからです。あるいは、意思決定が議論と協働によって行われるべき場合、会議室にいるすべての声が有効であり、リーダーはより良い論理やより説得力のある主張に対して譲歩し、耳を傾ける用意があるとき、そこに多くの心理的安全性が見られるのです。
私は逆のことが真実だと考えています。実際には本物ではない、パフォーマンス的な心理的安全性がたくさんあります。リーダーたちは多くの陳腐な言葉や、どこからでもアイデアを受け入れるという壁に書かれた言葉を並べ立てます。彼らは正しいことをすべて言いますが、実際にチームがどのように運営されているかを見ると、チーム会議に行き、部屋に12人がいて、たった2〜3人しか話さない、といった光景が見られます。あるいは、決定が下されたり計画が提案されたりした際、部屋で最も権威のある人物が「質問はありますか？」と尋ねても、誰も質問しない、という状況です。もちろん、人は常に質問を持つべきです。決してすべてが明確なわけではありません。誰も質問をしないのは、おそらく間違った質問をすると馬鹿にされるのではないかと恐れているからです。これはその部屋に心理的安全性がないことを確実示す兆候です。
マインドフル・リーダーシップ：刺激と反応の間に空間を作る [24:29]
トーマス・ベッツ：あなたが教え、話されていることの1つに、マインドフル・リーダーシップ（mindful leadership）があります。私たちはここから、チームをトップに置くリーダーへと、そしてそのリーダーが心理的安全性や他の側面をサポートする立場へと移行していると感じています。単に壁にポスターを貼るだけではないのです。では、リーダーシップの文脈においてマインドフルネスとはどのような姿を示すのでしょうか？それは理論やポスターではなく、日々の行動として現れるものでしょうか？
サム・マカフィー：マインドフルリーダーシップとは、プレッシャー下での意思決定に対する意識を高めることです。単に冷静であることではありません。もちろん、私が語る内容よりもはるかに広範な瞑想の側面も存在します。しかし、組織におけるリーダーシップという文脈では、私たちは瞑想について話しているわけではありません。沈黙の静修についても言及していません。あなたが感じるような平静さのレベルについても論じているのではありません。本当に重要なのは、プレッシャーがかかっているその瞬間に、自分自身の思考や感情、そして周囲の人々のそれらに対する意識を高めることです。それは刺激と反応の間にわずかな隙間を作り、十分な時間を持って明確な意思決定ができるようにするためのものです。それがマインドフルリーダーシップがもたらすものです。
おっしゃる通り、これは多くの点で心理的安全性と直接関連しています。聴衆の皆様には、心理的安全性が存在しない場合や、心理的安全性が相対的に低い環境を創出しているリーダーがいる場合に、そのことを考慮していただきたいと考えています。通常、そのような状況は意図的なものではないはずです。彼らの立場や受けているプレッシャーの規模を考えると、シニアリーダーたちに対して私は大きな共感を覚えます。私自身も多くの執筆活動を行ってきました。私のブログや書籍を読んでくださる方もおり、ブログという壇上からCEOを非常に厳しく批判することもありますが、その多くは点を強調するための遊び心のあるトーンであると考えています。現実には、リーダーシップの立場にある人々に対して私は大きな同情を抱いています。なぜなら、それは容易なことではないからです。
長年コーチングのクライアントであり、現在は親しい友人でもある私の良い友人が先日電話で、「サム、20年前に『シニアリーダーの多くが人々を崖から引き戻すような対応をしている』と言われたら、信じたかどうかはわからない」と言いました。まるでこの仕事全体が、皆が無事であることを確認することに回っているかのようです。シニアリーダーたちは、上層部や市場、取締役会、他の同僚などから多くのプレッシャーを受けています。そのため、心理的安全性が低い状況では、その状況を創り出しているのがリーダー自身であることに、通常は自覚がありません。彼らは環境に対して反応しているのです。他人に発言を許したり、自分のアイデアに反論されたりすることに慣れていないのかもしれません。これは意識的なことではなく、自分が何をしているのかを本当に理解していないために起こっていることです。
マインドフルネスは、ある意味において、組織内でより心理的安全性を構築するために使用できるツールの一つです。なぜなら、それはリーダーが自身の行動を見つめ直し、その行動がチームが望むレベルでパフォーマンスを発揮し、期待するビジネス成果を生み出すような環境を作り出しているかどうかを、慎重に考えることを可能にするからです。
多くの場合、問題となるのはリーダー自身の行動です。軽々しく口にした言葉、十分に考えずに発した言葉、疲れや過労による不機嫌さ、あるいは「ドアは開いている」と言いながら実際には決して利用できない状況などがあります。また、自分の言葉がどれほど大きな影響力を持つかに気づいていないこともあります。したがって、安易に考えもせずに発言することは避けなければなりません。なぜなら、それはチームの他のメンバーに多大な影響を及ぼすからです。
リーダーたちがこれらの点によりマインドフルになることで、組織内の文化や環境を、非常に意図的な方法で形作ることが可能になります。これは往々にして間接的な方法ですが、彼らが目指している成果を生み出すことになります。しかし、リーダーシップは間接的な仕事ですよね？すべてをコントロールすることはできません。条件を整える必要があるのです。それはまるで園芸家のようものです。種を蒔き、水をやり、植物が成長するのを促します。しかし、植物そのものを成長させるわけではありません。植物は置かれている環境の条件に応じて成長するものです。マインドフルなリーダーシップは、まさにこれらの原則を受け入れています。
トーマス・ベッツ：はい。はい。「もっと笑顔で」は『ハミルトン』の台詞ですが、あなたが言いたいのは「少なく話し、多く聞くこと」、つまり座って話をすることです。誰かがあなたに話しかけてきたら、すぐに反応する前にその人の話を聞いてください。間違いなく常に良いアドバイスです。ただちにデフォルトの反応に飛び込む前に、一呼吸置いてください。なぜなら、それはあなたの直感に基づく反応である場合があるからです。感情に基づいて行動しているのではなく、この状況にとって実際に最善なのは何か、その人が何を考慮しているのかを考える必要があります。
振り返ってみれば、ほとんどうまくいっているように思えます。誰かが上司に問題を提起する場合、それは「あなたが私たちを置いている環境はこうです」「あなたが作っている庭園はこれです」という意味かもしれません。もう少し時間をかけてくださいと伝える機会を見つけてください。「はい、私が何か間違っていたのかもしれません」と言う機会は必ずあります。もしかすると、二人ともこの成長の機会を利用する必要があるのかもしれません。
サム・マカフィー：はい。通常、一呼吸で十分です。それほど長くはかかりません。数秒あれば、生物学的にも認知的にも、脳がその瞬間に起きていることを追いつき、考えることができます。ダニエル・カーネマンの『ファスト＆スロー』や他の...すみません、長年神経科学の本を読み込んでいて、専門用語を連発してしまいました。
非常に興味深いのは、脳の一部が非常に自動的であり、超高速であるという点です。もし私たちが同じ部屋にいて、私があなたに野球を投げたら、あなたの脳が腕に何をすべきか伝える前に、あなたはそれをキャッチしてしまうでしょう。私たちには生存のために進化してきた反応的な脳の部分があります。それは進化的な理由で存在しています。しかし、その部分が会議を主導すべきではありませんよね？よりゆっくりと、より体系的で、熟考する脳の部分が組織を率いるべきなのです。
Thomas Betts: はい。私を追いかけてくる動物からの逃走ですね。
Sam McAfee: はい、まさにそうです。私たちは-
Thomas Betts: 逃げることは非常に重要ですが、この状況ではそうではありません。
Sam McAfee: その通りです。ほとんどの場合、私たちは実際に虎に追われているわけではありません。
Humanize: AI サポート型リーダーシップと人間がループに参加する未来 [31:13]
Thomas Betts: それは少なくとも私がソフトウェアを書いている経験とは異なります。今私たちがどこにいるか、そしてこれからどこへ向かうのかについて話をまとめたいと思います。AI パワー型のリーダーシッププラットフォームである Humanize について少し教えてください。AI をリーダーを支援するツールとしてどのように捉えており、そこで販売されている AI の蛇の油（※信頼性の低い製品）に対して人々がどこで警戒すべきかについても教えていただけますか？
サム・マカフィー：はい、Humanize は多くの取り組みを経て生まれた製品です。比較的新しい製品で、この録音時点ではまだ1年にも満たないほどですが、急速に成長しています。しかし、その背景には長年にわたる協働の歴史があります。私の同僚たちと私は、組織がリーダーシップを向上させ、ビジネス成果を改善し、よりマインドフルで人間的かつ心理的に安全な方法で導くことを支援しようと努めてきました。私たちは明確な視点を持ってこの問題に取り組んでいます。多くの研究により、このような人道的なリーダーシップのあり方が、同時に優れた結果も生み出すことが示されています。『フェニックス・プロジェクト』やジーン・キムの業績、マット・パーカーによる『ラディカル・エンタープライズ』を参照するだけでも十分です。これらのより良く、現代的なリーダーシップの方法が実際に効果的であることを示すために、思索深い人々によって多くの研究が行われています。これらは単なる「あれば良いもの」ではなく、実効性のあるものです。
私たちは、リーダーが困難な決断を下すのを支援するために「Humanize」を構築しました。私が手動で行っていることと少し似ていますが、このツールは、リーダーが直面している課題について議論し、問題を再定義し、それらの問題に対処するために使用できるツールやリソースへと導くためのプラットフォームです。私たちは、さまざまな分野の思考の指導者たちや同僚から知識を集めました。非常に技術的または製品開発に関するものもあれば、リーダーシップ、文化、ビジネス、組織、コミュニケーションスキルなど、あらゆる分野にわたるものです。それらすべての知識をシステムに注ぎ込み、システムがあなたと対話し、リーダーとしての目標達成をサポートできるようにしました。
私たちはバランスを取ることに非常に注意を払ってきました…これはまだ初期段階なので、まだ模索している最中です。皆さんに試してもらい、フィードバックを提供していただくことをお勧めします。また、ユーザーから実験し、学ぶ必要もあります。基本的に、人間の介入のポイントを調整しています。ロボットは私たちを大きく助けてくれますが、すべてのことに対応できるわけではありません。そこで、誰かが手を挙げて人間の介入を求め、おそらくコーチングやフィードバック、耳を傾ける姿勢など、何らかの支援を提供してもらうことが適切かどうかを見極めようとしています。「Humanize」はこの原則を中心に構築されています。人間をループから排除するのではなく、人間がループの中でどこに位置すべきかを模索しているのです。
私たちがツールを構築しているという事実は興味深いものです。ウェブサイトで AI の旗を振ることはあまりありませんが、確かに頭脳には AI が組み込まれています。これは AI プラットフォームの上に構築されており、さらにそのプラットフォーム自体も AI を用いて作られています。コードの生成も行っていますし、Cursor といったツールも活用しています。これは私が以前関わったスタートアップとは全く異なる点で、特にコードの書き方や本番環境への展開方法においてです。私たちのワークフロー自体にも大きな変化が生じています。私たちは依然として3名の小規模でタフなチームですが、私にとって素晴らしいのは、いわゆるガレージで働く3人のチームとして、新しい機能のコミュニケーションやデプロイが非常に速く、流れるように行える点です。1日に複数の機能をリリースできるという状況は、本当にワクワクする場所です。
私にとっては非常にメタ的な話です。顧客やクライアントに掲げる価値観を、ツールそのものを構築する際にどう取り入れているかという点について、とても興味深い問いかけです。私たちは、デザインが人間の相互運用性、つまり人間同士のコミュニケーションをいかに高めるかを考えるのに多くの時間を費やしてきました。しかし同時に、時には作業をエージェントに引き渡す必要もあります。それらすべてがどのように統合されるのかについては、実はまだ私たちが完全に理解しているわけではありません。
実際、先数ヶ月間、別のプロジェクトの一環として多くの技術リーダーと話し合う機会がありました。AI が彼らのワークフローをどう変えているかについてです。2026 年の初頭現在で私が目にするのは、まだ非常に「ワイルド・ウエスト（開拓時代）」のような状態だと言えます。明確ではないが、いくつかの新しいパターンが出現しつつあります。しかし変化のスピードはあまりにも速いです。
例えば、プラットフォームを構築するために使用しているツール自体を見てもさえも、6 ヶ月前とは異なるシステムやアイデアから、より良い方法へとコンポーネントや考え方を切り替えています。だからこそ、この作業においては柔軟で実験的なマインドセットを持つことが何よりも重要なのです。何がうまくいくのかは正確にはわかりません。組織が成長するにつれて、「自社のドッグフードを食べる（eat our own dog food）」という言葉が私の好きなフレーズではありませんが、彼らが言うように、あるいは「自社のレストランで食事をすること」と言い換える方がより適切かもしれません。
はい、それは本当に言うのが難しいですね。私たちは技術的に非常に興味深いポイントにいます。過去のフェーズや技術革新のラウンドからのパターンが存在する一方で、AI もそれらと多くの点で似ています。以前冗談を言ったように、初期のウェブサイトや初期のモバイル端末と同様に、AI はこれまでのすべてのものとは完全に異なるわけではありません。しかし同時に、非常に異なる側面もあり、コミュニティとして慎重に働きかけ、何が異なり何が同じなのかを理解する必要があります。このように考え深く、このような対話を持つことは、互いに知識を共有し、オープンソースで取り組むために本当に重要です。正直なところ、今後 2 年、3 年、5 年後にどうなるかを誰も正確に知らないような時期において、これらは非常に重要なことです。これはエキサイティングな時代です。
トーマス・ベッツ：はい。それが InfoQ の目標の一つであり、私たちは情報を Robin Hood のように広めたいと考えています。こうした対話をしたいのです。その情報を世の中に発信し、より多くの議論を始めるために。人々が学ぶための機会が非常に多くあります。おっしゃる通り、あなたの製品はリーダーが AI を活用して学習するための手段です。彼らがそうした機会を探していることを願っています。この番組を聴くことも含めて。残念ながら、時間がなくなりました。ここで締めくくる必要がありますので、サム・マカフィーさん、今日はお越しいただき改めてありがとうございます。これは素晴らしい議論でした。数時間続けてもよかったはずです。
サム・マカフィー：お招きいただき本当にありがとうございました。とても楽しかったです。
Thomas Betts: リスナーの皆さん、今後とも当番組『The InfoQ Podcast』の他のエピソードにぜひご参加ください。
著者について
サム・マカフィー（Sam McAfee）
私は、容易に撤回できない意思決定を行う責任を負うシニア製品リーダーおよび技術リーダーと協力しています。
私の焦点は、実際のプレッシャー下におけるマインドフルなリーダーシップです。スピード、確実性、あるいは合意形成が誘惑となるような瞬間において、明確さこそが最も重要となる局面です。
過去 25 年以上にわたり、私は不十分な意思決定が、知能や努力の欠如から生じることはほとんどないと見てきました。それらはむしろ、検証されていない前提、感情的なノイズ、そして判断よりもモメンタム（勢い）を報奨するシステムから生じます。私が実践するマインドフルネスは、静寂や自己改善に関するものではありません。それは実際に何が起きているかを見極め、意図的に選択することです。
私は関与する場所を選り好みしています。この仕事は、リーダーが真の権限を持ち、不快な状況でも立ち止まる用意があり、合致（アライメント）だけでなく結果に対して責任を負う場合にのみ意味を成します。
もしフレームワーク、モチベーション、あるいは継続的な安心感を求めているのであれば、私はおそらく適任ではないでしょう。複雑さやトレードオフ、不可逆な選択に直面し、実際に何を決断しているのかをより明確に見たいとお考えであれば、そこが私の最も力を発揮できる場所です。
ポッドキャストは RSS フィードを通じて最新情報を入手でき、SoundCloud、Apple Podcasts、Spotify、Overcast、YouTube でもご利用いただけます。このページからは録音された番組ノートにもアクセス可能で、すべてにクリック可能なリンクが含まれており、音声の該当部分へ直接移動できます。
原文を表示
Transcript
Introduction [00:37]
Thomas Betts: Hello, and welcome to The InfoQ Podcast. I'm Thomas Betts. Today, I'm speaking with Sam McAfee. Sam is a Silicon Valley veteran with over 25 years of experience leading technology organizations, working with everyone from global companies to startups. Sam is the author of Startup Patterns the book, and founder of Startup Patterns the company, a leadership and strategy firm helping founders and executives build resilient, high-performing organizations. He's also the co-founder of Humanize, an AI-powered leadership platform. Sam's expertise blends modern product development, mindful leadership, and organizational transformation.
Sam, welcome to The InfoQ Podcast.
Sam McAfee: Thanks for having me. Very excited.
Thomas Betts: Let's start with that, that your bio covered a bunch of stuff, but what do you do, Sam? When are you typically brought in to work with an organization, and what are the goals?
Sam McAfee: Typically, I don't get brought in on day one. I have a lot of experience with early stage startups and go-to-market strategy from the old days. But in more recent times, I usually get brought in after there's been some success and things are growing, and that's causing a lot of stuff to break, and so it's when the stuff... You could call maybe day two. When the stuff that used to work, now, because of our success, is starting to crack in the foundation, for a variety of reasons, is usually when I get brought in.
Startup vs. Enterprise: Why Big Companies Struggle to Innovate [02:04]
Thomas Betts: Yes. The idea of what got us here isn't going to get us there. It's that pivot point that a lot of startups and even organizations that are working on an MVP, any new product, you go from, well, we had this project mindset, get this thing off the ground, get the MVP out there. A few customers start using it, and then you need to scale, and it's a different process you need to go through from build the first to build the nth one of those. What are some of the barriers that you see in the industry during that transition, and is there anything new coming out in this age of AI?
Sam McAfee: I really appreciate that you pointed out it happens in bigger companies as well, when they're trying to build something new. We, as an industry, know a lot about how startups should work these days. My book is about 10 years old, and it certainly wasn't the first. There's a lot of best practice out there, most of which orients around an experimental mindset that in the old days we built everything all at once and launched it during the dot-com boom, which is where I came up into technology. Those were the days of big design upfront and launches, and either it passed or failed. Usually, failed.
Of course, we've been using iterative development for a long time, and Agile reflects that in the Lean Startup, which basically forms the foundation of what we would think of as modern product management. Involves lots of experiments, lots of talking to customers, lots of building things that might not scale at first until you can validate that your idea has merit. That it's something people want to buy. That it actually does the thing you think it does. That spirit is there, and I think a lot of startups these days, I'm finding, do it pretty well. I've definitely been part of a lot of initiatives where a large organization that has had some success in one market is trying to pursue a new product or a new revenue stream maybe in the same market, maybe in an adjacent market.
I definitely did a lot of consulting myself and with a lot of colleagues over the years, trying to teach those large organizations how to play startup again, how to form a team that can build something in the way that I just described for startups. And what we found in those days, and this is still largely true, is that the organization structures and processes and even culture that make it work really well at scale get in the way when they're trying to build something new. There can be a lot of friction between the new and the old, and so companies have struggled to support and protect a new initiative. Whether it's in an incubator or a lab or just a team that's spun off, they have a hard time leading them in a way that would be effective for a startup project or product or service or revenue stream when they're totally tooled to operate and keep the lights on, business as usual, which is a really different style of leadership, of process, all that sort of stuff. So yes, we see that a lot.
Thomas Betts: Yes. I talked about it as a go from day zero to day one to day two, like we have to get to that new thing. We have to scale up. You're almost talking about cycling back and having that, we need to stop doing what we are now if we're a big company that's successful, and we're doing all these things to support our legacy software. But to do something new, you can't necessarily start from where you're at right now. You have to think differently. And you're saying that doesn't always fit into a large organization mindset.
Sam McAfee: Absolutely. At so many different levels, too. In terms of investment, many large companies that are pushed to innovate, they don't even think in economic terms that are small enough, right? You'll sometimes see these portfolios where it's like, hey, if it's not a billion dollar project, we don't even want to bother, right? I've worked with some of the larger organizations in the world, and when they think about funding things, it's like these very large numbers, so it's difficult for them to think in terms of small, early stage stuff.
I think in large measure, there's probably more buying of innovation at that level. There are some orgs that I think still do try to innovate. We certainly saw a lot of it in the previous decade around everybody had an innovation lab. I mean, they all sort of still do, kind of. But I think it's much more common for large orgs to admit the fact that they don't know how to build like a startup, and they'll usually go and do it through acquisition, through M&A is kind of the main way. But those practices we were describing, they are slowly getting absorbed into larger organizations as well, bit by bit, and I try to help that happen sometimes.
The AI Pressure Wave: Innovation or Mandate? [07:08]
Thomas Betts: I tacked on at the end there the, is anything changing with AI? I think where I see this, to your example, is the we need to add AI to our products so we look innovative, and they aren't set up to do that. These companies haven't been doing AI development. And if they think of it as just software, but they don't recognize it's different, it's still only... Things won't necessarily work the same way. Or they have new security policies they have to go through because you have to make sure these agents aren't running amuck. What else do you see coming up as a barrier to adopting that innovation mindset?
Sam McAfee: There are two aspects in my mind to AI's impact on our software development world. One is building AI capabilities into our offers, our products, our services, which has a whole bunch of implications. The other is how it actually affects our tooling and how we build those systems themselves. Those are two different, certainly overlapping topics. I think the first one is a little easier to cover, and we'll probably spend a lot more time on the second aspect.
The first one is very much similar to every other trend that's come along. I've been around long enough to remember Web 1.0, everyone needs a website, then everyone needed a mobile app, then everyone needed to be in the cloud, and then everyone needed to figure out this blockchain thing. Despite the shrill hysterics that this AI boom changes everything, there are ways in which those of us who've been in the game for a little while recognize these patterns. And so, when companies are rushing to offer something with AI in it... We've seen this. There's a chatbot in every single application we use now, and there's all sorts of generative capabilities. Some of which are very cool. Some of which are useful and have value. It's great.
But it's that same gold rush mentality. Or actually, not always really gold rush. But a good buddy and colleague of mine, Rich Mironov, an author of product management books and really smart guy, said to me recently that he coaches a lot of chief product officers. He said every chief product officer he's spoken to in the last year is either desperately trying to launch something with AI in it because they were told to by the board or has been fired for not doing it, right? I mean, it's clear that there's a little bit of Wall Street, headline-driven, you must produce with AI. So, we know that's happening.
I think that the simple answer is it's like every other aspect of product development. You have to start with the customer and what value are they getting from the introduction of this technology. To this day, despite 25 or 30 years of Agile, however you calculate it, and at least 15 of Lean Startup, it's still not that common and most organizations start with the customer, shockingly. But it's true. And so, I think that people just are under a lot of pressure to compete in the market, naturally. That's the world we live in right now. "Hey, we have to get ahead of this AI thing", is a phrase that comes down from the board or from the CEO, and so there's a lot of downward pressure from the organization to put AI into the product somehow or build a new AI product of some kind.
That's where leaders in technology, heads of engineering, heads of product, people at the mid to senior level really need to be careful to push back a little bit or at least slow the process down because those products are still only going to be successful if they are meeting a real felt need by a customer that pays the bills, that will pay for a service. A lot of the AI explosion that we've seen, I would say some healthy amount of it does not yet do that or has not yet proven its value, right? Having a chat in everything. Or, "Oh, can I help you write that letter or that piece of copy?" everywhere you go might not necessarily be the most useful thing.
But of course there is a lot of value to it. Just it's our job to validate with paying customers that this feature we want to build actually is something that they want. So, I think that first aspect is very much like every other technology shift where there's pressure to ship something that satisfies it, and we have to think about the same best practices that many of us have been trying to follow still apply with AI in the product.
Experiments, Failure, and the Misunderstood Heart of Agile [12:03]
Thomas Betts: Yes. I think if we go back to when you said back in the early web days, build the whole product or get the whole thing shipped. It's shrink-wrapped software. You get one shot, and it's done, and it's out the door. You had to do that somewhat because of delivery mechanisms, but now we can release hundreds of times a day, so we can constantly be updating our software. I think some companies, there was always that struggle like, "Oh, we need to be agile. We're going to slap Agile on it. Get out the spray can, and now we're Agile. We're following Scrum, so we must be Agile". But they didn't embrace what you said as the experimental mindset, that it's not just about follow these new procedures, and we'll be better.
The reason behind that is so that we can do these little things, we can have those conversations, and I think that the experimental mindset gets lost in that a lot. I don't see a whole lot of companies that are doing that. They may be following Agile processes. They might be following Scrum. They might have daily standups, and they might be communicating with their customers or a product owner. But they might not be thinking about it in terms of, did that work, and how do we do a little small experiment and roll it back if it doesn't work and figure out the other thing? Because sometimes the experiments don't work. It's always the assumption that we have to do it, and it's going to be successful.
Is that what you're saying about with we've got to put AI in the product because the CPO asked for it, and the board asked for it, or the street asked for it? But there's not really an experiment there. It's like, thou shalt must do this.
Sam McAfee: Absolutely. I think it's important for us to acknowledge that the experiments rarely work. It's not 50/50. I mean, I think in most environments, where you're experimenting the scientific method, most experiments should be expected to fail. The point isn't to get all your experiments right or even get them to have a successful outcome. The idea is that having an experimental mindset and approach allows you to learn faster and to reduce uncertainty, right?
All of this is within business, and business is about uncertainty, right? And so, people whose responsibility is to fund efforts, they want to have as much certainty as possible. I think that one of the things that's happened, certainly with Agile... I'm sure there's been many discussions and debates about where Agile software development succeeded or wasn't as successful and why. But I think my quick off the top of my head take on this has to do with the cultures that are in high-level executive management of large, standard Fortune 500 companies. There is a very different mindset in running an organization like that, where the culture and the incentives are about not failing.
Agile came up out of scrappy IT, tech startup folks, creatives and people who like to tinker. As Agile got more and more popular and as it got adopted by larger organizations... Of course, the management consultants played their role in popularizing it, for better or for worse. Mostly worse. I think we have a collision of cultures, where Agile was seen as a way for things to go faster and maybe to reduce a certain amount of uncertainty. But I think that the boardrooms miss the point that there has to be a certain flexibility, and that the reason why we push for shipping in smaller pieces is because we can ship faster and more continuously, but also because it allows us to be wrong more often, safely and more quickly, and recover faster.
We don't bet the whole farm one season and then be wrong. We make lots of little bets every day. Every line of code that we push to production is in some respects an experiment, right? We don't know for sure until users are using it if that was the right way to go. And so, I think that that culture of we're going to try things and see how they work, it is not really in line... Our management and executive cultures came out of the industrial age, out of Taylor and Gantt, and a lot of large scale, we have to be sure, we have to be precise types of thinking, and a lot of punishment if you're wrong, too.
I mean, you got to think about what the world of a senior exec is like in modern companies. It's not that forgiving, right? That's a different mentality from what it takes to do product development, to do service innovation. Innovation of any kind takes creativity. It takes flexibility. It takes the embrace of failure as a learning movement. And that's not the environment on Wall Street or in the boardroom.
Finding Friction: Where Systems Break and Decisions Bottleneck [17:02]
Thomas Betts: I think when you're talking about the... You're trying to get into that innovation mindset, and I think this works both ways. Either you're big, and you're trying to add more innovation, or you're small, and you're trying to move into more stability. It's that mindset shift. We talked about friction, and I think you brought it up. It can slow you down. How do you help identify what those friction points are in your software development process, whether it's software development itself or the teams or the bureaucracy?
Sam McAfee: The way I think about it is where the system starts breaking down. If you're putting in more and more effort and getting the same or less throughput, that's usually a sign that something is structurally off. In an ideal environment, teams operate with a certain degree of autonomy. And autonomy isn't free. It comes with the need for clarity and competence, quoting David Marquet a little bit there. But that idea of you got to have clear goals and then clear guidelines and constraints. If those two things are present, and if people have the skills and the training and the competence to do their jobs, they can operate with a very high degree of autonomy, and they can move very fast, and they can respond to an uncertain stochastic environment very quickly and get the job done.
Where we see breakdowns is typically because of usually a lack of clarity. In the beginning of our conversation, you asked about when I'm typically brought in, and I think one place that it really matters is around decision clarity. I really help with context around decisions. Who's making them? Which ones do we need to make? At what level of the organization should they be made? Because decisions have a cost, right? And there's usually a timing to them as well. One of my early product development heroes, Don Reinertsen, likes to talk about the costs of decisions.
We were talking earlier about every line of code potentially being an experiment. Something I used to say a lot in my consulting work is every single line of code is a business decision. You could think about a team or an organization building products and shipping them as a whole set of decisions that are being made at the individual level, at the team level, at the department level, at the organization level all the time. And where organizations tend to falter is when there's a lack of clarity around, whose decision is this? What is the impact of this decision? If we have to escalate decisions to more senior management, that usually is a sign of breakdown.
When there is a lot of escalation... I mean, there are orgs where escalation's seen as the norm. That's a dysfunction. That's an anti-pattern, right? If there's an escalation, it's because we didn't actually plan for the logic of these decisions in advance. You can't make all your decisions in advance, but you can actually think through the logic of different types of decisions. These are our goals. If this sort of thing happens, this is the kind of decision we want to make. If this thing happens, we want to go this other way. Then when there are outliers, the executives can say, "Okay, please come to me when these weird things happen. Those you should escalate. I'll help to decide". But most of the time, the team should be running on their own.
So, I think where you really see these breakdowns is when there's a lot of escalation, there's a lot of confusion, and there's a huge amount of pressure and effort, but output, or outcomes, really, are not improving or moving fast enough, despite additional hires, additional resources, people working late, and it's still not getting done. Not that I'm advocating for that. But more effort and it's not happening means there's a structural problem. By structure, I'm usually not talking about the concrete of the building. I'm talking about how the organization is put together, role definition, processes, that sort of thing.
Speaking Up For Psychological Safety [21:32]
Thomas Betts: Yes. You mentioned clarity and competence as being fundamental. I think those tie into the idea of psychological safety. The team and the individual team members feel like they have enough autonomy. They feel safe operating with that. They feel like they can have a little bit of open disagreement to actually challenge, like, "I need to help make this decision". And you can go to a team member versus, "I've got to run it up the flagpole. We can't decide anything ourselves". So, what's your definition of psychological safety, and how can you tell if it actually exists in the team or if there's just a veneer that looks good?
Sam McAfee: You can tell psychological safety is present when people on a team, particularly ICs, individual contributors, are completely comfortable pushing back on bad ideas that come from their leaders. If the leader says, "Hey, I think we're going to go this way", and if someone in the meeting is able to say, "You know what? I think that's actually a mistake, and here's why", and nobody gets fired or publicly shamed, or it becomes some sort of problem, like if you see that in an organization, it's usually a good sign.
Psychological safety has been around as a concept for a while, and I'm really pleased to see it being taken more seriously in techie environments. Because I think in the beginning there was a little bit of a misunderstanding that, oh, this is a nice to have. It's just squishy, happy, feely stuff. Actually, it's not. Because in order for people to be able to make those decisions, they have to feel safe that they have the authority and the responsibility to make those decisions. Or if a decision needs to be made by discussion and collaboration, that all voices in the room are valid and that leaders will yield to better logic, better cases being made, are willing to listen, that's when you see a lot of psychological safety.
I think the opposite is true. There's certainly a lot of performative psychological safety that's not really authentic, where leaders will have lots of platitudes and lots of words written on the office wall about how much they embrace ideas from anywhere. They say all the right words, but when you actually see teams operating, you go to a team meeting, and there's 12 people in the room, and only two or three talk, right? Or a decision's made, or a plan is put forward, and the most senior person in the room says, "Are there any questions?" and nobody has any questions. I mean, people should always have questions. I mean, it's never that clear. If nobody asks any questions, it's probably because they're afraid that they'll look stupid if they ask the wrong question. That's a sure sign that there's not psychological safety in that room.
Mindful Leadership: Creating Space Between Stimulus and Response [24:29]
Thomas Betts: I know one of the things you teach and talk about is mindful leadership. I feel like we're getting there from here's the team to here's the leader on top of that team and supporting psychological safety and other aspects that it's not just put the poster on the wall. So, what does mindfulness look like in a leadership contest? What is that day-to-day behavior and not just theoretical and a poster?
Sam McAfee: Mindful leadership is about being aware of the decisions that you're making under pressure. It's not about being calm. I mean, there are aspects of mindfulness that are a lot larger than the way that I talk about it. But in the context of leadership in an organization, we're not talking about meditation. We're not talking about silent retreats. We're not talking about the level of calmness that you feel. It's really more about being aware of your thoughts and feelings and those of the people around you in the moment when the pressure is on. It's just about creating a tiny space between stimulus and response to slow down enough to make decisions with clarity. That's what mindful leadership gets you.
And you're right, it's directly related to psychological safety in many ways. I think it's worth our listeners to consider that when there is not psychological safety, or when there are leaders that are creating an environment where psychological safety is relatively low, it's not usually intentional, right? I have a great deal of empathy for senior leaders, given their position and the amount of pressure that they're under. I mean, I've done a lot of writing. Some folks have followed my blog or read my books, and I can really lambast the CEO pretty fiercely from my blog soapbox, but I think a lot of it is playful tone to make a point. The reality is I have a lot of sympathy for people in leadership positions because it is not easy.
A good buddy of mine who used to be a coaching client that I coached for many years, who's a good friend now, we were just on a call the other day, and he said, "Sam, if you told me 20 years ago that most of senior leadership is talking people off the ledge, I'm not sure I would've believed you. It's like this whole job is going around making sure everyone's okay". I think that senior leaders have a lot of pressure on them from above, from the market, from the board, from other peers, and so when there's low psychological safety, it's not typically conscious of a leader that's creating that situation. They are reacting to their environment. It may be that they aren't comfortable allowing other people to speak or allowing to be pushed back on their ideas, not in a conscious way, but because they're not really aware of what they're doing, right?
Mindfulness, in a way, is one of the tools that you can use to build more psychological safety in an organization because it allows a leader to look at their own behavior and to think in a measured way about whether that behavior is creating the kind of environment that's going to allow their teams to perform at the level they want them to perform and to produce the business outcomes that they want to see. Most of the time, it's the leader's own behavior that things they say offhandedly, not thinking things through, being tired and overworked and grouchy, whatever it is, saying that their door is open, but never being available. Not recognizing that their words have an enormous amount of power. So, it's really important to not flippantly say things without thinking them through, because they have a huge impact on the rest of the team.
When leaders start to become more mindful of these things, it allows them to shape the culture and the environment in their organization in a way that's very intentional and that will produce the kinds of outcomes that they're looking for, often in an indirect way. But hey, leadership is an indirect job, right? You can't just control everything. You have to create conditions. It's more like a gardener. You plant the seeds. You water. You don't make the plants grow. Those plants will grow according to the conditions that they're in. Mindful leadership really embraces those principles.
Thomas Betts: Yes. Yes. Smile more is a line from Hamilton. Talk less, but listen more is really what you're getting to is sit down. When someone comes to you, listen to them before you just respond. Definitely always good advice. Just take a beat before you just jump into your default, because sometimes that is your gut reaction. You're going off emotion, not okay, here's what's actually best for the situation. Here's what that person's considering.
It almost works in hindsight. If someone's raising an issue to their manager, it may be the, this is the environment you put us in. Here's the garden that you're creating. You need to spend a little bit more time on it. Find those opportunities to say, "Yes, I may have done something wrong". It might be both of us need to take this opportunity to grow.
Sam McAfee: Yes. Usually, one breath is enough. It doesn't take that long. A couple of seconds is enough time biologically, cognitively for your brain to catch up with what's going on in the moment and to think. If you look at Thinking, Fast and Slow by Daniel Kahneman or other... Sorry, I've been nerding out on neuroscience books for a long time.
One of the things that's really interesting is the parts of the brain that are very automatic are super fast, right? If we were in the same room, and I tossed you a baseball, you would catch it before your brain even had a chance to catch up and tell your arm what to do. We have a part of our brain that's very reactive that has kept us alive. It's there for evolutionary reasons. That's not the part of the brain that should be running the meeting, right? The slower, more methodical, thoughtful part of the brain is the one that we want in charge of the organization.
Thomas Betts: Yes. The runaway from the animal chasing me.
Sam McAfee: Yes, exactly. Yes. We're not like-
Thomas Betts: Very important to run away, but not in this situation.
Sam McAfee: Right. We're not being chased by actual tigers, most of the time.
Humanize: AI‑Supported Leadership and the Human‑in‑the‑Loop Future [31:13]
Thomas Betts: That's not my experience writing software at least. I want to wrap it up going into where we're at now and where we're headed. Tell us a little bit about what Humanize is–the AI-powered leadership platform. Where do you see AI as a tool that can help leaders, and where should people be cautious about the AI snake oil that's being sold out there?
Sam McAfee: Well, Humanize came out of a lot of work. It's a relatively new product. We're only about a year old, a little bit less at this recording, but coming along fast. But it came out of many years of collaboration. My colleagues and I have been trying to help organizations improve their leadership, improve their business outcomes to lead in a more mindful and humane and psychologically safe way. We're definitely coming at this with a point of view. There's a lot of research showing that these more humane ways of leading also produce better outcomes as well. One needs to look only at the Phoenix Project, or Gene Kim's work, or Radical Enterprise by Matt Parker. There's a lot of work being done by thoughtful people to show that these better, more modern ways of leadership are actually effective. They're not just nice to have.
We built Humanize to help leaders with difficult decisions. A little bit like what I do manually, this tool is a platform to enable leaders to go and discuss challenges that they're having, and it will help them reframe the problem and point them to tools and resources that they can use to tackle those problems. We've collected knowledge from a cohort of thought leaders and colleagues across a range of disciplines. Some very technical or product development, others, leadership, culture, business, organization, communication skills, all of those things. We've poured it all into the system, and then the system is able to interact with you and help you with your goals as a leader.
We've been very careful to balance... This is early days, so we're still figuring it out. I encourage people to try it out and give us feedback. We also need to be experimenting and learning from our users. But basically, we are calibrating the point of human intervention. The robots can help us a lot, but they can't help with everything, and so we are trying to figure out where it's appropriate for someone to raise their hand and ask for a human to intervene and maybe provide some coaching or some feedback, a listening ear, whatever it is. Humanize is built around that principle. It's not removing the human from the loop, but trying to figure out where the human goes in the loop, right?
It's interesting for us that we're building a tool that... We don't wave the AI flag around that much on the website, but yes, there is AI in the brain. It is built on an AI platform, and then we're building the platform with AI, right? We're generating code. We're using tools like Cursor and things like that. Which is really interesting because this is different than the last startup I worked on, just in terms of how we write code and push it to production. A lot has changed in terms of our own workflows. We're still a small, scrappy team of three. But the great thing for me is the speed and fluidity that we can communicate and deploy new features when you're a team of three in the proverbial garage, shipping multiple features a day. That's a really exciting place.
It's a lot of meta for me. It's a lot of interesting, how are we embracing the values that we're espousing to our customers and our clients in how we're building the tool itself, right? We put a lot of thought into how the design needs to enhance human interoperability, like communication between humans, but then also sometimes you need to hand things off to an agent. How all that fits together, I think we don't really know. I mean, I've had the pleasure of talking to a lot of tech leaders in the last few months for a separate project, actually, around how AI is changing their workflows. I would say what I see right now at the beginning of 2026 is it's still pretty Wild West. There are lots of patterns that are emerging that aren't super clear, but there are some patterns. But the speed of change is so fast.
I mean, even just in terms of the tools we're using to build our platform, we've swapped out some components, or some ideas, or some systems from six months ago where we were using something different, and then now there's a better way. That's all the more reason why we have to have a flexible experimental mindset in doing this. We don't know exactly what's going to work, and so it's really important for us as our organization grows that we, not my favorite phrase, but eat our own dog food, as they say. Or eat in our own restaurant. Maybe that's a better way of putting it.
Yes, I think it's really hard to say. We're really at an interesting point technologically where there are patterns from previous phases or rounds of technological innovation. We were joking about earlier, the early websites, the early mobile. There's a lot of ways in which AI is just like that. It's not completely different to everything that's come before. But then there are also ways where it is pretty different, and we have to work carefully as a community to figure out what's different and what's the same. I think being thoughtful, having conversations like this, it's really important for us to share knowledge with each other, open source. All of those things are really crucial at a time like this where, frankly, nobody really knows exactly how it's going to work out two, three, five years from now. It's an exciting time.
Thomas Betts: Yes. That's one of the goals of InfoQ is information Robin Hoods. We like to have these conversations. We like to get that information out there, start more discussions. There's so many opportunities for people to learn. Like you said, your product is a way for leaders to use AI to help them learn. I hope they're looking for those opportunities, including listening to this show. But unfortunately, we're out of time. We need to wrap it up, so Sam McAfee, thanks again for joining me today. This is a fantastic discussion. I'm sure we could have kept going for hours.
Sam McAfee: Thanks so much for having me. This was really fun.
Thomas Betts: Listeners, we hope you'll join us again soon for another episode of The InfoQ Podcast.
About the Author
Sam McAfee
I work with senior product and technology leaders who are responsible for decisions that can’t be easily reversed.
My focus is mindful leadership under real pressure: moments where speed, certainty, or consensus are tempting, but clarity matters more.
Over the last 25+ years, I’ve seen how poor decisions rarely come from lack of intelligence or effort. They come from unexamined assumptions, emotional noise, and systems that reward momentum over judgment. Mindfulness, as I practice it, is not about calm or self-improvement. It’s about seeing what’s actually happening and choosing deliberately.
I’m selective about where I engage. This work only makes sense when leaders have real authority, are willing to slow down when it’s uncomfortable, and are accountable for outcomes, not just alignment.
If you’re looking for frameworks, motivation, or ongoing reassurance, I’m probably not a fit. If you’re navigating complexity, tradeoffs, and irreversible choices, and want a clearer view of what you’re actually deciding... that’s where I do my best work.
Show moreShow less
You can keep up-to-date with the podcasts via our RSS Feed, and they are available via
SoundCloud,
Apple Podcasts,
Spotify,
Overcast
and YouTube.
From this page you also have access to our recorded show notes. They all have clickable links that will take you directly to that part of the audio.
関連記事
今日のまとめ
AI日報で今日の重要ニュースをまとめ読み