リーダーシップ

このページはリーダーシップのポインターを掲載しています。 最初のいくつかの見出しは、チーム構造ページで定義されているグループ分けを使って、どのグループに適用されるかを示しています。

Managers of One

オールリモートの組織では、私たちは各チームメンバーが Manager of One であることを望みます。Manager of One は、私たちの Efficiency バリューに紐づく属性です。GitLab で成功するには、チームメンバーは目標を達成するための日々の優先事項を自ら立てる必要があります。Manager of One は自分の仕事のトーンを定め、アイテムを割り当て、何をやり遂げる必要があるかを判断します。どんなロールであっても、セルフリーダーシップは Manager of One として成功するために不可欠なスキルです。

1. GitLab では、個人コントリビューターであれリーダーシップチームのメンバーであれ、全員にリーダーシップが求められます。
2. リーダーとして、GitLab のチームメンバーはあなたの行動に倣うので、常に正しいことをしてください。努力をもって率先垂範してください。
3. GitLab に加わる全員が、自らを私たちの バリューのアンバサダーであり、私たちの 文化の守り手であると考えるべきです。
4. 行動は社内でも社外でも一貫しているべきです。私たちは社外でも正しいことをします。
5. GitLab はあなた自身が何が最善かについての判断を尊重します。あなたが自分自身を最もよく知っているからです。どこか別の場所により良い機会があるなら、会社への忠誠心から GitLab に留まる必要はありません。
6. 厳しい時期には、人はお互いのためにやっているときに最大限の努力を注ぎます。
7. 私たちは 非同期で働きます。率先垂範し、起きたことはその都度 Issue に書き留める必要があることを全員に理解してもらってください。ドキュメントによってチームに説明責任を持たせてください。
8. 私たちは民主主義やコンセンサス駆動の会社ではありません。コメントや意見を述べることは奨励されますが、最終的にはすべてのフィードバックを聞いたうえで 1 人が決定します。
9. 意見が異なることや建設的な議論をすることは奨励されますが、どうか 知的に議論してください。
10. 私たちは結束よりも真実の探求を重んじます。
11. 私たちは可能な限り ミーティングを避けます。ミーティングは非同期のワークフローを支えず、タイムゾーンの違いから実施が難しいからです。
12. ミーティングは時間どおりに始め、自分も時間どおりに参加し、全員が揃っているか尋ねず、時間どおりに来た人を、遅れて来る人を待ったり遅れて来た人のために繰り返したりして罰しないでください。ミーティングがプロセスや意思決定のブロックを解消したときは、それを祝うのではなく、次の問いに向き合ってください: 今後、ミーティングを必要とせずにブロックを解消するにはどうすればよいか？
13. ミーティングの準備と参加の仕方には意図を持ってください。非同期コミュニケーションは、皆が 自分のカレンダーを確認し、ミーティングの前に準備するときに最もうまく機能します。
14. 私たちは フィードバックを、たくさん与えます。改善のための提案を惜しまないでください。それが私たちの成長を助けます。フィードバックを通じて他者を助けることに誇りを持ってください。
15. 改善に注力してください。社外の人と会うときは、いつも私たちが何を改善すべきだと思うか尋ねてください。
16. Paul Graham のアドバイスに従い、組織をよりシンプルにするよう努めてください。
17. 「お聞き及びかもしれませんが」「檻の中で暮らしていない限りご存じでしょうが」「誰もが知っているように」「ご存じかもしれませんが」といった趣旨の発言は有害です。知っている人にはそれを言う必要がありません。知らない人は何かを見逃したように感じ、その背景を尋ねるのを恐れるかもしれません。
18. 物事を進めるために、他人の名前を使ったり、自分の肩書きを持ち出したり、その他の方法で 「権威をかさにきたり」しないでください。
19. 目標と適切なタイムラインを設定する責任を引き受けることで、自分自身と自分のロールの CEO として振る舞ってください。自分のコントリビューションに優先順位をつけ、すべてを知ることは不可能であることを認識してください。
20. 自分の目標の状況について、チームやピープルリーダーと明確にコミュニケーションしてください。課題となる領域に対処したり、割り当てられた期間内に達成できない目標を再評価したりするために、迅速に行動してください。

GitLab における Manager of One の行動例

1. 同期的なブレインストーミングのコールへの参加を求められたとき、チームメンバーは代わりに Issue を開き、チームのアイデアを非同期で求める。
2. ピープルリーダーが、メンターになることで、私たちの ダイバーシティ、インクルージョン、ビロンギングのバリューを推進する。
3. チームメンバーが学習と能力開発のための専用時間を確保し、セルフサービスとセルフラーニングを日常的に実践する。
4. 新しいロールに就いたチームメンバーが、学習しているプロセスに非効率を見つける。求められたり監督されたりすることなく、変更を提案するマージリクエスト（MR）を開き、レビューのためにマネージャーにアサインする。
5. 予定されていたミーティングのアジェンダがコール終了予定の 10 分前に完了したとき、参加者がコールを早めに終了する。
6. ピープルリーダーが、私たちの CREDIT バリューを体現する新しいチームメンバーを採用する。
7. あるトピックについて議論するために他者の時間をもらう前に、自分の考えを整理する時間を確保し、提案を作成する。
8. Manager of One が、フィットネス、食事、有給休暇、個人の予定のためにカレンダーをブロックすることで、ウェルビーイングを優先する。
9. チームメンバーが、マネージャーやチームがすでに把握していると思い込むのではなくブロッカーを表面化させ、同時に パブリックに働くことと 低い羞恥心をもって他者のブロック解消にも取り組む。

Interim と Acting のリーダーシップ

場合によっては、Management グループ、Director グループ、Senior Directors and VPs、さらには E-groupの個人が「Interim」または「Acting」の肩書きを持つことがあります。

1. Acting は、その人が一時的にそのロールを担っており、一定の時間が経過した後、または外部からの採用など他の条件が満たされた後に、元のロールに戻ることを意味します。
2. Interim は、その個人がそのロールへの昇進に向けて取り組んでいることを意味します。

いずれの場合も、その人はそのロールのすべての責任を果たします。そのロールの今後について質問があれば、本人またはそのマネージャーに尋ねてください。

各部門には、これらのロールを担う資格がある人についての独自の基準があるので、所属部門のキャリア開発ページを確認してください。

意思決定

意思決定のリーダーシップページを参照してください。

コミュニケーションは階層的ではなく直接的であるべき

ほとんどの企業は、指揮命令系統を通じて上から下へとコミュニケーションを行います。このコミュニケーションの流れはしばしばマネージャーに権限を与えますが、同時に非効率も生み出します。チームメンバーが自分の仕事を進めるためにコミュニケーションを取る必要のある相手と直接つながれないからです。GitLab では、すべてのチームメンバーが、Issue を素早く解消したり、問題を解決したり、その他の方法で支援したりするために、誰であれ適切な人（または複数の人）に連絡を取ることが奨励されます。ただし、直属のマネージャーには配慮し、依頼の cc に入れてください。私たちは、チームメンバーにマネージャーを通じてエスカレーションさせ、返答が戻ってくるのを待たせるような不要な摩擦を奨励しません。重要なのは結果にたどり着く効率です。CEO に Slack を送る、VP に Slack を送る、同僚に Slack を送る。GitLab を成功させるために必要なことをしてください。

マネージャーは、コミュニケーションのボトルネックやサイロになるべきではありません。 誰もが、問題を解決するために持ちうる最善の情報をもって、誰にでも気兼ねなく連絡できると 感じられるべきです。 これは、より 効率的で、透明で、協働的な働き方です。

フィードバックを与える

定期的に フィードバックを与えることは、マネージャーとチームメンバーの双方にとって極めて重要です。フィードバックは、1-to-1 ミーティングとは別の、コーチングセッションという形を取ることもできます。フィードバックを与えることは準備でもあり、状況に応じて、別個のアジェンダを作成し、次のように構成すべきです:

1. コンテキストを提供する。
2. これは次の条件を満たすか自問する:
   • アクションにつながるか
   • 具体的か
   • 親切か（そのフィードバックはその人を助けるか？ 注: 親切（kind）であることは、感じが良い（nice）ことと同じではありません。）
   • 客観的か（公平に近い）
   • 職務ロールやコンパレシオに関連しているか

根本原因を特定する

パフォーマンスが低下したとき、それに取り組む最善の方法は、根本原因を突き止めようとすることである場合があります。これは言うは易く行うは難しです。CEB（現 Gartner）が、これを助けるために作成した パフォーマンス Issue の根本原因診断 という優れたツールがあります。根本原因を特定することが常に可能または適切とは限らないので、その場合は パフォーマンス不足プロセスに従うべきです。

ネガティブなフィードバックへの対応

リーダーとして、ネガティブな フィードバックへの対応の仕方は、あなたのチームに大きな影響を与えます。権威ある立場の人に懸念を伝えるのは難しいことがあると心に留め、感受性と感謝をもって対応してください。特に、次のことを念頭に置くことをおすすめします:

• 議論したり身構えたりしない。フィードバックをありのままに受け入れてください: それは、あなたの仕事やプロフェッショナルな関係を改善しようとする試みです。説明する必要がある場合でも、共感的であり続けるよう努めてください。
• 行動を後回しにするのは問題ありません（むしろ望ましいことです）。ネガティブなフィードバックを受けると、私たちはしばしば自分の行動を正当化するか変化を約束しなければならないと感じます。そして、大きなチームに責任を負っているとき変化は必ずしも容易ではないため、正当化がデフォルトになります。フィードバックを評価してどう進めるかを決めるのに時間が必要だと言って構いません。
• ネガティブなフィードバックへの正しい対応の仕方
• あなたの部門や組織の別の部分のチームメンバーがあなたのところに来て、自分自身やそのレポートのコントリビューションがあなたのレポートに評価されていないと感じると言った場合、マネージャーはこれを解決しようとすべきです。研究によれば、これはアンダーレプレゼンテッドなマイノリティにより起こりやすいとされています。なお、DRI はフィードバックを認めずに無視する自由があること、そして コントリビューションを評価することはそれに同意することと同じではないことに留意してください。ここで問題にしているのは、他人のアイデアを出典を示さずに横取りすること、または人身攻撃な発言でアイデアを退けることです。

1対1

1-1を参照してください。

スキップレベルのやり取り

skip-levelsを参照してください。

あなた個人の README

チームメンバーの README ページは、その人と一緒に働くのがどのようなものかを他者が理解するのを助けることを目的としています。特に、これまで一緒に働いたことのない人にとって有用です。それはまた、意図的に弱さを見せることで信頼を築き、良い働きの関係についての自分の考えを共有し、今あるいは将来あなたのチームにいるかもしれない人々の不安を減らそうとする、善意の試みでもあります。

README は、その人がどのように働くかについての真摯なレポートを提供し、バイアスや思い込みを減らし、共通のフレームワークに基づいて人々が協働できるようにします。GitLab の 透明性バリューの一環として、私たちは各 GitLab チームメンバーが自分自身の README を作成することを検討するよう奨励します。

ディビジョン別 README

GitLab のディビジョン README ページを参考のために以下にリンクしています。他の README を読むことは、自分の README に何を含められるかについてのアイデアを得る重要な方法です。これらをガイドとインスピレーションとして活用してください。

• Engineering の README
• Marketing チームの README
• Sales チームの README
• Finance チームの README
• Legal チームの README

あなたの README を作成する

1. README-template をコピーして、お気に入りの Markdown エディターに貼り付けます。Markdown エディターを持っていない場合は、Typora や Bear がおすすめです。
2. 推奨されるセクションを記入します。各セクションは 任意 であることに注意してください。記入するのが気が進まないものは削除でき、自分にとって興味深い、または重要なセクションを追加できます。
   1. あなたの ディビジョンに README をホストするページが すでに ある場合（上記参照）、そのディレクトリ内に 新しいページを追加するガイドラインに従ってください（例えば、マーケティングチームのメンバーである Darren M. は、/handbook/marketing/readmes 内に新しいディレクトリとページを追加し、/handbook/marketing/readmes/dmurph を作成します）。
   2. あなたの ディビジョンに README のための受け皿ページがまだない場合、まず ディビジョンのハンドブックセクション内に 新しいページを追加する（readmes）ガイドラインに従い、その後 readmes 内に自分のユーザー名ディレクトリを作成してください。
3. .gitlab/CODEOWNERS ファイルに、自分の README と自分自身を codeowner として追加すればボーナスポイントです。

あるいは、GitLab の README プロフィールカスタマイズ機能を ドッグフーディングして README を作成することもできます。GitLab プロフィールに README で詳細を追加する方法については、ドキュメントに従ってください。あなたのプロフィールのリンクをディビジョンの受け皿ページに追加するのを忘れないでください。

あなたの README を周知する

README を作成したら、次の場所からそれへのリンクを追加することを検討してください:

• Google ドキュメントのアジェンダやカレンダーの招待
• あなたの GitLab.com プロフィール
• あなたの Slack プロフィール
• あなたのメール署名

これにより、他者があなたと働く前にあなたの README を読めるよう、最大限の可視性が得られます。これにより、相手はあなたの働き方やコミュニケーションの好みを考慮でき、理想的には表される共感の全体的なレベルが高まります。

README は、私たちの バリューに馴染みのない、GitLab の 外部 の人々と働くときに特に強力です。README は 透明性のビーコンであり、あらゆる働きの関係のトーンを定めるのに役立ちます。

コーチング

コーチングとは何か？

コーチングとは、他者が自分自身を助けるのを助けることです。アドバイスを与えたり、指示したり、何をすべきか伝えたりすることではありません。コーチングとは、未来に注目し、コーチを受ける人がどこにいたいか、何を達成したいかを特定することです。 GitLab では、コーチングを、人々が自分で考え、自分なりの答えを見つけ、自ら設計したアクションにコミットするのを助ける会話と定義しています。コーチとしてのあなたの役割は、現在の状態から未来への道筋を明確にすることです。コーチは、コーチを受ける人がより深いインサイトに基づいて十分な情報に基づく選択をできるようにすることで、これを行います。

マトリックス組織なし

no-matrix-organizationを参照してください。

安定したカウンターパート

私たちは、人々が一緒に働く必要のある他の機能のための安定したカウンターパートを与えることで、自然発生的なクロスファンクショナルな協働を促進したいと考えています。例えば、各 Strategic Account Executive（SAE）は 1 人の Sales Development Representative（SDR）と働きます。私たちの カテゴリーでは、開発者の各バックエンドチームが Product Manager（PM）と フロントエンドチームにマッピングされます。

人々に 安定したカウンターパート を与えることで、より社会的な信頼と親しみが生まれ、意思決定が速まり、コミュニケーションの問題が防がれ、対立のリスクが減ります。こうして私たちは、マトリックス組織の欠点なしに、効果的にクロスファンクショナルに働けます。

ファクトリー vs. スタジオ

私たちは ファクトリーとスタジオの最良の組み合わせを望んでいます。スタジオの要素とは、ユーザーから CEO まで、誰もが何についても口を挟めることを意味します。自分の作業領域の外に踏み出して貢献できます。ファクトリーの要素とは、全員が明確に割り当てられたタスクと権限を持つことを意味します。

効果的なエスカレーション

チームメンバーは、予期しない課題を解決するために助けが必要なとき、Issue をエスカレーションすることに気兼ねを感じないようにすべきです。効果的なエスカレーションは良いものです。なぜなら、意思決定を速めるからです。チームメンバーが Issue をエスカレーションするとき、他のチームメンバーの意見が異なる、アライメントに助けが必要、あるいは重大なトレードオフが必要であるために、別の人が意思決定者やアドバイザーとして加わります。エスカレーションは明確さと前に進む道筋をもたらすことができ、何を、どのように、いつエスカレーションするかを知っている場合、エスカレーションを始める人にとってシニアリティの証となり得ます。

この Medium の記事で述べられているように、明示的なエスカレーションは次の 4 つの問いに答えるべきです:

1. これは、私がエスカレーションしている相手の人／チームにとってなぜ重要か？
2. その課題の関連する詳細は何か？
3. あなたは何を試したか？
4. あなたは何を必要としているか？

Issue をエスカレーションする人は、マネジメントの系統にいる人々を驚かせるのを避けるべきです。これは、他の関連するチームメンバーがエスカレーションが起きていることを認識しているべきだということを意味します。例えば E-Group では、メンバーは、これが起きていることを他の関連するメンバーにまず知らせることなく、エスカレーションを CEO に持ち込まないことに同意しています。

マネージャーやピアにまず知らせることには、いくつかの例外があるかもしれません。例えば、チームメンバーがマネージャーやピアに懸念を表明することに 安全を感じず、報復なしに標準的な通知をもって効果的にエスカレーションできないと感じる場合です。例外が適切な場合もありますが、それはまれであるべきです。

チームメンバーが Issue をエスカレーションした後、エスカレーション先の人が下した決定に 同意しないが、コミットして擁護するとしても問題ありません。

プロセスは悪い評判を得ている

プロセスは悪い評判を得ています。それは、私たちが GitLab で避けようとしている事柄についての評判です。必要のないプロセスを持つと、それは官僚主義に変わります。良い例が承認プロセスです。私たちは、人々に自分で意思決定する権限を与えることと、必要な場所では素早く軽量な承認プロセスを持つことの両方によって、承認プロセスを最小限に抑えるべきです。

しかし、プロセスには良い側面もあります。社内でどうコミュニケーションするかについての文書化されたプロセスを持つことは、オンボーディングに費やす時間を大幅に減らし、スピードを高め、ミスを防ぎます。直感に反する効果として、それはプロセスを変えることも容易にします。名前も場所もなく、人々の頭の中に異なるバージョンで存在するプロセスを変えるのは本当に難しいことです。文書化されたプロセスを変更し、diff を配布する方がはるかに簡単です。

タレントの獲得と維持

マネージャーは、チームメンバーのタレントの獲得と 維持について多大な責任を負います。

• 自発的な離職、特に予期しない離職は少なくあるべきです。退職の最も一般的な理由は、マネージャーに紐づけられることがあります。
• 私たちは、候補者がオファーを辞退することが少ないことを望みます。特に理由が報酬でない場合はそうです。
• 私たちは、十分な量と質の候補者パイプラインを必要とします。特に重要なポジションではそうです。
• オファーが提案された候補者は、基準を満たすべきです。特により上位のポジションではそうです。
• グローバルなチーム を築いてください。ビジネスケースで示されない限り、「ベイエリア以外でタレントが見つからない」というのは、私たちの ダイバーシティ、インクルージョン、ビロンギングのミッションと Location Factor KPIに反します。

高出力マネジメント

GitLab のリーダーシップとマネジメントのアプローチは、書籍「High Output Management」で扱われている原則を用いて構築されました。詳しくは High Output Managementを参照してください。

ハイパフォーマンスなチームの構築

結果を出すためのチームを築くことは、効率と イテレーションを改善するうえで非常に重要な側面です。ハイパフォーマンスなチームは常に結果を出します。GitLab のリーダーとしてのあなたの役割は、望ましいレベルのパフォーマンスと生産性に到達するハイパフォーマンスなチームを育てることです。GitLab のハイパフォーマンスなチームが示す特定の特性があります:

• 自分たちの目的と目標について明確なビジョンを持っている
• 目標達成にコミットし続けている
• 対立を管理している
• お互いに効果的なコミュニケーションと健全な関係を保っている
• チームとして全会一致の決定を下している

Jeb Hurley、Brainware Partners の共同創業者兼マネージングパートナーとの対話のリプレイをご覧ください。そこでは次のことについて議論しました:

1. リモートチームにおける信頼、生産性、ウェルビーイングの管理
2. 信頼の行動、生化学、ダイナミクス
3. 信頼を築くことのインパクトを測定し報告することの価値

マネージャー向けの ハイパフォーマンスなチームを構築するコンピテンシーのスキルと行動:

• 協働、コミュニケーション、信頼、共有された目標、相互の説明責任とサポートを育むことで、チームワークを体現し奨励する
• 重要なトピックについて、複数のアサインメントのタイムマネジメントと Direct Responsible Individuals（DRI）とともに、結果とのバランスが取れた環境を育む
• チームメンバーが Manager of One であることを後押しし、キャリアで専門的に成長するためのツールを与える
• 信頼に基づく、委任、説明責任、教えやすさのインクルーシブな環境を作ることで、トップタレントを惹きつけ維持する

ハイパフォーマンスなチームを構築する戦略

Drexler-Sibbet Team Performance Model は、GitLab で ハイパフォーマンスなチームを構築するのを助ける優れたツールです。このモデルは、チームのためのロードマップと共通の言語を提供します。それは、チームがどう協働するかを簡略化して記述したもので、ハイパフォーマンスに到達するためにチームが注力すべき最も重要な事柄を浮き彫りにします。GitLab では、これをハイパフォーマンスなチームを育てるための参照枠として使えます。これは、マネージャーが新しい、そして既存のチームメンバーに、次のことによってチームのミッションと方向性を確実に知ってもらうのに役立ちます:

• チームを形成する
• チームが何をするかを導く
• チームがどれだけうまくいっているかをモニタリングする
• チームがどこで苦戦しているかを診断する、またはチームの成功の鍵を特定する。

ハイパフォーマンスなチームを育てる 7 つのステージ:

1. オリエンテーション - なぜ私たちはここにいるのか？ チームメンバーは、チームのアイデンティティの感覚と、個々のチームメンバーがどう収まるかを見る必要があります。
2. 信頼の構築 - あなたは誰か？ チームメンバーは互いへの相互の敬意を共有し、信頼に基づく関係にオープンで協力的です。
3. 目標の明確化 - 私たちは何をしているのか？ 前提が明確にされ、個々の前提が、終わりの状態の明確なビジョンとともに知られるようになります。
4. コミットメント - どうやってそれを行うか？ チームメンバーは、どう意思決定し、どう仕事をするかを理解します。
5. 実装 - 誰が、何を、いつ、どこで行うか？ チームメンバーは明確さの感覚を持ち、共有された目標のアライメントによって効果的に活動できます。
6. ハイパフォーマンス - すごい！ チームは期待以上のことを成し遂げています。チームは飛躍し、創造性が育まれ、目標が上回られます。
7. リニューアル - なぜ続けるのか？ チームは認知を与えられ、価値ある仕事を生み出す個人の達成を祝います。学んだ教訓を振り返り、未来のために再評価します。

マネージャーのリソース: バーンアウトの特定と対処

ハイパフォーマンスを構築し維持することには、チームのウェルビーイングと潜在的なバーンアウトに気を配り続けることが含まれます。GitLab の結果駆動の文化、AI を中心としたプロダクトイノベーションの要求、ペースが速く絶えず進化するビジネス環境のなかで、私たちの組織は、野心的な目標の達成とチームメンバーのウェルビーイングの維持との間の重要なバランスを認識しています。誰もがこのハンドブックの マネージャーがバーンアウトを特定し対処するために設計されたリソースにアクセスできます。これはチームのパフォーマンスに継続的な影響を与えます。

マネージャー M-Team グループ

M-team は、メンバー間での同期ミーティングを可能にするタイムゾーンにいる 3 〜 6 名のマネージャーで構成される、マネジメントのサポートグループです。M-team は、メンバーが合意したケイデンスで、「今週は何が大変か？」をアジェンダとする定例ミーティングを設定すべきです。誰がファシリテートするかを決め、各人がミーティングで自分の課題を議論してもらう機会を得ます。自分の番になったら、自分が苦労していることについて少し話します。M-group は、グループメンバーが弱さを見せることを厭わないよう、ある程度の 守秘に同意します。弱さを見せることは信頼につながり、グループにとってより良い成果につながります。

M-team ミーティングを始めること、または参加することに興味があれば、#managers Slack チャンネルで他のマネージャーに連絡してください。

記事

1. Carta’s Manager’s FAQ
2. Carta’s How to hire
3. How Facebook Tries to Prevent Office Politics
4. The Management Myth
5. Later Stage Advice for Startups
6. Mental Models I Find Repeatedly Useful
7. This Is The Most Difficult Skill For CEOs To Learn
8. PIP についてどう考えるかに関する優れた記事は こちらですが、私たちのタイムスケールはより短いです。
9. Impraise Blog: 1-on-1s for Engaged Employees
10. Mind Tools: Giving Feedback: Keeping Team Member Performance High, and Well Integrated
11. Remote.Co: 5 Tips for Providing Feedback to Remote Workers
12. リモートチームのフィードバックに関する Hanno の非常に興味深いブログ記事
13. 51 questions to ask in one-on-ones with a manager
14. HBR: The rise of data driven decision making is real but uneven
15. Forbes: 6 Tips for Making Better Decisions

書籍

このセクションの書籍は 経費精算できます。

E-Group オフサイトの書籍セレクションからの注目すべき書籍が、以下のリストに追加されることがあります。

私たちは、これらの書籍をグループで読み進めるために、ときどき 読書会を自主的に開催します。

1. High Output Management - Andrew Grove
   • トップ 10 の引用
   • 読書会
2. The Hard Thing About Hard Things: Building a Business When There Are No Easy Answers - Ben Horowitz
   • Chase Wright のノート
3. Crucial Conversations: Tools for Talking When Stakes Are High - Kerry Patterson
   • E-groupの読書からのノート:
   • バーチャルなチームは、同じ場所にいるチームよりも、Crucial Conversations で失敗する可能性がはるかに高い
   • 私たちは、潜在的な問題を明らかにするために、非同期の会話のトーンを感じ取るスキルを身につける必要がある
   • 私たちは、公式のチャンネルで人々に 心理的安全性を作り出す方法を見つける必要がある
   • 共感から始めることは、緊張した状況で必要なコンテキストを集める優れた方法である - これは非同期では難しいが、より重要である
   • 後で後悔するかもしれないコメントを Issue に投稿する前に、（Slack で）1-on-1 でコンテキストを得ることを検討する
   • リーダーとして、私たちもコンテキストを与える必要がある。良い問いは: 「X を優先順位付けしてもらうには、何が変わる必要があるか…」
   • 何かをドキュメント化することは、難しい会話をすることの代わりには ならない
   • 読書会
   • Crucial Conversations のハンドブックページ

メーリングリスト

1. Software Lead Weekly

トレーニング

リーダーシップのトレーニングを行う際は、プレゼンテーションを作成する代わりにハンドブックを画面共有してください。

リーダーシップ開発の機会

1. マネージャーは、オールリモートのチームを率いるためのマネジメントスキルの開発に焦点を当てた Elevate プログラムに参加できます。
2. 成長と能力開発の福利厚生を用いたリーダーシップ開発コーチング。正式な GitLab コーチングプログラムについての詳細は追って発表します。
3. 女性 TMRG のメンターシップグループに参加して、リーダーシップを実践するためのメンターになるか、リーダーと組んで学んでください。
4. Shadow プログラムに参加する機会を探ってください。
5. GitLab Learnで、IC からマネージャーへの移行を成功させるために必要なスキルを探ってください。
6. LinkedIn Learningでリーダーシップとマネジメントのコースを探ってください。
7. Learning and Development は FY23 にいくつかのプログラムを開発しており、Managing at GitLab Course、New Manager Bootcamp、LifeLabs Learning Pilot and Launch、コーチングプログラムなどが含まれます！

People Group

リーダーシップ開発のトピックについてさらなるサポートが必要な場合は、People Groupの誰にでも気軽に連絡してください。チームページで People Group のドロップダウンを使って私たちを見つけられます。チームには HelpLab 経由でも連絡できます。

上場企業であること

GitLab の 上場企業であることについての見解についてさらに詳しくご覧ください。

懸念の緩和

私たちは 懸念の緩和を文書化したページを持っています。私たちの バリューの多くは、これらの懸念の一部を緩和するのに役立ちます。

ページのソースコードを見る - ページの編集 - please contribute.