InfoQメディア報道·2026年2月26日 20:03·約8分

ソフトウェアリーダーシップチームを成長させる教訓

#組織開発 #エンジニアリングマネジメント #リーダーシップ育成 #チーム構築 #カルチャー形成 #QCon

整理・翻訳:ainew.jp 編集システムAIによる自動処理作り方と限界

本文の状態

日本語全文を表示中

詳細モードで約8分の本文を読めます。

同じ出来事の情報源

この情報源を基点に整理

InfoQ

まず要点

Thiago Ghisiが、マネージャーや上級ICを指導して、自身の下に強靭なリーダーシップグループを構築した経験を共有。

Source Article

元記事を日本語で読む

本文に関係しない購読案内、埋め込み通知、サイト内プロモーションは除いています。

InfoQ ホームページニュースソフトウェアリーダーシップチームを育てる上での教訓

ソフトウェアリーダーシップチームを育てる上での教訓

2026年2月26日 4分で読める

InfoQに寄稿する

この記事を聴く - 0:00 再生準備完了お使いのブラウザはオーディオ要素をサポートしていません。 0:00 0:00 通常速度 1.25倍速 1.5倍速読み上げリスト

Thiago Ghisiは、QCon Londonでの講演「エンジニアリング組織を育てる上での教訓」において、マネージャーと上級IC（インディビジュアル・コントリビューター）を導き、自身の下に強靭なリーダーシップ集団を構築した方法を説明した。定期的な同期、期待値の調整、そしてより広範な目標への整合を図ることで、リーダーたちは文化とパフォーマンスの増幅器となった。文化とは、口にするものではなく、実際に行うことであると彼は主張した。

Ghisiは、自身の役割が上司のリーダーシップ集団とその儀式に参加することだけではなく、意図的に自身の下にリーダーシップ集団を構築することでもあると気づいたことが大きな啓示だったと述べた。彼らはオフサイトミーティングから始め、マネージャーと上級ICが繰り返し発生するインシデントやスコープの混乱といった個人的な苦労を共有し、また、Lean Inceptionに似た形式で、チームとして次のサイクルの優先事項と目標に整合を図った。それにより共感と信頼が築かれたと彼は語った。

強靭なリーダーシップチームを構築するために、彼らはより広範な組織目標への整合を図ったとGhisiは説明した。

私たちは、週次または隔週で一貫した同期ミーティングを設定しました。そこでは彼らが互いに責任を果たすよう求め合い、最も重要なことを互いに思い出させ、組織にとって最も重要なプロジェクトを支援するためにICを再配置し合いました。たとえそれが彼らの直属のスクワッドにとって必ずしも最善でない場合でもです。

Ghisiは、彼らが期待値の調整も行っていると述べた。サイクルの開始時に、各マネージャーは直属の部下に対する期待値を草案し、同僚からのフィードバックを得る。これにより、各レベルで「良い」状態がどういうものかについて全員が合意し、彼らが達成に注力していることが、より広範な組織および会社の優先事項と整合しているかを確認する。

明確なスコープと、同僚を自身の「第一のチーム」と捉える意識を持たせることで、そのリーダーシップチームの結束に投資した結果、彼らは文化とパフォーマンスの増幅器となったとGhisiは語った。

私がボトルネックになるのではなく、彼らが互いに助け合い、フィードバックを与え合い、何を推進し何を押し返すかを決定し、将来のビジョンと戦略について議論し反復を重ねているのです。

文化とは、あなたが何を言うか、どのような儀式を持つかというよりも、あなたが何をし、変化や危機の際にどのように反応するか、どのような価値観を示すか、どのような行動を促進し、どのような行動を押し返すか、ということです。口先だけではなく、実際に行動で示すことだとGhisiは主張した。

あなたは常に自分自身を向上させようとしている人ですか？理にかなった提案があれば、本当に耳を傾け、それを取り入れていますか？リーダーシップチームの前で悪く見られることを恐れ、直属の部下や同僚との対立や困難な会話、決断を避けていませんか？

Ghisiは、文書化せず、まず「なぜ」を説明することなく、組織再編を試みるべきではないと提案した。それは、潜在的なトポロジーや組織的・構造的変更についてブレインストーミングを始める前に、再編の大きな理由・動機・目標を記述した、非常にシンプルで短い1ページの文書でもよい。

物事を急いだり、繰り返しの会議で「ビジョン」を高レベルで伝えるだけにして、そのビジョンが議論に引き継がれることを期待しようとするたびに、私は伝言ゲームのように議論が完全に横道にそれることに気づかされ、驚かされました。

Ghisiは、彼らは成果を押し出す前に、人の問題を解決することを学んだと述べた。低パフォーマンスのスクワッドがあるなら、まず対人関係やスキルのギャップに対処すべきだという。ストレスが多く安全でないチームは、大規模な成果を出せない。

すべてが合意を必要とするわけではなく、それは良いことだとGhisiは言った。リーダーシップ集団が分裂した場合の決裁者を確立しなければ、行き詰まると彼は主張した。RACIマトリックスはここで大いに役立つ。

InfoQは、継続的改善と実験についてThiago Ghisiにインタビューした。

InfoQ: 継続的改善の文化をどのように確立しましたか？

Thiago Ghisi: 私たちは「学んだ教訓」を、私たちが行うすべてのこと、書くすべての文書、すべての大きな組織再編、すべての重大なインシデントの事後分析、そしてすべてのリーダーシップオフサイトに組み込みました。例えば、2つのスクワッドを統合したことが、実際には予想以上にオンコール負荷を増やしたと判明した場合、私たちはすぐに修正しました。このように文書化して透明性を示すことで、上手くいかないトップダウンの指示に固執しないことを示したのです。

人々は、「何か新しいことを試す」ことは「永遠にそれに縛られる」ことではないと学びました。つまり、私たちは混在したアプローチを取っています。正式な儀式（レトロスペクティブ、テックトーク、スキップレベルフィードバック、各チームとの月次詳細検討など）がある一方で、問題に対応する際の一貫したフォローアップ（私たちが非難よりも反復を重視し、リーダーシップチームとして常に耳を傾け、常に支援するために存在していることを示す）も行っています。

InfoQ: 適切なチームトポロジーを見つけるために、どのように実験しましたか？

Ghisi: それは、私自身と私の直属のチームの経験と、会社内の他のグループで通常うまくいっているパターン、トポロジー、インセンティブ、プロセスを見極めることの組み合わせでした。これは通常、他の会社や過去の経験からアイデアを借りようとするよりも、はるかに効果的です。

高レベルでは、私たちは常に摩擦のシグナル（未解決の依存関係や、広すぎるスコープに圧倒されているマネージャーなど）を探し、小さくテスト可能な変更を加えています。例えば、あるドメインが常に別のドメインをブロックしている場合、そのドメインに深いコンテキストを持つスタッフエンジニアを依存する側のチームに配置しました。あるいは、ロードマップが大きく重複している2つのスクワッドがある場合、四半期単位で「タスクフォース」として統合しました。私たちは初日からそれを実験とラベル付けしました。ボトルネックが解決すれば素晴らしいし、より混乱を招くなら元に戻す。これにより、チームは新しい構成（複数のスクワッドにまたがる統一されたオンコールローテーションなど）を試す心理的安全性を得られました。データが役に立っていないと示せば、方向転換することを知っているからです。

寄稿者について

この記事を評価する

このコンテンツは Culture & Methods トピックに属しています

関連スポンサー

InfoQで人気の記事

Anthropicの研究: AIコーディング支援は開発者のスキル習熟度を17%低下させる

OpenAI、Harness Engineeringを導入: Codexエージェントが大規模ソフトウェア開発を推進

jQuery v4をリリース: 約10年ぶりのメジャーバージョン

OpenAI、エンタープライズ全体でAIエージェントを構築、デプロイ、管理するプラットフォーム「Frontier」をローンチ

オンボーディングを48時間から4時間に短縮: Amazon Keyのイベント駆動プラットフォームの内部

マイクロサービスとLLMによるソフトウェア進化: Chris Richardsonとの対話

The InfoQ ニュースレター

毎週火曜日配信、InfoQの先週のコンテンツまとめ。25万人以上のシニア開発者コミュニティに参加しましょう。例を見る

私たちはあなたのプライバシーを保護します。

原文を表示

InfoQ Homepage News Lessons from Growing a Software Leadership Team

Lessons from Growing a Software Leadership Team

Feb 26, 2026 4 min read

Write for InfoQ

Listen to this article - 0:00 Audio ready to play Your browser does not support the audio element. 0:00 0:00 Normal1.25x1.5x Like Reading list

Thiago Ghisi explained how he guided managers and senior ICs to build a resilient leadership group beneath him in his talk Lessons from Growing Engineering Organizations at QCon London. Regular syncs, expectation calibration, and alignment on broader goals made leaders multipliers of culture and performance. Culture is what you do, not what you say, he argued.

A major epiphany was realizing that his role wasn’t just about being part of the boss’s leadership group and rituals, but also about intentionally building a leadership group beneath him, Ghisi said. They started with an off-site where managers and senior ICs shared personal struggles, like repeated incidents or scope confusion, and also aligned on priorities and goals for the next cycle as a team in a format similar to a Lean Inception. That built empathy and trust, he mentioned.

To build a resilient leadership team, they aligned on broader organizational goals, Ghisi explained:

We set up consistent weekly or biweekly syncs where they’d hold each other accountable, reminding each other of the most important things and reallocate ICs to help on the most critical projects for the organization, even when that was not necessarily the best thing for their direct squad.

Ghisi mentioned that they do expectation calibrations. At the start of the cycle, each manager drafts expectations for their direct reports and gets peer feedback, ensuring they all agree on what "good" looks like at each level and if what they are focused on achieving is aligned with the broader organizational and company priorities.

By investing in that leadership team’s coherence with clear scopes and a sense of making their peers their first team, they became multipliers of culture and performance, Ghisi said:

Rather than me being the bottleneck, they are helping each other, giving each other feedback, deciding what to promote and what to push back, and discussing and iterating on visions & strategies for the future.

Culture is less what you say or what rituals you have and more what you do and how you react during changes or crises, what values you show, what behaviors you promote, what behaviors you push back. It’s walk the walk, not talk the talk, Ghisi argued:

Are you someone who is constantly trying to improve yourself? Are you really listening and incorporating suggestions when they make sense? Are you afraid to look bad in front of your leadership team and avoid conflicts or difficult conversations and decisions with your direct reports or with your peers?

Ghisi suggested that you shouldn’t try to reorganize without documenting it in writing and describing the "Why" first. It could be a very simple and short one-pager describing the big reasons/motivations/goals for the reorganization, before starting the brainstorming on potential topologies/organizational/structural changes:

Every time I tried to speed things up or just to tell "the vision" at a high level in repeated meetings and hope that vision would carry over into discussions, I was reminded and surprised by the telephone game with discussions going completely sideways.

Ghisi mentioned that they learned to fix people’s issues before pushing delivery. If you have a low-performing squad, address the interpersonal or skill gaps first, he said. A stressed, unsafe team can’t deliver at scale.

Not everything needs consensus, and that is a good thing, Ghisi said. Establish who the tie-breaker is if the leadership group is split, otherwise you get gridlock, he argued. The RACI matrix can help a lot here.

InfoQ interviewed Thiago Ghisi about continuous improvement and experimentation.

InfoQ: How did you establish a culture of continuous improvement?

Thiago Ghisi: We baked "lessons learned" into everything we do, in every document we write, every big reorganization, every major incident postmortem, and every leadership off-site. For instance, if we discovered that merging two squads actually caused more on-call load than expected, we’d fix it quickly. That transparency in writing showed we weren’t wedded to top-down directives if they weren’t working.

People learned that "trying something new" doesn’t mean "stuck with it forever." So it’s a mix: we have formal rituals (like retros, tech talks, skip-level feedback, monthly deep dive with each team) but also consistent follow-through in how we respond to problems—showing that we value iteration over blame and that we - as the leadership team - are always listening and always there to help.

InfoQ: How did you experiment to find the right team topologies?

Ghisi: That was a mix of my own and my direct team experience, with seeing what patterns, topologies, incentives, and processes were usually working inside the company in other groups. That usually works a lot better than trying to borrow ideas from other companies or past experiences.

At a high level, we are constantly looking for friction signals—like unresolved dependencies or managers overwhelmed by an overly broad scope—and making small, testable changes. For instance, if one domain was constantly blocking another, we’d place a staff engineer who had deep context in that domain onto the dependent team. Or if we saw two squads with a lot of overlapping roadmaps, we’d merge them for a quarter as a "task force." We’d label it an experiment from day one: if it solved the bottleneck, awesome; if it caused more chaos, we’d revert. This gave teams psychological safety to try new configurations (like unified on-call rotations across multiple squads), knowing we’d pivot if the data said it wasn’t helping.

About the Author

Rate this Article

This content is in the Culture & Methods topic

ソフトウェアリーダーシップチームを成長させる教訓

元記事を日本語で読む

調べる

選ぶ

サイト