昇進と異動

社内でタレントを育成することは GitLab の成功の重要な要素であり、私たちの昇進と異動のプロセスは、私たちの価値観に沿った育成をサポートするために構築されています。チームメンバーは GitLab で キャリアアップを追求する 2 つの主な道があります: 1) 周期的な昇進キャリブレーションプロセスを通じて、2) 募集中のポジションに応募して面接を受ける。

私たちは、チームメンバーが自身のキャリアアップを自身でコントロールすることを奨励し、開発を所有する権限を与えています。チームメンバーは、別のまたはより大きな役割に成長することを考える際に、開発したいスキルを明確にしてマネージャーと整合するためのツールとして、個人成長計画を活用することを推奨されます。 このページでは、異動、昇進、再編成に関する情報を扱います。

定義

内部モビリティ

内部モビリティは、チームメンバーが GitLab の募集中のポジションに移動するプロセスです。ポジションが募集され、Greenhouse 経由でキャリアサイトに掲載され、現在の GitLab チームメンバーによって埋められた場合、それは「内部モビリティ」として分類されます。外部候補者で役割を埋めるのと同様に、内部チームメンバー候補者も同じ Greenhouse 採用ステップに従い、情報に基づいた採用決定を可能にするためフルの面接プロセスを経験します。すべての募集中のポジションは、検討の機会を平等にするために掲載されるべきです。

Greenhouse 採用プロセスに従って募集中の役割のオファーを受けた結果のアクションタイプは、レベルと職務範囲の変更に依存します:

• チームメンバーが同じグレードのポジションに応募して受け入れる場合、それはおそらくラテラル異動とみなされます。ほとんどの場合、新旧の職務ファミリー間で報酬構造に大きな違いがない限り、ラテラル異動は報酬の増加につながりません。チームメンバーが新しい役割に移動するとき、職務レベル、ファミリー、範囲のレビューによって、これが実際にラテラル移動であるかどうかが決定されます。
• チームメンバーがより高いグレードのポジションに応募して受け入れる場合、それはおそらく「昇進」とみなされ、報酬および/または昇進ストック付与の変更につながります。一部の職務ファミリーは職務グレーディングが異なり、チームメンバーが新しい職務ファミリーに移動するとき、レベルと職務範囲のレビューによって、これが実際に昇進であるかどうかが決定されます。
• チームメンバーがより低いグレードのポジションに応募して受け入れる場合、それはおそらく「降格」とみなされ、報酬の変更につながる場合とつながらない場合があります。一部の職務ファミリーは職務グレーディングが異なり、チームメンバーが新しい職務ファミリーに移動するとき、レベルと職務範囲のレビューによって、これが実際に降格であるかどうかが決定されます。

新しい役割に応募する際、チームメンバーは現在の職務レベルとファミリーに基づく変更の影響を理解することが推奨されます。

注: チームメンバーが個人コントリビューターから管理職に移動したい場合、すべての興味のある候補者が応募する機会を持てるよう、ポジションを掲載し、通常の採用プロセスのステップに従う必要があります。これにより、全員に公平で透明なプロセスが提供されます。

内部モビリティの機会は、従業員適格性と利用可能な募集中のヘッドカウントに依存します。

• タイムライン
  • 募集中の要請と Greenhouse 経由の内部採用プロセスに基づきます。
  • すべてのポジションは最低 5 暦日間オープンである必要があります。
  • 内部または外部候補者にオファーを出す前に、少なくとも 2 回の面接を完了する必要があります。
  • 報酬の変更がある場合、開始日はチームメンバーの国に沿った給与期間の開始に当たる必要があります。チームがコミッション役割の場合、開始日は常に月の 1 日に整合する必要があります。

ビジネス要件や再編成による職務詳細の変更

時には、ビジネスが直接マネージャーや部門などの職務属性を変更する必要があります。これらの変更は、チームの統合、新しい部門の作成、またはチームメンバーを新しいマネージャーの下に異動させた結果である可能性があります。これらのタイプの変更は職務属性の変更として指定され、内部モビリティの定義を満たさず、現在のマネージャーが Workday 経由で開始できます。

エンジニアリング内部モビリティ

エンジニアリングについては、追加のガイドラインと正当性についてはエンジニアリングモビリティ原則を参照してください。

昇進

昇進はチームメンバーのキャリアの旅における最も意味のある瞬間の 1 つを表します。彼らの成長、貢献、可能性の認識です。マネージャーにとって、これらの会話はリーダーとして持つ最もインパクトのある会話の 1 つであり、成果を祝い、継続的な卓越性を鼓舞する機会を提供します。 昇進サイクルは、個人の願望と組織のニーズの両方を尊重する、公正で透明なプロセスを作成するように設計されています。次のレベルへの準備状況を示す準備をしているチームメンバーであっても、この重要な瞬間を通じて誰かを導くマネージャーであっても、あなたの参加はキャリアだけでなく、成長と認識の文化を形作ります。

このプロセス全体を通じて、昇進は単なる肩書きや報酬以上のものであることを覚えておいてください。これは可能性を認識し、成長を祝い、GitLab の未来に投資することについてです。結果が昇進であっても、次のサイクルへの育成フィードバックであっても、すべての会話は関係を強化し、継続的な卓越性を鼓舞する機会です。

昇進サイクル全体を通しての質問やサポートについては、People Business Partner (PBP) またはタレントマネジメント&開発チームに連絡してください。

昇進のタイプ

サイクル内昇進: サイクル内昇進は、同じ職務ファミリー内にいて、同様だが拡大した職務範囲を持つ個人のことです。職務ファミリーの違いにより、昇進は必ずしも新しいグレードで定義されるわけではありません。同じ職務ファミリー内の次のレベルポジションに昇進する前に、チームメンバーが少なくとも 12 か月そのポジションに就いていることを通常期待します。このプロセスは面接を必要とせず、補充ヘッドカウントを作成せず、キャリブレーションされた昇進プロセスを通じて半期ごとに、またはセールス開発職務ファミリーのレベル 5 チームメンバーには月次で発生します。すべてのサイクル内昇進は Workday で処理され、Greenhouse では処理されません。

内部モビリティ昇進: 内部モビリティ昇進は、チームメンバーが現在の役割と比較して高いグレード/職務責任のポジションに応募してそれを受け入れたときに発生します。

• 内部モビリティを通じた昇進が発生するためには、スキップレベルリーダーからの承認が必要です。
• さらに、整合性と可視性のために、整合するPeople Business Partnerにも相談する必要があります。

昇進の哲学

私たちの昇進哲学は、伝統的な「はしごを登る」考え方を超えています。私たちは、成長は複数の次元 (垂直方向 (レベルを上がる) と横方向 (スキルと影響を広げる)) で起こることを認識しており、開発と成功への多様な道を提供するキャリアの「ラティス (格子)」を作り出しています。

私たちの昇進哲学は、私たちの価値観に沿ったアプローチとプロセスを取り巻くコアな柱で構成されています。

柱

• パフォーマンスファースト: 昇進は、可能性だけでなく、現在のパフォーマンスを反映します。インライン昇進の場合、昇進する前に、次の職務フレームワークで説明されているレベルで一貫して動作している必要があります。職務ファミリー内の次のレベルへの昇進の対象となるのは通常、現在の役割に就いてから 12 か月後ですが、スキルを横方向に広げることは成長の旅に同様に価値があることを覚えておいてください。
• 成長パートナーシップ: あなたのキャリア開発は、あなたとあなたのマネージャーの間の共同努力です。私たちは、はしごを上がること、ラティスを横切って広げること、いずれにしても、願望に関する定期的な会話を奨励します。マネージャーは、現在の領域での専門知識を深めるか、補完的なスキルと経験を開発するために分岐するかにかかわらず、目標に整合する機会を特定するのを助けるためにそこにいます。
• 包括的な評価: 昇進を考慮する際、私たちは準備状況とビジネス機会の両方を考慮します。私たちは、より広い責任を引き受け、垂直方向に登るだけでなく、影響を水平方向に広げるチームメンバーを評価します。
• 透明なプロセス: GitLab のすべてのインライン昇進には昇進ドキュメントが必要です。この透明性により、垂直方向の進行であれ、重要な横方向の成長と能力の拡大の認識であれ、誰もが昇進の根拠を理解できます。
• セルフオーナーシップ: 効率の価値観に従って manager of one であり、マネージャーとパートナーシップを組んで昇進ドキュメントの所有権を持つことを奨励します。これは、垂直方向の昇進を求めているか、スキルと影響を広げることへの認識を求めているかに関わらず適用されます。
• 公平なキャリブレーション: 公正で一貫したレビューを確保するために、計画された昇進を年 2 回キャリブレーションします。このプロセスを通じて、垂直方向と横方向の両方で、私たちの昇進が組織全体で健全で公平な割合で発生しているかどうかを理解するために指標を追跡します。

ラティス (横方向の拡大) とラダー (垂直方向の成長) の両方を昇進哲学に組み込むことで、GitLab で成長し貢献できる多様な方法を認識する多様なキャリアパスを実現するスペースを作り出します。

価値観との整合性

私たちの昇進哲学は、私たちの価値観とも整合しています:

• コラボレーション: フィードバックとキャリブレーションのためのクロスファンクショナルなレンズ
• 結果: ビジネス上の正当化、範囲、チームメンバーの結果が示され、昇進をサポートするために文書化されます
• 効率: 年 2 回の計画とキャリブレーションによる、昇進プロセスにおける一貫性とスケーラビリティ。計画とキャリブレーションのタイミングは、ビジネスの既存のプログラムとサイクルを考慮し、効率のために最も整合する頻度に昇進を埋め込むことを目指します。
• 多様性、インクルージョン、ビロンギング: 組織のすべてのレベルでの昇進への一貫したアプローチと文書化を通じて反映される公平性と公平性、そして私たちの職務フレームワークと Total Rewards URG 監査によってサポートされる
• イテレーション: プロセスは各サイクルで改善されます。FY24 では年 2 回に移行しました。私たちは引き続き、効率とスケーラビリティのためにプロセスをイテレートする方法を検討しています。
• 透明性: 昇進指標、予算、ガイドラインの明確さと有効性に加え、社内公開昇進ドキュメントを通じた昇進の正当性の透明性。

昇進の処理

ほとんどの昇進は年 2 回の昇進キャリブレーションを通じて処理され、個人が面接を受け承認されたヘッドカウントを埋めるポジションを受け入れたかどうかに応じて、例外は Greenhouse または Workday を経由します。これら 3 つの昇進処理方法の詳細は以下にあります。

年 2 回の昇進キャリブレーションプロセスとタイムライン

GitLab では年 2 回の頻度で昇進を行います。昇進プロセスには 3 つのコアステージがあります: 計画、キャリブレーション、処理。

セールス開発組織は、職務ファミリー構造内の各レベルの特定の昇進基準により、サイクル内昇進を月次でレビューします。計画、キャリブレーション、処理ステップは以下の詳細に整合しています。

セールス開発プロセス

セールス開発の昇進は月次でレビューされます。

• 計画とキャリブレーション: 各月の第 3 週まで
• 処理: 各発効月の 5 日までに昇進を HRIS に追加する必要があります
• 昇進の発効日: 20XX-11-01、20XX-12-01、20XX-01-01

エンジニアリング昇進計画

今後の昇進への洞察、必要なサポートの特定、成長軌道への可視性の向上のため、エンジニアリングは昇進トラッカーを保持しています。マネージャーは、チームメンバーの昇進準備状況を特定するときに、会計年度を通じてこのフォームを記入することが求められます。

回答は、エンジニアリングリーダーシップチーム (CTO 直属の部下) とエンジニアリングPeople Business Partnerにのみ表示されます。

半年に 1 回のプロセス

以下は FY27 のタイムラインです: Senior Director+ 昇進のキャリブレーションタイムラインは、Senior Director+ 昇進が E-group オフサイトで年 2 回キャリブレーションされるため、上記のタイムラインと若干異なることに注意してください。

FY27-Q2 (5 月 1 日)

以下は FY26-Q2 昇進サイクルのタイムラインです:

昇進指名の準備と提出

• 1 月 12-30 日: マネージャーとチームメンバーが会って昇進準備状況について議論します。ビジネスニーズと個人の準備状況に整合がある場合、1 月 30 日までにマネージャー提出用に昇進ドキュメントフォームを準備するために協働します
• 1 月 30 日: 締切 - すべてのマネージャー昇進指名は Workday で提出される必要があります
• 2 月 2-27 日: 昇進キャリブレーションセッションと昇進承認

報酬 / ACR 計画 (暫定スケジュール)

• 3 月 23 日週: ACR がプランナーに公開されます (Workday でプロセスを開く前に昇進承認が必要)
• 3 月 23 日 - 4 月 3 日: プランナーはグリッドに報酬額を入力します
• 4 月 9-13 日: eGroup / PBP comp 承認
• 4 月 21 日: Workday でステートメント生成
• 4 月 21-30 日: チームメンバーコミュニケーションウィンドウ
• 5 月 1 日: 昇進が発効！

*注: すべての日付は軽微な調整の対象となります。変更は事前にコミュニケーションされます。

FY27-Q4 (11 月 1 日)

ステータス: 日付は未定で投稿予定です。後で確認してください！

計画

FY26 Q4 昇進計画は、機密性を維持し、必要に応じて部門リーダー間のコラボレーションを可能にするために、Workday 経由で完了します。上記のタイムラインの計画フェーズに入る前に、People Business Partnerは、キャリブレーションフェーズに入る前に Workday が最新であることを確認します。

部門ごとのキャリブレーションフェーズが完了すると、ディレクター以上は、Workday 計画グリッドに昇進報酬の推奨を入力できるようになります。部門のキャリブレーションミーティングタイムラインの詳細については、People Business Partnerに連絡してください。

昇進ドキュメント

昇進ドキュメントはすべてのインライン昇進に必要です。昇進ドキュメントは合計 3 ページを超えてはなりません。

対象は他の GitLab チームメンバーであるため、テキストは三人称でチームメンバーの名前と適切な代名詞 (he/she/they) を使い、役割への適性の証拠として仕事とスキルを強調するように書く必要があります。説得力のあるドキュメントの作成を支援するために、スタイルガイドが利用可能です。ビジネス結果ごとに関連するセクションを捉えるためにブレットフォーマットを活用するか、短い段落を使用できます。

インライン昇進ドキュメントは、価値観の整合性、役割のビジネスニーズ、影響力のあるビジネス結果の提供を通じてチームメンバーの準備状況を示す必要があります。私たちの昇進ドキュメントのコアセクションは、昇進サマリー、ビジネス結果/影響、価値観の整合性、ビジネス上の正当化です。

昇進サマリー

このセクションは、チームメンバーが次のレベルでパフォーマンスする能力を持っていることを示す成果のハイレベルなサマリー (3〜5 文) です。

ビジネス結果

最も重要な価値観として、結果は私たちが行うすべてのことの中心にあります。

職務フレームワークにおける価値観と期待に沿った次のレベルでチームメンバーのパフォーマンスを示す、最もインパクトのある 3 つの結果 (達成、イニシアチブ、またはプロジェクト) をリストアップしてください。

GitLab / ビジネス結果に対するプロジェクトのインパクト

プロジェクト/達成のインパクト

• 例: Org Design Playbook の作成は、会社全体のあらゆる組織変更に対する反復可能なプロセスを概説します。リーダーとPeople Business Partnerが活用して変化を実行しリードできる、コラボレーティブで、チームメンバー指向、コミュニケーション中心、結果駆動型のフォーマットを作成します。これは、変化管理、実行、ステークホルダーの整合性のための重要なリソースとして、ハイパフォーマンスカルチャーの構築に直接結びついています。

ビジネス結果

• 例: Org Design Playbook の導入以来、実行する変更の成功を測定できるスコアリングシステムも実装しました。Playbook の作成以来、全体的な平均スコアの増加が見られます。

ビジネスの関連性とは、プロジェクト/達成が会社にとってなぜ重要であるか (たとえば OKR に関連しているか、重要な投資テーマに関連しているか、など) を指します。

• 例: FY25 Yearlies の 1 つは、ハイパフォーマンスカルチャーの推進に関連しています。ハイパフォーマンスカルチャーの重要な側面は、効率的で結果指向の方法で変化を管理する能力です。組織設計の変化と再編成は、私たちが効率的、徹底的、チームメンバー指向の実行アプローチに整合していない場合、チームメンバーの結果を出すスピードに悪影響を与える可能性があります。

チームメンバーの直接的な貢献

• 例: Tanuki はグローバルなクロスファンクショナルチームの DRI であり、プロジェクトのすべての変更管理コミュニケーションを確立しました。

チームメンバーがこの達成での仕事で CREDIT 価値観をどのように示したか。

• 例: Tanuki は、この結果を提供する際にイテレーションの価値観を示しました。彼らは機能チームのサブセットを駆動して納品タイムラインにコミットさせ、製品ローンチの GTM 動作を可能にしながら、他のチームに反復的に納品する柔軟性を与えました。

私たちがビジネス結果に上記の構造を一貫して従うようお願いするのは、以下を確保するためです:

1. インパクトを強調する: 達成をビジネス目標に直接結び付け、プロジェクトでのインパクトと役割を次のレベルのパフォーマンス期待に結び付けます。
2. クロスファンクショナルに理解可能: ストーリーテリング構造により、チームメンバーが何をしたか、なぜ重要か、ビジネスにどのようなインパクトを与えたかを、より多くのクロスファンクショナルな理解が促進されます。
3. 客観性を追加する: 貢献、インパクト、関連性に一貫したフォーマットで焦点を当てることで客観性を追加し、無意識のバイアスの機会を減らします。

ビジネス上の正当化

GitLab は、昇進について考えるときに、個人の準備状況とビジネスニーズの両方を考慮します。マネージャーは、より高いレベルで完了させる必要があるチームメンバーのスキルと仕事を正当化する内容を含めて、昇進ドキュメントのビジネス上の正当化セクションを完了する責任があります。可能なビジネス上の正当化には、通常、より複雑なプロジェクト、チームがスケールするにつれて必要となる追加の作業範囲、および/または XYZ ビジネス理由による追加の責任が含まれます。

価値観の整合性

価値観は、GitLab で私たちが行うすべてのことの中心にあります。チームメンバーの成果とイニシアチブを、それらがサポートする価値観に結び付けることは不可欠です。すべての価値観は、昇進ドキュメントで少なくとも 1 回、昇進候補者がビジネス結果への貢献が価値観にどのように整合しているかの例とともに参照されるべきです。ビジネス結果セクションで参照されなかった価値観については、チームメンバーが CREDIT をどのように示したかをさらに強調する 1〜2 文の例を提供してください。

• 各職務レベルに整合する DIB 行動に関するガイダンスをレビューしてください。これは、私たちの多様性インクルージョン&ビロンギング価値観を示す方法の例を提供します

追加のヒント

昇進ドキュメントを作成するとき、以下を覚えておいてください:

• 昇進は成長の可能性ではなく、パフォーマンスに基づきます。
• 昇進ドキュメントは合計 3 ページを超えてはなりません。
• GitLab のさまざまなレベルでの期待に関するガイダンスについては、ハンドブックの職務フレームワークを参照してください。職務レベルは、昇進ドキュメントに含めるために選択したデータをガイドするのに役立つはずです。さらに、キャリブレーションセッションでの議論にも役立ちます。
• レビューと承認プロセスが遅延しないように、昇進ドキュメントが ‘GitLab’ に対して “comment” アクセスが有効になっていることを必ず確認してください。昇進を提出する前に、以下の昇進ドキュメントの各セクションに関連する指示を削除してください。
• 達成を明確に表現するのに苦労している場合は、マネージャーがサポートしフィードバックを提供できます。フィードバックを得るためにステークホルダーに連絡したり、信頼できる同僚やメンターと会ってブレインストーミングしたりすることも検討できます。
• これらは機密で、昇進キャリブレーション、タレントアセスメントキャリブレーション、レポート構造内などの機密設定でのみ議論される必要があるため、“Exceeding Performance” などのタレントアセスメント評価を含めるべきではありません。

キャリブレーション

各四半期、部門/部署リーダーシップと整合するPeople Business Partnerは、予測される昇進をレビューするキャリブレーションセッションを計画します。これらのキャリブレーションセッションの目標は、部門での昇進に対して公正で一貫した基準を設定し、ピアレビューを可能にし、質問する機会を提供することです。これらのセッションは非同期または同期で行うことができます。

キャリブレーションセッション中、リーダーは以下を議論する準備をする必要があります:

1. 昇進ドキュメントのコアテーマ: 価値観の整合性、ビジネス上の正当化、ビジネス結果。
2. 育成領域: 昇進ドキュメントは強みを概説しますが、チームメンバーが次のレベルで開発する機会をどのようにサポートするかも強調したいと考えています。
3. クロスファンクショナルなフィードバック: 私たちのビジネス目標とイニシアチブがますますクロスファンクショナルになるにつれて、マネージャーはチームメンバーが直近のチーム内、およびコアなクロスファンクショナルパートナーとステークホルダーと効果的に協働する方法を把握する必要があります。
4. 職務フレームワークに整合した現在および (一部) 次のレベルの期待に対するパフォーマンス。
5. コンピテンシー: 利用可能で該当する場合。
6. 最新のタレントアセスメント (および以来の関連する変更)。

キャリブレーションは、以下のレベルのリーダーとピープルマネージャーに整合する必要があります:

サイズ/範囲などによって、キャリブレーション構造は部署と部門で異なる場合があります。

Senior Director+ への昇進

哲学的には、GitLab のすべての昇進は同じように取り組まれ、同じハイレベルプロセス (計画、キャリブレーション、処理) に従い、同じ昇進ドキュメントテンプレートを使用します。

Senior Director+ レベルへの昇進には、以下の違いがあります:

1. 計画: Senior Director+ 昇進は、可視性のために、希望する昇進四半期の少なくとも 2 四半期前に E-group の昇進プロジェクトシートに追加する必要があります。たとえば、Q1 (2 月) 発効で個人を昇進させたい場合、Q3 (10 月最遅) 中にこのチームメンバーを E-group の予測シートに追加してもらう必要があります。整合するPeople Business Partnerと協働し、昇進予測が追加されることを確認してください。
2. レベルスコーピング: 組織設計の原則とシニアリーダーシップ役割の期待において、厳格さと一貫性を確保したいと考えています。Senior Director+ 昇進の場合、ビジネスニーズと職務フレームワークへの整合性のために役割を評価するために (チームメンバーではなく)、スコーピングツールを使用します。
3. クロスファンクショナルフィードバック: Senior Director+ 昇進をレビューする際、少なくとも 3 つのクロスファンクショナルフィードバックの例が必要です。このフィードバックは公開されず、キャリブレーション委員会、PBP、直接マネージャー、チームメンバーによってのみレビューされます。

• 昇進ドキュメントで強調された 3 つのビジネス結果はすべて、少なくとも 1 人のクロスファンクショナルなチームメンバーからフィードバックが提供される必要があります。
• フィードバック提供者は、昇進ドキュメントで強調されたビジネス結果の 1 つ以上にプロジェクトチームメンバー、DRI、またはステークホルダーとして取り組んだ直接的な経験を持つ必要があります。
• フィードバック提供者は、マネージャーと同じレポートラインにいない (つまり、チームメンバーのマネージャー、スキップレベルなどではない)。
• フィードバック提供者はクロスファンクショナルである必要があります。フィードバックを提供する最も適切なチームメンバーを決定する際、コアな焦点は、昇進ドキュメントで強調されたビジネス結果について、昇進候補者と最も密接に協働した人にあるべきです。
• フィードバック提供者は、ターゲットの昇進レベル以上である必要があります。フィードバック提供者は、ターゲットの昇進レベル以上の個人コントリビューターまたはピープルマネージャーである可能性があります。フィードバック提供者にターゲットの昇進レベル以上を要求する理由は、すでに次のレベルで動作しているチームメンバーとして、次のレベルの期待のコンテキストで、ビジネス結果とコラボレーションについて話す能力があることを確認するためです。
• フィードバックは、昇進ドキュメントとは別に、このテンプレートで取得され、キャリブレーション議論の一部としてレビューされます。フィードバックは要約され、フィードバック提供者の具体的な名前を提供する必要はありません。

フィードバック質問ガイダンス:

1. X の Y ビジネス結果の提供、およびあなた/あなたのチームとのコラボレーションについてフィードバックを提供してください。

2. 特に、職務フレームワーク、CREDIT 価値観、HPT 柱に対するパフォーマンスを強調してください

3. キャリブレーション: すべての Senior Director レベル昇進は、部門レベルではなく部署 VP+ リーダーシップレベルでキャリブレーションされます。Vice President レベル昇進は E-group でキャリブレーションされます。キャリブレーションタイムラインは E-group オフサイトまたは拡張月次ミーティングのタイミングに整合し、組織の残りのキャリブレーションタイムラインとは異なります。すべての昇進ドキュメント、フィードバックサマリー、スコーピングツールは、オフサイト日の少なくとも 2 週間前に完了し、可視性と準備のために E-group と共有される必要があります。

このプロセスへの唯一の例外は、内部チームメンバーが面接を受けてオファーを受ける、Director またはそれ以上のレベルの役割のオープンな予算化された公に広告されたポジションがある場合です。外部候補者が検討され面接された場合で、内部候補者が標準採用プロセス (スクリーニング、フルインタビュープロセス) を通じて役割を獲得した場合、リクルーターはオファーが承認されたらすぐに候補者にオファーを出せます。内部および外部候補者間で募集中の役割のオファーを出して受け入れるタイミングまたはプロセスに違いはありません。

昇進指標

GitLab は Tableau で以下の昇進指標を追跡します

内部モビリティ

GitLab は内部モビリティ率を追跡します。市場データは、会社全体での昇進の平均として確認すべきガイドラインとして、15% のローリング昇進率を示しています。これはガイドラインであり、上限ではありません。

平均 % 報酬変更

GitLab は、昇進に対して一般に5〜10% の報酬変更の平均をターゲットとしています。この指標は、競争力があり意味のある昇進増加を確保しつつ、会社全体で昇進報酬の引き上げをチームメンバーに割り当てる際に一貫性と公平性を確保するために設けられています。

予算インパクト (以下を参照)

FP&A は年 2 回、部門/部署ごとに予算への影響を追跡します。

昇進予算

昇進予算は部署リーダーレベルで保持され、Workday での計画のためにディレクター以上のレベルに縮小されます。

Compensation Program Budget をレビューして、昇進予算がどのように割り当てられるか、四半期中に部署/部門が予算オーバー/アンダーの場合の潜在的なトレードオフをレビューするプロセスを理解してください。

年 2 回の昇進キャリブレーションプロセス外で処理される昇進

特定のタイプの昇進は、年 2 回の昇進キャリブレーションプロセス外で処理できます:

1. Greenhouse で新しい、承認されたヘッドカウントへの応募:
   • 内部候補者は、Greenhouse 昇進/異動セクションでさらに定義されている面接プロセスを経ます。
2. 暫定/代理役割の個人からの昇進。
3. 年 2 回のプロセス外で、上記のタイプのいずれにも整合しない例外。

例外の処理方法: Workday でのサイクル外昇進リクエストの提出

年 2 回の昇進キャリブレーションプロセスや Greenhouse での募集中の要請を通じて処理されない、昇進が発生した例外的な状況については、マネージャーはPeople Business Partnerと協働して Workday 経由で昇進を提出できます。マネージャーは PBP にメールで連絡し、昇進ドキュメント、例外の正当化、10% を超える報酬増加の推奨に対する次のレベルマネージャーの承認を含める必要があります。People Business Partnerが例外を承認したら、昇進を処理でき、People Business Partnerが Workday で昇進を提出できます。変更の提出に関するヘルプは Workday ガイドを参照してください。

例外の承認

Director+ レベルのサイクル外昇進例外の承認には E-Group の承認が必要で、Director 未満のレベルのサイクル外昇進は部門長を通じての承認が必要です。

昇進レベルに関わらず、リーダーは、昇進に資金を提供するためにレビューできるトレードオフを特定するために、People Business Partner、Total Rewards、FP&A と概説どおりに協働することが重要です。

FY25 CTO 組織昇進ガイダンス

必要なドキュメント

CTO 組織では、会社のプロセスに従い、標準昇進ドキュメントを使用します。シニアリティに関係なく、すべての役割についてビジネス上の正当化を記入することを要求します。この会計年度で昇進を検討する際に、マネージャーが集中することを望む具体的なガイダンスがあります。以下を参照してください。FY25 Q3 昇進から、ピアフィードバックは昇進検討には不要であることに注意してください。この要素は将来再評価する可能性があります。

FY25-Q3 の CTO タイムライン

• 2024-06-10 から 2024-06-21: 昇進指名者の直接マネージャーが、個人の準備状況についてピア、ステークホルダー、その他のチームメンバーと話し合った後、昇進ドキュメントを完成させます。完成したドキュメントは 2024-06-21 (太平洋時間営業終了) までに Kristina Bullock と Jess Durbin に共有されます。
  • 注: 直接マネージャーは 2024-06-10 より前から昇進ドキュメントの作業を開始できます。これは会社全体の計画期間の開始です。
• 2024-06-24 から 2024-07-10: 部門レベルキャリブレーション (PBP が促進) に続き CTO リーダーキャリブレーション。
• 2024-07-16 から 2024-08-01: 承認された昇進が Workday に入力され、Comp レビューが完了し、最終承認が取得されます。
• 2024-08-01: 昇進が Workday で発効。

マネージャーへのコンテキスト設定

リーダーとして、チームメンバーの昇進が承認された場合、個人との期待をリセットする必要があり、チームのシニアリティの成長に合わせて変更を加える必要があるでしょう。根拠を記述する前に、これらの変更が何を伴うかを考えることが、最良のビジネス上の正当化を準備するのに役立ちます。肯定的な結果は、個人の期待だけでなく、現在および将来のマネージャーが仕事をどのようにすべきかの期待も変えます。

FY25 昇進のガイディング質問

チームメンバーの現在の責任と昇進後の将来の期待を確認するために、GitLab 職務フレームワーク、エンジニアリング IC キャリアマトリックス、エンジニアリングリーダーシップ職務ファミリーを参照してください。

1. 昇進が承認された場合、このチームメンバーの役割はどのように変わるでしょうか？増加した責任のスペースを作るために、何をやめるでしょうか？昇進のレベルに応じて、これらがビジネス上の正当化に含まれ、これらの決定がチーム、ステージ、会社に利益となることが期待されます。

   1. 例: Tanuki はシニアエンジニアになる準備ができています。これは、本番に投入される前にリグレッションを特定するテレメトリと品質指標を追加するための評価フレームワークを開発することで自身の仕事を合理化したという事実によって示されます。これにより仕事の質が向上し、シニアエンジニアとして、本番にプッシュする前にチームのすべての機能に対して適切な品質バーを設定することを確実にするためにチームの残りをリードします。シニアエンジニアとして、チーム全体で働き続け、この新しい評価フレームワークをチームの働き方に組み込みます。複数のチームにこれを拡大する機会がありますが、それは継続的な成長のための彼女の開発計画の一部となります。

2. 昇進が承認された場合、チームメンバーはどのように異なる方法で働くでしょうか？

   1. 例: Tanuki は現在 Quad から作業項目を受け取っていますが、新しい役割では、Tanuki はクロスファンクショナルに働き、優先順位を付けて計画されたマイルストーンに組み込まれるべき潜在的な作業を特定することが期待されます。Tanuki は、適切に優先順位付けされるべき作業の課題と根拠を提示でき、GitLab がこの新しい仕事の利益を実現できるよう迅速に実行できます。

3. このチームメンバーがより高いレベルの役割にいる場合、チームがどのように異なる機能を発揮するかを検討しましたか？

   1. 追加の詳細: すべての昇進は、特定のチームおよび/またはプロジェクトのコストと期待を増加させます。あなたとその人は、この人/チーム/プロジェクトへの会社の増加した投資のリターンをどのように確保しますか？肯定的な結果で発生するコミットメントと変更を詳細に説明することは、この昇進がすべての関係者にとってより良い結果をもたらすという信頼を意思決定者に与えるのに役立ちます。

4. 現在のチームの状態で「X」レベル (つまりシニアエンジニア) のチームメンバーがこれだけ必要ですか？そのレベルで行うべき作業が十分にありますか？

セキュリティ昇進プロセス

フィードバックを与え、受け取ることは、ハイパフォーマンスチームを構築する上で重要な部分です。達成された主要なビジネス結果に関するチームメンバーからのフィードバックは、チームメンバーの昇進準備状況を評価する際の重要なデータポイントです。セキュリティ部署内でフィードバック文化を引き続き育成し、ビジネス結果を通じてコラボレーションの有効性をキャリブレーションするための取り組みとして、FY25 Q3 から部署の昇進プロセスに正式なフィードバックタッチポイントを組み込みました。フィードバックは単独でチームメンバーが昇進する準備ができているかを決定するわけではなく、昇進計画とキャリブレーションプロセス全体を通じて考慮すべきデータポイントであることに注意してください。

以下のステップは、昇進候補者が私たちの年 2 回の昇進プロセスの一部としてフィードバックを依頼するために従うべきプロセス、主要な期日、および両方の昇進候補者とフィードバック提供者がレビューすべき有用なリソースを概説しています。

注: FY27 Q1 サイクルでは、効率のためにタレントアセスメントキャリブレーションを昇進キャリブレーションと組み合わせます。部門長は、CISO Directs キャリブレーションセッションに先立って、部門レベルでタレントアセスメントキャリブレーションが完了し、昇進ドキュメントとフィードバックドキュメントが分析および準備されている必要があります。

1. チームメンバーが昇進準備状況と候補性についてマネージャーと整合する
   • フィードバックを依頼する前に、チームメンバーはマネージャーと昇進準備状況についての会話を持つ必要があります。次回の昇進サイクルに対するマネージャーとチームメンバーの両方による準備状況に整合がある場合、チームメンバーは「昇進候補者」として認定されます。マネージャーは、プロセスをキックオフする前に、リーダーシップチェーン内の CISO direct もまた、昇進候補性を認識しサポートしていることを確認する必要があります。これはまた、早期のフィードバックのためのスペースを作ります。
   • 期日: 2026-01-09
2. チームメンバーは昇進ドキュメントを完了する
   • 昇進ドキュメントの完了は、マネージャーのサポート、レビュー、フィードバックを伴ってチームメンバー主導で行われる必要があります。フィードバックを依頼する前に、フィードバックを提供する基本として機能するため、昇進ドキュメントは完成している必要があります。チームメンバーは、フィードバックを依頼する前に、マネージャーが昇進ドキュメントをレビューし、内容に整合していることを確認する必要があります。
   • 期日: 2026-01-16
3. チームメンバーはフィードバックフォームテンプレートのコピーを作成する
   • この Google フォーム は、セキュリティ部署全体での昇進フィードバック収集のフォーマットと質問の一貫性を確保し、より一貫性のある公平なキャリブレーションプロセスを促進するテンプレートを提供します。このプロセスは、フィードバックが次のレベルのパフォーマンスを示す主要な成果物に一貫して結びつくよう、昇進ドキュメントのビジネス結果セクションに関連するフィードバックに特に焦点を当てています。
   • 各昇進候補者は、それぞれのフィードバック提供者からフィードバックを収集するために使用するために、このフォームのコピーを作成する必要があります。
4. チームメンバーはフィードバックリクエストのステークホルダーを特定する
   • チームメンバーは理想的には、昇進ドキュメントで強調された 3 つのビジネス結果全体でフィードバックを提供する 3〜4 人の異なるチームメンバーを選択する必要がありますが、フィードバックを提供する少なくとも 2 人の異なるチームメンバーを選択する必要があります。昇進ドキュメントで強調された 3 つのビジネス結果はすべて、少なくとも 1 人のフィードバック提供者からフィードバックを提供される必要があります。チームメンバーは、フィードバックフォームを送信する前に、整合を確保するためにマネージャーに提案されたフィードバック提供者をレビューしてもらう必要があります。
   • フィードバック提供者の要件:
     • フィードバック提供者は、昇進ドキュメントで強調されたビジネス結果の 1 つ以上に、プロジェクトチームメンバー、DRI、またはステークホルダーとして取り組んだ直接的な経験を持つ必要があります。
     • フィードバック提供者は、マネージャーと同じレポートラインにいない (つまり、チームメンバーのマネージャー、スキップレベルなどではない)。
     • フィードバック提供者は、クロスファンクショナルまたは部署内のいずれかであり、両方の組み合わせが好まれ推奨されます。フィードバックを提供する最も適切なチームメンバーを考える際のコアな焦点は、昇進ドキュメントで強調されたビジネス結果について、昇進候補者と最も密接に協働した人を反映することです。注: クロスファンクショナルフィードバックは、キャリブレーションの目的でセキュリティ部署外からのフィードバックとして定義されます。クロスファンクショナルフィードバックは Staff+ 昇進に必要です。このルールへの例外は、キャリブレーションで CISO direct によって正当化され説明される必要があります。
     • フィードバック提供者は、ターゲットの昇進レベル以上である必要があります (つまり、セキュリティエンジニアがシニアセキュリティエンジニアの昇進をターゲットにしている場合、フィードバック提供者のレベルはシニアセキュリティエンジニア以上である必要があります)。フィードバック提供者は、ターゲットの昇進レベル以上の個人コントリビューターまたはピープルマネージャーである可能性があります。フィードバック提供者にターゲットの昇進レベル以上を要求する理由は、すでに次のレベルで動作しているチームメンバーとして、次のレベルの期待のコンテキストで、ビジネス結果とコラボレーションについて話す能力があることを確認するためです。
   • ピープルマネジメントと個人コントリビューターの対応する職務レベルの復習として、職務レベルを、会社全体のレベルごとの主要な違いの概要としてGitLab 職務フレームワークを、レベルごとの期待におけるセキュリティ固有の違いに関するリソースとして職務記述ライブラリを参照できます。
   • フィードバック提供者を選択するためのこれらの要件を満たすためにサポートが必要な場合は、マネージャーに相談してサポートを得てください。
   • 期日: 2026-01-21
5. チームメンバーはフィードバックフォームのコピーをフィードバック提供者に送信する
   • これは、ステップ 3 で昇進候補者がコピーを作成したフォームを参照します。
   • チームメンバーは、フィードバックリクエストに含めると役立つ場合、これを構造として活用できます: Hi [team member name], I am currently under consideration for a promotion to [next level job title]. I would really appreciate your feedback on our work together, specifically on results and our collaboration related to [name business result]. Please complete this feedback form by [insert due date]. You can read more about the feedback process [link this handbook section].
   • フィードバックを依頼する昇進候補者と、フィードバックを提供するチームメンバーの両方について、プロセスがキックオフされる前にフィードバックに関するガイダンスをレビューすることをお勧めします。S-B-I モデルは、フィードバックが明確で消化しやすい方法で構造化されるのを確保する役立つフレームワークになります。 フィードバックは 2026-01-21 から 2026-02-04 まで継続されます。チームメンバーが 2026-01-21 より前にフィードバックフォームをステークホルダーに送信する準備ができている場合は、そうすることができます。すべてのフィードバックは 2026-02-04 までに取得される必要があります。
     
   • 注: 会社全体のタイムラインに整合して、すべての昇進指名は 2026-01-30 までに Workday で提出される必要があります。フィードバックプロセスがまだ進行中であっても、このウィンドウ中にチームの昇進指名を提出してください。昇進指名は単なる指名であり、キャリブレーションと処理後まで完全に承認されません。
6. チームメンバーとマネージャーがフィードバックを分析する
   • チームメンバーはマネージャーと取得したフィードバックを共有し、テーマとトレンドについて議論し分析します
   • チームメンバーとマネージャーは CISO direct と共有するためのテーマをまとめます。一貫性を確保するためにテーマのコンパイルと分析にはこのテンプレートを活用します。分析は、Google フォームで提供された主要なテーマとフィードバックに焦点を当てる必要があります。
   • CISO direct は、CISO directs キャリブレーションセッションでフィードバックを表現できることを確実にするためにレビュー、フィードバック提供、明確化質問をする機会を持ちます。
   • 期日: 2026-02-10
7. CISO direct がキャリブレーションスプレッドシートにフィードバックサマリーを追加する
   • CISO direct は、キャリブレーションセッションに先立って可視性を確保するため、ステップ 6 でコンパイルされた昇進フィードバック分析を CISO directs 昇進キャリブレーションスプレッドシートに追加する責任があります。スプレッドシートは参考用に Security Promotion Projections と題されています。
   • 各昇進候補者の完全なフィードバック分析を列 J に追加し、CISO、CISO directs、セキュリティPeople Business Partnerがアクセスできることを確認します。
   • 期日: 2026-02-12
8. キャリブレーションセッションが行われる
   • キャリブレーションは 2026-02-16 の週にスケジュールされ、CISO directs が部署全体で昇進候補者をキャリブレーションします。
   • CISO direct は、キャリブレーションセッションからフィードバックと重要なポイントを提供するために、昇進候補者のマネージャーとフォローアップする責任があります。
9. マネージャーが昇進ステータスをコミュニケートする
   • 昇進は 2026-05-01 に発効し、コミュニケーションウィンドウは 2026-04-27 から 2026-04-30 までで、会社全体のタイムラインに整合しています
   • マネージャーは、成功または不成功の昇進をチームメンバーと直接コミュニケートします。不成功の昇進については、チームメンバーに明確なフィードバックを提供する必要があります。

フィードバックの機密性

このプロセスを通じての目標は、より定期的で継続的なフィードバックを提供する機会を引き続き促進し、部署としてフィードバックの筋肉を鍛えることです。チームメンバーが提供するフィードバックを所有して関係を強化し、お互いの成長と開発に投資し、フィードバックを受け取るチームメンバーが必要に応じて明確化質問をする機会を提供するよう、私たちはチームメンバーに奨励します。

フィードバックフォームはフィードバック提供者の情報を要求するため、昇進候補者とそのマネージャーは、提供されたフィードバックの詳細を可視化できます。CISO directs キャリブレーションセッションでは、この構造でテーマをレビューします。

提供されたフィードバックは、昇進候補者のリーダーシップチェーン、CISO directs グループ、整合するPeople Business Partner外では共有されません。

リソース

セキュリティ昇進フィードバックプロセスのために上記で強調された主要なリソースの概要。これらは、プロセス中に使用されるリソース、またはチームメンバーとフィードバック提供者がプロセスをキックオフする前にレビューすることをお勧めするリソースです。

• GitLab 職務フレームワーク
• セキュリティ職務ファミリー
• フィードバックに関するガイダンス
• GitLab 職務レベル
• ビジネス結果
• 昇進ドキュメント
• フィードバック提供者 Google フォーム
• フィードバック分析テンプレート
  
  
  
  
  
  
  
  

VP+ 役割の採用

社内昇進と新しいリーダーシップ役割の両方に一貫したレベルのレビューを確保するため、すべての新規 VP 以上の「採用予定」役割は e-group によってレビューおよび承認されます。シニアリーダーは、提案された役割の正当化ドキュメントを作成するために、People Business Partnerとパートナーシップを組む必要があります。正当化ドキュメントにより、e-group は役割のビジネスニーズと、組織内でどのように整合するかをよりよく理解できます。

このレビューは、e-group オフサイト中に行われる組織設計議論の一部です。

提案された役割は、組織がビジネスニーズへの可視性を持ち次第すぐにレビューできます。ただし、新しい VP+ 役割のニーズがこれらの組織設計議論外で発生した場合、採用慣行のアジャイル性と競争力を引き続き確保するために、週次の e-group ミーティング中にレビューできます。

正当化ドキュメントは次の場合に使用される必要があります:

1. 既存の役割をより高いレベル (VP+) でバックフィルすることを決定した場合
2. VP+ 役割の新規ヘッドカウントを開く場合 (現在の会計年度のヘッドカウント計画に組み込まれていなかった)

マネージャーのプロセス: 昇進のリクエスト

1. 昇進変更が年 2 回の昇進サイクルを通じて処理されるべきか、Greenhouseを通じて処理されるべきかを判断します
2. 年 2 回の昇進サイクルで進める場合、People Business Partnerとリーダーシップと協働して、計画プロセスの前に昇進を推奨し、チームメンバーが計画とキャリブレーションに含まれるようにします。この時点で昇進または報酬変更ドキュメントが作成されていることを確認します。
   • 昇進を推奨しているチームメンバーが director またはそれ以上の場合は、director およびそれ以上への昇進を参照してください。
3. 昇進/報酬変更が Greenhouse を通じて処理されるべき場合は、Greenhouse 昇進/異動プロセスセクションで概説されているステップに従ってください。
4. 昇進が例外と見なされる場合は、例外の処理方法: Workday でのサイクル外昇進リクエストの提出で概説されているステップに従ってください。

プロセスを開始する前に考慮すべきこと:

• チームメンバーが昇進を通じて次のレベルに移動する準備ができていても、ビジネスの性質上、その特定の役割または次のレベルが利用できない場合があります。たとえば、チームメンバーは Manager または Director の役割の準備ができていますが、ビジネスにはその時点で追加のマネージャー/ディレクターのニーズ、予算、範囲がありません。そのポジションは将来利用可能になる場合とならない場合があります。
• 空席がジョブページを通じて広告されている場合、個人は役割の応募を提出する必要があります。同様に、空席投稿がない場合は、誰もが応募し検討される機会を持てるよう、空席投稿を作成し #new-vacancies Slack チャンネルに共有する必要があります。

報酬の増加の推奨

GitLab では、昇進が報酬の観点でインパクトがあり、同じ役割のピアと公平であることを確保しています。マネージャーは、直接の部下のキャッシュ報酬の増加の推奨を提案します。質問がある場合は、People Business Partnerまたは Total Rewards チームに気軽に連絡してください。

昇進報酬ガイドライン

• チームメンバーが同じ職務ファミリー内のあるレベルから次のレベルに昇進する場合、報酬範囲の最小値と中央値の間に持っていくのが一般的です。
• Total Rewards チームは通常、昇進の一部としてキャッシュ報酬への 5〜10% の増加を推奨します。追加のエクイティは、昇進のエクイティに基づいて固定されます。
  • ベンチマークデータは、通常人口の 4〜8% が昇進することを示しており、平均基本給与の 4.1% 増加を示しています。
• 以下の条件を持つ昇進は、Total Rewards チームとエグゼクティブ承認者への追加の正当化が必要です。昇進ワークシートのコメントとしてビジネス上の正当化を追加してください。
  1. 10% を超える増加

異動報酬ガイドライン

Greenhouse で異動の報酬をレビューする際、Total Rewards チームは、以下の一般的なガイドラインを使用してオファー詳細を承認する前に、同じような役割間で内部公平性を確保します:

1. ラテラル異動 (異なるまたは同じ職務ファミリー、同じグレード): 通常、チームメンバーがラテラル異動で増加を受けることは期待しません。これには、グレードまたは職務レベルの変更なしにテリトリー、セグメント、専門分野の変更を受けるチームメンバーが含まれます。
2. 昇進異動 (異なるまたは同じ職務ファミリー、より高いグレード): 通常、チームメンバーが 5〜10% の増加を受けることを期待します (昇進の期待される増加に整合)。
3. その他の異動タイプ: ケースバイケースでレビューできる他の異動があります。たとえば、誰かが異なるまたは同じ職務ファミリーのより低いグレードに異動する場合、役割の市場レートとの整合性を確保するために報酬が下方調整される場合があります。レビューを行うために Greenhouse で Total Rewards チームをタグ付けしてください。

Workday サイクル外昇進承認プロセス

このセクションでは、People Business Partnerが Workday で昇進リクエストを送信した後の承認チェーンについて説明します。

1. 変更は、マネージャー、次のレベルマネージャー、e-Group リーダーに承認のためにルーティングされます。
2. リクエストが承認された場合、People Operations チームは DocuSign で職務変更レターをステージングします。
3. DocuSign はマネージャーにチームメンバーと昇進について議論するよう促します。マネージャーは、1-1 ミーティングでコールで職務変更レターを共有することにより、チームメンバーに変更をコミュニケートします。マネージャーとチームメンバーはレターを処理/署名します。署名後、マネージャーは Slack の #team-member-updates チャンネルで昇進をアナウンスします。アナウンスでは、マネージャーは個人が昇進基準をどのように満たしたかを記述し、お祝いを述べます。
4. 部門とマネージャーの変更については、People Operations チームメンバーは組織変更チェックリスト Issue を作成します。

People Operations チーム向け: 昇進、内部異動、報酬変更の処理

1. リクエストが Workday を通じて承認された場合、People Operations チームは職務変更レターを作成しますが、リクエストが Greenhouse を通じての場合、People Operations チームは People Operations チームメールで通知されます、CES チームによって職務変更レターが作成され署名されました。

職務変更レター

1. 国別の署名要件をレビューし、それに従って職務変更レターを処理します。すべての法人と国の場所で職務変更レターが必要なわけではないことに注意してください (たとえば、米国のチームメンバーは職務変更レターを受け取りません)。
2. 該当する職務変更レターテンプレートのコピーを作成し、Workday リクエストに基づいてすべての適用可能な情報を入力し、該当する署名者または会社署名スタンプを追加します。発効日は次のとおりです:
   • 変動報酬の変更があるセールス担当者の場合、発効日は法人に関係なく常に月の 1 日です。
   • チームメンバーが報酬の変更なしのラテラル移動を行う場合、開始日は任意の月曜日にできます。
   • 米国のチームメンバーの場合、発効日は 1 日または 16 日のいずれかである必要があります。ペイロール締切日が現在のペイ期間で経過した場合、発効日は次のペイ期間の開始にする必要があります。発効日を決定する際は、GitLab Inc および Federal Payroll カレンダーを参照する必要があります。
   • たとえば、変更が 6 月 22 日に処理される場合、この日付は 6 月 23 日のペイロール締切日より前なので、発効日は 6 月 16 日にする必要があります。
   • 変更が代わりに 6 月 25 日に処理される場合、これはペイロール締切日後なので、発効日は 7 月 1 日にする必要があります。
   • カナダのチームメンバーの場合、発効日は、変更が処理されるタイミングに応じて、ペイロール締切日に最も近く、それ以降ではないペイ期間の開始にする必要があります。発効日を決定する際は、GitLab Canada Corp Payroll カレンダーを参照する必要があります。
   • たとえば、変更が 6 月 15 日に処理される場合、6 月 6 日のペイロール締切日は経過しているので、これは 6 月 20 日の締切日を持つ次のペイ期間に行きます。6 月 20 日の締切日に対応するペイ期間の開始は 6 月 21 日であるため、6 月 21 日が発効日になります。
   • その他のすべての変更については、月の 8 日以前に処理される場合は当月の 1 日、月の 8 日以降に処理される場合は翌月の 1 日が発効日です。
   • たとえば、GitLab Ltd チームメンバーが 6 月 7 日に処理される変更を持つ場合、これは 6 月 1 日に発効します。
   • 変更が代わりに 6 月 15 日に処理される場合、これは 7 月 1 日に発効します。
3. エクイティ報酬は、米国外の誰かの職務変更レターには含まれてはなりません。RSU 情報を含む別のレターが職務変更レターに含まれていることを確認してください。
4. チームメンバーがフランスに雇用されている場合、レターでの分類を確認できるよう、Legal Employment チームと職務変更レターを共有してください。
5. 会社のスタンプのみが必要な場合、レターは変更をコミュニケートするためにチームメンバーのマネージャーにメールで送られる必要があります
6. 電子署名が必要な場合、DocuSign でレターをステージングし、GitLab メールアドレス経由で署名する以下のチームメンバーを追加します:
   • マネージャー用にラジオボタン (追加のものは削除) を追加して、マネージャーが 1:1 Zoom コール中に職務変更レターを共有することにより、チームメンバーに変更をコミュニケートし、そして再度ラジオボタンを 1 つ追加 (追加のものは削除) して、#team-member-updates Slack チャンネルでアナウンスします。
   • チームメンバー用の署名フィールドを追加します
   • チームメンバー用の署名日フィールドを追加します
   • 注: a) ドキュメントを準備する際に「Set signing order」オプションが選択されていること、b) ラジオボタンのみが required field/mandatory field オプションの選択を可能にするため、チェックボックスではなくラジオボタンを選択することを確認してください。これにより、マネージャーがレターのタスクをチェックせずにレターを処理することを禁止します。
7. 署名済みのレターを、Workday プロフィール内のそれぞれのチームメンバーのドキュメントタブに保存します。
8. 組織変更チェックリストのここで述べた基準を満たしている場合、People Operations Specialists は Workday からアラートを受け取り、異動するチームメンバーのために Issue が開かれることを確実にします。

暫定および代理役割

暫定 (Interim)

エンジニアリング部署内のキャリア開発構造の一環として、暫定 (interim) および代理 (acting) 役割の機会が時折発生します。暫定および代理役割がエンジニアリングキャリア開発にどのように適合するかについての詳細は、エンジニアリングキャリア開発ハンドブックページを参照してください。暫定および代理プロセスに関する情報については、以下を続けて読んでください。

暫定期間の開始

定義セクションで強調されているように、すべての暫定役割は (応募者の数に関係なく)、Greenhouse 応募および面接プロセスを経る必要があります。面接プロセスのステップは、採用マネージャーと次のレベルリーダーによって決定されます。これには、標準の GitLab 採用プロセスのいくつかのステップが含まれます。暫定役割への応募に興味のあるチームメンバーのプロセスは次のとおりです:

1. チームメンバー: Greenhouse で暫定ポジションに応募します。

チームメンバーが面接プロセスを成功裏に完了し、暫定期間に選ばれたら、チームメンバーが暫定役割で成功するための準備が整うように、以下のステップを取る必要があります。

1. CES: 暫定期間の開始を最終化するための職務変更レターを発行します。レターには、暫定職務タイトル、開始日、終了日 (既知の場合) を含める必要があります。職務変更レターは重要です。これは、Total Rewards が Greenhouse からの変更を通知される方法です。
2. People Operations: Workday でチームメンバーの職務およびビジネスタイトルを更新して、暫定役割を開始したことを反映します (例: Senior Manager, Engineering (Interim))。この更新は、暫定の開始日と終了日を追跡するための SSOT として機能し、現在暫定役割で執行している人物に関する透明性を提供します。暫定期間は報酬への影響がないため、職務コードと職務レベルは同じままです。つまり、Change Job プロセスを開始する際に他のフィールドを更新しないでください。
3. 現在のマネージャー: 暫定マネージャーに移動する必要のある直属の部下がいる場合、この変更は現在のマネージャーまたは必要に応じてそれぞれのグループのPeople Business Partnerが Change Manager プロセスに従って Workday で開始する必要があります。ここでの哲学は、チームメンバーが面接プロセスを成功裏に経て、マネージャー役割の暫定期間に対応できる準備ができていることを示したのであれば、Workday で直属の部下を持つために必要なレベルの EQ と裁量を持っているということです。もちろん、暫定期間が昇進で終わらない場合、チームメンバーは引き続き機密情報を機密として扱うことが期待されます。

暫定期間の終了

暫定期間が終了する際、次の 2 つの結果のいずれかが発生する可能性があります:

• チームメンバーが成功基準に整合して暫定期間を成功裏に完了し、永続的に暫定役割に移動します。
  • 一般的なガイドラインとして、暫定期間は 30 日以下にならず、4 か月以上にもならないようにする必要があります。
  • People Business Partnerは、変更を公式にするために、昇進ドキュメントを含む Change Job job aid を使用して Workday で昇進リクエストを送信する必要があります。Workday では、変更の理由を Promotion - Promotion にする必要があります。暫定までの達成と暫定中の達成を昇進ドキュメントに使用できます。マネージャーは、昇進ドキュメントを作成し、報酬の増加を推奨する責任があります。注: チームメンバーの移動が昇進につながる場合にのみ、昇進ドキュメントが必要です。ラテラル移動の場合、昇進ドキュメントは必要ありません。
• チームメンバーが暫定期間を成功裏に完了しないか、マネージャートラックを追求したいものではないと決定し、暫定期間前の役割に戻ります。
  • 暫定期間が成功しなかった理由がチームメンバーに明確になるよう、チームメンバーと採用マネージャー間でフィードバックセッションが行われるべきです。
  • People Business Partnerは、マネージャーのリクエストに応じて、暫定期間が終了したらチームメンバーの職務タイトルを元に戻すために、Workday Change Job プロセスおよび承認フローを Workday で送信する必要があります。
  • 暫定期間を成功裏に完了しないことは、チームメンバーが将来同様の役割に移動できないことを意味するわけではありません

結果に関係なく、暫定期間が終了する際、マネージャーは暫定ボーナスの適格基準をレビューし、チームメンバーのために暫定ボーナスリクエストを送信する必要があります。完全なボーナス計算がボーナス提出のコメントに記載されていることを確認してください。

Workday での暫定の移動の更新

暫定役割への職務変更レターを受け取ったら、以下のように変更を処理します:

1. レターを Workday の Documents > Contracts & Changes Document Category に保存します
2. 報酬変更をレビューします
3. アクセスレベル
   • 暫定役割 - アクセス変更 (必要な場合)
4. 職務タイトルを更新します (必要な場合)
5. マネージャーを更新します (必要な場合)

注: 代理役割の場合、Workday で変更は行われません。代理ポジションを追跡するために、マネージャーはこのフォームを完成させる必要があります。

代理 (Acting)

「代理」で役割にいる人は、一時的に役割を占有し、元の役割に戻る人です。役割で「代理」を務めることは、その役割が個人のキャリア開発パスの目標に合うかを判断するために役割を実験するためかもしれませんし、永続的に役割を埋めるために誰かを雇う間、空いた役割を埋めるためかもしれません。暫定はエンジニアリング部署にのみ適用されますが、代理は GitLab 全体で使用されます。

代理役割は通常昇進で終わらないため面接は必要ありません。また、通常、Workday で直属の部下が代理マネージャーに移動することもありません。 代理ポジションのために誰かを選択するプロセスは次のとおりです:

• 今後の代理役割はスタッフミーティング中に議論されます。
• リーダーシップは、今後の代理役割のためにチームメンバーから関心を集めることができます。
• 採用マネージャーは、代理役割に最も適したチームメンバーを決定します。
• 先に進む前に、部門長が代理期間と選択された候補者を認識しサポートしていることを確認してください。

代理期間が終了する際、マネージャーは暫定ボーナスの適格基準をレビューし、チームメンバーのために暫定ボーナスリクエストを送信する必要があります。

代理役割と内部モビリティ

チームメンバーが代理の役割で働いていて、その役割が公式に募集中のポジションになる場合、非公式の代理の役割にいるチームメンバーは、他の候補者と一緒にオープン役割の検討対象となる可能性があります。チームメンバーが代理ポジションを永続的にすることに興味を示す場合、以下のプロセスに従う必要があります:

1. チームメンバーがマネージャーに、ポジションを永続的に追求することへの興味を表明します。
2. チームメンバーが、代理の役割でのこれまでのパフォーマンスについてフィードバックを受けるために、採用マネージャーに連絡します。
3. チームメンバーは、標準的な採用慣行に整合して、Greenhouse でポジションに応募することを歓迎されます。 注: 採用マネージャーと代理チームメンバーが相互に同意して役割の検討を進める場合、ポジションが現在の役割と同じまたはより低い職務レベルで、同じ部署内にあり、ピープルマネジメントポジションでない場合、正式な面接プロセスは必要ない場合があります。採用マネージャーが面接プロセスを含めないことを好む場合、整合するPeople Business Partner (PBP) と接続して、彼らがサポートしていることを確認する必要があります。代理ポジションにいるチームメンバーが時間をかけてポジションで成功する能力を実証する独自の経験のため、この面接例外の可能性が存在します。
4. チームメンバーが正式にオープン役割に移動した後、バックフィルポジションが作成されます。

降格

降格は常に後退とは見なされません。チームメンバーが新しいスキルを習得する機会、または彼らの興味のある領域により密接に整合する役割に移動する機会である可能性があります。あなたの直属の部下の 1 人を降格するには、マネージャーは以下のステップに従う必要があります:

• 降格がパフォーマンスによる場合、マネージャーは Team Member Relations とパフォーマンスの問題や可能な降格について議論する必要があります。
• 降格には Google ドキュメントでの報酬とエクイティのレビューも含める必要があります。マネージャーはこれらのトピックについて Total Rewards チームに相談する必要があります。
• チームでの降格と変更 (もしあれば) について合意に達したら、関連する Google ドキュメントが完了した後、降格を Compensation Group がレビューおよび承認するためのエスカレーションポイントとして機能します。
• 承認されたら、マネージャーは個人に通知し、HelpLab 経由でリクエストを提出して必要な変更をリクエストする必要があります。その後職務変更レターが作成されます。
• その後、People Operations チームはPeople Operations チーム向け: 昇進と報酬変更の処理の下にリストされているプロセスに従う必要があります。
• コミュニケーションは個人への敬意のために必要な人に限定し、公開してはなりません。
• マネージャーは必要なアクセスリクエストまたはアクセス変更リクエストを開始します。

職務タイトル専門分野の変更

職務タイトルの専門分野は、ステージ、グループ、および/または責任範囲内のチームメンバーの特定の焦点領域を示すために使用されます。これらの専門分野は職務タイトルの一部ではありませんが、ステージ、グループ、および/または焦点領域への投資に関するレポートに反映されるために使用されます。また、People Group とリーダーが組織健全性指標と比率をレビューするために活用するリソースでもあります。

チームメンバーの職務タイトル専門分野に変更が必要な場合、マネージャーは新しい職務タイトル専門分野情報と変更の発効日 (Data Correction を選択) を含む People Operations チーム向けの HelpLab ケースを作成する必要があります。既に存在しない新しい職務タイトル専門分野を作成する必要がある場合は、Workday: Job Title Specialty Request テンプレートを使用して Workday で作成してもらうために Issue を開いてください。Workday でこのフィールドが正確であり続けることを確実にすることは、マネージャーの重要な責任です。

マネージャー向けの職務タイトル専門分野ガイダンス

GitLab のさまざまな部署は、職務タイトル専門分野をさまざまな方法で管理しています。以下に、一貫したアプローチを確保するために職務タイトル専門分野をどのように考えているかを文書化するために、特定の部署向けのガイダンスを概説しました。

チームの現在の職務タイトル専門分野のレポートに簡単にアクセスするには、以下のステップに従うことができます:

• Workday にログインします
• 検索バーに “My Team Job Title Specialties” と入力します
• あなたの組織のために “OK” をクリックします

Development および Infrastructure 部門の場合

• 誰が専門分野を持つべきか:
  • IC: ステージおよび/またはプライマリーグループ (該当する場合) を持つべきです
  • ピープルマネージャー: IC を管理する Manager、Senior Engineering Manager、Group Product Manager は、ステージおよび/またはプライマリーグループ (該当する場合) を持つべきです
• 職務タイトル専門分野の更新をリクエストする際は、以下のフォーマットに従ってください:
  • Product/Categories をレビューし、使用するグループ名がこれらに一致することを確認します。一致しない場合は、Product Manager に接続して確認し、必要に応じて更新するために協働してください。
  • 職務タイトル専門分野フィールドにステージとグループの両方を追加します
    • 例: “Authentication” の代わりに “Govern: Authentication” を追加
    • 重要: ステージとグループの間のコロン (:) の後にスペースを残してください。たとえば、Create: Source Code は正しいフォーマットで、Create:Source Code は正しくないフォーマットです。これは、レポートを取得する際に投資の整合性に対する正確なカウントを確保するのに役立ちます。
  • 各人をレビューし、1 つのグループのみがリストされていることを確認します。
    • 注: 2 つのグループがある状況では、プライマリーグループを選択します。
  • すべての専門分野情報が Job Title Specialty (Multi-Select) フィールドではなく Job Title Specialty フィールドにあることを確認します。

Customer Support 部門の場合

• 誰が専門分野を持つべきか:
  • IC: 役割の焦点が Global、Federal、Readiness (該当する場合) であることを示します
  • ピープルマネージャー: Manager と Senior Manager が役割のプライマリーフォーカスを示します (該当する場合)。

注: サポートの場合、ステージやグループではなく、職務タイトルに捉えられていない役割の焦点に紐付いています。

• 職務タイトル専門分野の更新をリクエストする際は、People Operations に連絡する際に必ず以下のフォーカスエリアのいずれかを使用してください:
  • Global
  • Federal
  • Readiness

Workday でのマネージャーセルフサービス: 職務情報変更

職務情報の変更は、報酬関連ではない Workday のチームメンバーのプロフィール上の任意の情報を更新するために使用されます。現在のマネージャーがすべての職務情報変更リクエスト (チームメンバーのマネージャーを変更するリクエストを含む) を送信します。これらの変更は、コンプライアンス上の理由から承認証跡を持つために Workday を通じて必要です。

現在のマネージャー向け: マネージャー変更の処理

このジョブエイドは、Workday 内でチームメンバーを別のマネージャーに移動する方法に関する指示をピープルマネージャーに提供するのに役立ちます。直属の部下を移動する必要のあるマネージャーが利用できない場合は、おそらく「supervisory organization」が作成されていないことを意味します。管理レベルが「Manager」と表示されていても、Workday でチームメンバーが直属の部下を持つには監督組織が必要です。監督組織は、彼らが管理しているチームに固有の名前を持つべきです (例: Commercial Sales - EMEA、Content Marketing (John Smith)、Backend Engineering - Ruby)。監督組織のセットアップが必要なチームメンバーの名前、固有の名前、監督組織の発効日を HelpLab 経由で People Operations チームに連絡してください。Workday でセットアップをお手伝いします。

セールスマネージャーへの注: チームメンバーが Workday で正しいセールスマネージャーの下に移動されない場合、セールスコミッションのクレジットが正しいマネージャーにロールアップされません。コミッション対象役割の追加の昇進と異動の考慮事項はこちらを参照してください。

People Operations 向け: マネージャー変更の処理

1. People Operations Specialist は Okta 経由で Workday にログインして、Workday で異動を承認します > 右上隅の Inbox をクリック
2. ‘Transfer’ というタイトルのビジネスプロセスと ‘Manager to Another Manager’ という理由をレビューします > クリック: approve

EBA がシニアリーダーシップを更新するプロセス:

1. People Operations チームに変更を Workday で行うようリクエストし、発効日を提供するために、HelpLab でケースを作成します。
2. People Operations チームが Workday で変更を処理します。
3. 完了したら、チームは EBA にフォローアップして、すべての変更が行われたことを知らせます。
4. その後、EBA はチームページで変更を行う必要があります。

People Operations 向け: 職務情報変更リクエストの処理

1. すべての職務変更リクエストを監査し、変更が Payroll トラッカーで捕捉されていることを確認します。
2. Job Title Specialty 変更リクエストの場合、マネージャーは Workday でチームメンバーの Speciality を更新してもらうために People Operations チーム HelpLab に連絡します。
   • People Operations チームメンバーは、タイトルが既に Workday に存在するかどうかを確認する必要があります。存在しない場合は、Job Speciality がそれぞれの部門ハンドブックページに追加されているかどうかをチェックします (例: https://handbook.gitlab.com/handbook/engineering/ai/search/、または People Operations チームメンバーがそれを追加するためにそれぞれの Issue にタグ付けされているかどうか。不明な場合は、それぞれのPeople Business Partnerに連絡してください)。

部門異動

募集中の役割に応募することに興味がある場合は、Greenhouse または #new-vacancies Slack チャンネルで見つけられる社内求人掲示板リンクを通じてそうしてください。

応募を進められるようにするには、以下の適格性ガイドラインを満たす必要があることを理解してください:

• パフォーマンス適格性のガイドライン:
  • タレントアセスメント中に Performing または Exceeding Performance レベルと評価されたチームメンバーは、別の役割の検討対象となる資格があります
  • パフォーマンスが Developing と評価されたチームメンバー、または書面によるパフォーマンスマネジメントを積極的に受けているチームメンバーは、対象とならない場合があります。これらの状況では、進めるためにマネージャーおよび/または PBP の承認が必要です。
  • タレントアセスメントを受けていないチームメンバーは、進めるためにマネージャーおよび/または PBP の承認が必要です
  • 役割での期間の適格性は、現在の役割で 6 か月になります。これらの例外:
  • ビジネスインパクト (収益依存、暫定役割から永続役割への移行)
  • ビジネス主導の異動 (再編成の例)
  • SDR/BDR 12 か月の役割期間

社内応募者は応募提出前に現在のマネージャーまたはPeople Business Partnerと話す必要があることに注意してください。公式の応募は、チームメンバーが募集中の役割に応募するか、タレント獲得チームに連絡することによってシグナルされます。役割に関する非公式の会話では、チームメンバーがマネージャーに通知する必要はありません。内部役割への関心をマネージャーにコミュニケートすることに懸念がある場合は、People Business Partnerに連絡してください。

詳細については、私たちの内部採用プロセスハンドブックページを参照してください。

社内応募者向け

異なる職務ファミリー

• 異動に興味がある場合は、新しいポジションに応募するだけです。新しい役割が良いフィットかどうか確信が持てない場合は、採用マネージャーと時間を取って役割についてさらに学んでください。その会話の後、社内の機会を追求することに興味がある場合は、役割に応募する意図を現在のマネージャーに伝えることをお勧めします。応募に許可は必要ありませんが、彼らに対して透明であることをお勧めします。ほとんどの人は、リファレンスチェックとして連絡してきた誰かからあなたの移動を知るより一般的に良いため、その透明性を評価するでしょう。これを、現在のマネージャーおよび/または過去のマネージャーからのあなたのパフォーマンスに関する潜在的な新しいマネージャーに与えられるフィードバックについて議論する機会としても使用できます。
• 異動は、新しいポジションに応募する応募プロセスを経る必要があります (ジョブページで応募)。チームメンバーは、空席記述で概説されているフルインタビュープロセス全体を経る場合があります。標準面接プロセスへの一般的な例外は、行動または「価値観の整合性」段階です。リクルーターは、標準面接プランへの変更の背後にある理由をチームメンバーの Greenhouse プロフィールに文書化します。役割またはプロセスに関する質問がある場合は、部門または部署のPeople Business Partnerに連絡するか、私たちの内部採用プロセスハンドブックページを訪問してください。いずれの場合も、異動が確認される前に、該当するPeople Business Partnerにメールで通知する必要があります。
• 異動の場合、ゲイニングマネージャーが GitLab の社内リファレンス (以前と現在のマネージャーに限定) で確認することが期待され、要求されます。ピアまたは直属の部下と社内リファレンスチェックを行わないでください。質問または例外については、リクルーターとPeople Business Partnerに関与させてください。
• 応募者、現在のマネージャー、またはゲイニングマネージャーが、異動を調整するためにプライベート Slack チャンネルを作成することが推奨されます (必須ではありません)。関連するマネージャー、ディレクター、People Business Partner、財務ビジネスパートナー、リクルーターなど、関与する人を全員招待します。
• 現在のマネージャーがエンジニアリングで役割をバックフィルする必要がある場合、彼らはこのプロセスに従う必要があります。他の部署の場合、彼らは部門長、リクルーター、財務ビジネスパートナーと協働してバックフィルが利用可能であることを確認する必要があります。異動が確認されたら、現在のマネージャーはリクルーターと財務パートナーと協働してバックフィルのための GHP ID を取得し、Greenhouse で役割を開きます。
• オファーが行われる前に、リクルーターは、チームメンバーとゲイニングマネージャーが現在のマネージャーに実際に連絡を取ったことを確認します。彼らは新しい機会と、チームメンバーにオファーが行われることを議論します。
• タレント獲得チームは、該当する場合、オファーが行われる前にポジションが少なくとも 3 営業日掲載されていることを確認します。
• 報酬とエクイティは、新しいレベルとポジションを反映するために採用プロセス中にレビューされる場合があります。
• 面接後、マネージャーと GitLab チームメンバーが異動を進めたい場合、社内リファレンスをチェックする必要があります。マネージャーは異動をブロックできませんが、決定に情報を与えるのに役立つ良いフィードバックがあることがよくあります。GitLab チームメンバーは、新しいチームへの好みを説明し、新しいマネージャーに与えられるフィードバックを理解するために、マネージャーと話すことが推奨されます。また、パフォーマンス要件は役割間で常に等しいわけではないため、GitLab チームメンバーがある役割で苦労する場合、それらの弱点は新しい役割ではそれほど顕著ではないかもしれません、その逆もあります。
• リクルーターと採用マネージャーは、社内候補者とオファー詳細をレビューし、採用プロセスに従って Total Rewards チームから職務変更レターが送付されます
• チームメンバーが異動した場合、新しいマネージャーは #team-member-updates Slack チャンネルでアナウンスし、必要な追加のオンボーディングまたはオフボーディングを開始します。新しいマネージャーが異動アナウンスを行う前に、チームメンバーの現在のマネージャーと、現在のチームがチームメンバーの新しいポジションと異動について通知されていることを確認する必要があります。
• 機能的役割を変更するチームメンバーは、新しい機能のオンボーディングを完了する必要があります。たとえば、Frontend の仕事に移行または取り組むバックエンドエンジニアは、フロントエンドエンジニアのオンボーディングを行う必要があります。

同じ職務ファミリー、異なる部門または専門分野

チームメンバーが現在の職務ファミリーに残るが、専門分野または部門を変更する場合 (例: Plan から Secure への移動、または Development から Infrastructure への移動)、上記のステップに従います。役割の要件が同じであれば、採用手順が短縮される場合があります。最低限、採用マネージャーがチームメンバーと面接することをお願いします。

役割に選ばれた場合、People Operations チームから部門と専門分野への変更を概説する職務変更レターが送付され、People Operations チームが Workday で処理します。現在のマネージャーが役割をバックフィルする必要がある場合、財務パートナーに連絡する必要があります。

社内部門異動

部門内の別のポジションに興味があり、そのマネージャーがあなたのマネージャーでもある場合、以下を行う必要があります:

• Google ドキュメントでマネージャーに提案を提示します。
• 空席がジョブページで広告されている場合、検討されるには応募を提出する必要があります。空席投稿がない場合は、誰もが応募し検討される機会を持てるよう、空席投稿を作成し #new-vacancies チャンネルに共有する必要があります。
• マネージャーは機能要件を評価します。各レベルは空席記述で定義されている必要があります。
• 承認された場合、マネージャーは関連する指揮系統を通じてマネージャーの承認を取得する必要があります。
• 報酬とエクイティが再評価されます。この部分が含まれるまで提案を送信しないでください。
• チームメンバーが異動した場合、マネージャーは #team-member-updates Slack チャンネルでアナウンスし、必要な追加のオンボーディングまたはオフボーディングを開始します。

内部異動の開始日

GitLab チームメンバーが新しい役割に選ばれた場合、マネージャーは合理的で迅速な異動計画について合意する必要があります。通常、最大 4 週間が合理的な期間ですが、会社、影響を受ける人々、プロジェクトの最善の利益となる方法で異動を完了する判断を行うべきです。

合意された異動日は、現在のマネージャー、新しいマネージャー、異動するチームメンバー間で異動日が整合するように、Greenhouse のオファーレターに反映されるべきです。これは、両方のチームが計画を立て成功への準備を整えるために不可欠です。バックフィルが採用される間、退職するチームメンバーの作業負荷をカバーするために、チームメンバーの以前のチームがシャッフルすることが通常であることに注意することが重要です。これは、スムーズで迅速な異動と前向きなチームメンバー体験を確保するためです。開始日について整合する際、開始日を選択する際にペイロール整合性も考慮してください。

異動を遅らせることは、異動する個人にとって良いチームメンバー体験を確保するために避けるべきですが、不可抗力により異動日を延期する必要がある場合、両方のマネージャーがチームメンバーに伝える新しい異動日について合意する必要があります。

部門異動 マネージャー主導

すべての異動は最終的にチームメンバーが開始する必要があります。

• 応募プロセス中、採用マネージャーがチームメンバーの現在のマネージャーと透明であることを強く推奨します。そうすることで、現在のマネージャーが異動の計画を立てるための最大限の時間が確保され、全体のプロセスがスピードアップされます。
• 採用マネージャーは、潜在的に興味のあるすべての候補者を引き付けるために、#new-vacancies Slack チャンネルにオープン役割を投稿する必要があります。
• 最初にマネージャーと話さずに潜在的な候補者に直接連絡することは強く非推奨です。採用マネージャーは、透明性と認識を確保するために、現在のマネージャーのチームメンバーに連絡する意図を共有する必要があります。

昇進が考慮されるとき - 同じ職務ファミリー内

チームメンバーが、自身の職務ファミリー内の 1 つ上のレベルの空席が投稿されているのを見た場合 (たとえば、Intermediate Frontend Engineer が Senior Frontend Engineer の空席を見た場合)、チームメンバーはマネージャーとその機会を探ることについての会話を持つべきです。

マネージャーは、昇進準備状況に関連するチームメンバーのパフォーマンスについて正直であることが責任です。マネージャーがチームメンバーが準備ができていると同意する場合、彼らは周期的な昇進キャリブレーションプロセスに従います。彼らがチームメンバーが昇進の準備ができていないと考える場合、彼らはキャリア開発ドキュメントを見直し、チームメンバーと昇進プランに取り組む必要があります。マネージャーは、チームメンバーがこの時点で昇進の準備ができていないこと、および何に取り組む必要があるかを明確にする必要があります。マネージャーとの会話の後、チームメンバーがまだ役割への応募を提出したい場合、彼らは応募し、外部候補者と同じ面接プロセスを経ることができます。リクルーターは、社内面接プロセスが開始される前に、昇進準備状況の会話が行われたことをマネージャーと確認します。

社内応募者向け - 異なる職務ファミリー

役割が完全に異なる職務ファミリー内 (自身の部署内、または完全に異なる部署内、たとえば、プロダクトデザイナーがプロダクトマネージャーの役割に興味がある場合)、チームメンバーは Greenhouse の GitLab 社内求人掲示板に投稿されたものを通じて応募を提出する必要があります。

チームメンバーが応募した後、リクルーターはチームメンバーに連絡して、役割の報酬について連絡を取ります。場合によっては、報酬が現在のものより低いかもしれません。チームメンバーが新しい役割の報酬を理解し同意したら、プロセスを続けることができます。 社内と外部の候補者は、フルスクリーニングコール (上記のように、報酬について議論する短い会話になる) を除き、同じプロセスに従います。ただし、社内応募者が同じ部署にとどまっていて、エグゼクティブレベルの面接がプロセスの一部である場合、エグゼクティブは面接をスキップすることを選択できます。すべての面接フィードバックとノートは、チームメンバーから自動的に隠される社内チームメンバーの Greenhouse プロフィールに捕捉されます。面接が完了した後、社内「リファレンスチェック」が応募者の現在のマネージャーと新しい採用マネージャーによって行われます。 チームメンバーが社内で異動する希望とキャリアの志向についてマネージャーに通知することが推奨されます。マネージャーは、新しい採用マネージャーからではなく、チームメンバーが現在のマネージャーにリファレンスを確認する前に、チームメンバーから新しい機会について聞くべきです。

役割について確信が持てない場合は、採用マネージャーとコーヒーチャットをセットアップして自己紹介してください。役割への興味と、空席要件と必要なスキルについてもっと学びたいという願望を表明します。その会話の後に、自分が資格を持っているか、移動を快適に行えると感じない場合、採用マネージャーに、次の機会のために準備ができるよう自分自身を開発するために何ができるかについてのガイダンスを提供するよう依頼してください。採用マネージャーと学習のためのインターンシップをセットアップすることも可能かもしれません。

社内昇進/異動のアナウンス

組織変更チェックリストが役割を変更するロジスティクスをキックオフすることを目指す一方で、以下のガイドラインは、関与するすべての当事者からの一貫性と整合性を確保するために、社内昇進と移行のコミュニケーションを導くことを意図しています。

1. 会社全体のアナウンスの前に、チームメンバーは直近のチームメンバーとニュースを共有する機会を与えられる必要があります。
2. 昇進には通常エクイティ付与も含まれます。エクイティ付与金額が職務変更レターに記載されていない場合、マネージャーは以下のステップに従って Workday にナビゲートしてチームメンバーにコミュニケートする金額を見つけることができます:
   • Workday にナビゲート
   • 昇進したチームメンバーのプロフィールに行きます
   • 左パネルの Job をクリックします
   • 上部のタブから Worker History をクリックします
   • タイトルに Stock Grant を含み、昇進の発効日のビジネスプロセスをクリックします。
   • これにより、イベントを表示する新しいページが開きます。Stock Grant Details テーブルまでスクロールダウンして、提案された金額を確認します。

注意してください: エクイティ付与には取締役会の承認が必要です。コミュニケーションを取る際、マネージャーはこのエクイティ金額が提案された金額であるが、次の取締役会ミーティングまで公式に承認されないことを強調するべきです。

1. new manager は #team-member-updates Slack チャンネルにアナウンスを投稿する必要があります。これは理想的には (タイムゾーンが許す場合) 候補者が 職務変更レター に署名した同日に発生するべきです。
2. 職務変更レターが署名された同日にアナウンスすることが不可能な場合、アナウンスは候補者が署名してから 24 時間以内である必要があります。
3. この初期アナウンスに続いて、現在のマネージャーは、他の関連するチーム固有のチャンネルでこのアナウンスを行うことができます。

すべての場合のアナウンスは、昇進の背後にある「なぜ」を説明する必要があります。チームメンバーの貢献または実際の昇進ドキュメントをいくつかのポイントで共有することは、透明性を促進し、パフォーマンス期待に関する明確さを提供し、他の人が昇進への道を理解するのを助けます。

注: Total Rewards と People Operations チームは、その役割の一部として情報を更新する管理により昇進または異動を可視化できる場合がありますが、アナウンスが行われるまで昇進/異動についてチームメンバーとコミュニケーションを取ってはなりません。_

People Success と Talent Acquisition チーム向け

空席は、Greenhouse 社内求人掲示板を使用して少なくとも 3 営業日内部に投稿されます。役割が内部に投稿されない場合、新しい役割を受けたチームメンバーの Workday ドキュメントに文書化されたビジネスケースが必要です。詳細については部門異動を参照してください。

詳細は職務変更レターセクションで見つけることができます。

組織変更チェックリスト

以前は Career Mobility Issue として知られていた組織変更チェックリストは、チームメンバーが以下の基準のいずれかを満たすときに、彼らのアクセスがレビューされることを確実にするために開かれます:

• マネージャーから個人コントリビューターへの移行 (Workday 内で Mgr+ から IC への管理レベルの減少として定義)
• チームの移行 (組織変更チェックリストの目的のために、チーム変更はマネージャーとコストセンターの両方の変更として定義)

管理レベルに移動する個人コントリビューターは、彼らのアクセスがレビューされる必要がある場合とそうでない場合があります。このステップを確認するために、現在のマネージャーと新しいマネージャーに確認してください。アクセスを更新する必要がある場合は、こちらに文書化された AR プロセスに従ってください。

または、チームメンバーが必要なシステムとツールへのアクセスを既に持っている場合、マネージャーは GitLab のトレーニングプロジェクト内にハウスされている ‘Becoming a GitLab Manager’ と ‘Interview Training’ Issue を開くことができます。

• ‘Becoming a GitLab Manager’ と ‘Interview Training’ Issue を開くには、GitLab のトレーニングプロジェクトを訪問 -> Issue -> 新規 Issue。
• ‘Description’ で指定されたプロジェクトテンプレートを選択し、下部の Create Issue を選択します。

組織変更チェックリストが必要ない場合 (リクエストは可能):

• チーム/専門分野の変更だが、アクセスリクエストは不要

マネージャーがチームメンバーの役割に組織変更チェックリストが必要だと感じる他の役割変更については、HelpLab 経由で People Operations チームに連絡してください。

組織変更チェックリスト作成プロセス

それぞれのローテーションの People Operations Specialist は、(基準に基づく適格なチームメンバーのために) Workday からアラートを受け取ると組織変更チェックリストを開き、サポートのために移行に割り当てられます。

People Operations Lead は、適格なチームメンバーが組織変更チェックリストを開いたかどうかを確認するために、月次レポートを引きます。

組織変更チェックリストは、割り当てられた People Operations チームメンバーによって、自動化された Slack コマンドを使用して、発効日に、またはマネージャーがチームメンバーの移行の準備を開始できるよう発効日後 3 日以内に作成されます。

確実にする重要な事項:

1. 移行発効日から 2 週間の期日を追加します。
2. 以前のマネージャーと新しいマネージャーが Issue で正しくリストされていることを確認します。
3. People Operations リストの下にあるすべての該当タスクを完了します。

組織変更チェックリストが最終化された後の重要なタスク

チームメンバーが成功するためのセットアップには、現在のマネージャーと新しいマネージャーの両方によるアクションが必要です:

• 必要なシステムと、もはや必要のないシステムのために正しいアクセスリクエストを作成します。
• 必要なトレーニング Issue を作成します。
• チームメンバーにチームページ、GitLab プロフィール、Zoom、Slack、LinkedIn などのプロフェッショナルネットワークでタイトルを更新するように思い出させます。関連する場合は、新しい名刺を注文することも思い出させます。
• 年次報酬レビューの途中の場合、現在のマネージャーと新しいマネージャーが、同期または非同期でフィードバックの引き継ぎを成功裏に手配することが推奨されます。
• 該当するチームメンバーによるすべての移行タスクは、移行開始日から 2 週間以内に完了する必要があります。

コミッション対象役割の従業員の昇進と異動

このセクションでは、セールスコミッションプランを持つ従業員を昇進または異動するために必要なステップを説明します。昇進または異動が発生するとき、セールスマネージャーは、移行中のスムーズな従業員体験を確保するために特定のステップに従うことが重要です。セールスオペレーション、セールスファイナンス、コミッションチームは、必要なシステムを更新し、チームメンバーが新しい報酬プランを受け取ることができるよう通知される必要があります。

注 これらのステップは、People チームとパートナーシップを組んで昇進と異動に必要な他のすべてのステップに加えてのものです。

現在のセールスマネージャー向け

1. 昇進および/または異動の正しい道を決定します。私たちの昇進プロセスはハンドブックにあります。異動の場合、セールス採用チームにオープン役割があるかどうかを確認してください。昇進および/または異動を処理する前に、必要なステークホルダーとプロセスに従っていることを確認します。
2. セールスオペレーションに変更を通知し、Salesforce とテリトリーマッピング SSOT を更新できるよう、テリトリー変更リクエスト Issue を開きます。

セールス採用向け

1. セールスファイナンスに昇進/異動を通知し、Adaptive を更新できるよう、バックフィルヘッドカウント活用 Issue を開きます。
2. Issue テンプレートの ‘Approval’ セクションに示されているように、セールスファイナンスとセールスコミッションチームの適切なメンバーにタグ付けします。

セールスファイナンス向け

1. 昇進/異動を考慮してチームメンバーの Adaptive のプロフィールを更新します。
2. チームメンバーが昇進/異動した空の役割をバックフィルする要請を開く必要があるかどうかについて、リーダーシップと People チームとパートナーシップを組みます。

セールスコミッション向け

1. 毎月、Workday で新規採用、昇進、異動を特定します。
2. ヘッドカウントの変更について Sales Strategy and Analytics チームに通知するための月次 Issue を作成します。Sales Strategy and Analytics チームは、従業員の採用/昇進/異動日から 4 週間以内に、セールス従業員にクォータ¹を割り当てます。
3. クォータはコミッションチームに提出され、すべてのコミッションが管理および監視される Xactly システムに追加されます。
4. 新しいセールスマネージャーに承認とチームメンバーへのリリースのために新しい報酬プランを発行します。

チームメンバー向け: 新しいマネージャーへの移行

GitLab には、昇進、ラテラル異動、会社の再編、マネージャーの辞職など、チームメンバーがマネージャーを変更する原因となるいくつかの状況があります。新しいマネージャーとの新しい関係を構築するプロセスは時に不確実になる可能性がありますが、この移行プロセスをスムーズに進めるためのリソースがあります:

• 1-1 の移行は、マネージャー移行の非常に重要な部分です。これにより、新しいマネージャーが重要な議論、成果物などについて最新の状態になり、この情報が移行で失われないことを確実にします。
• 組織変更チェックリスト引き継ぎテンプレートは、達成、強み、育成領域などが、今後すべて証拠とともに捕捉されることを確実にするのに役立ちます。これにより、キャリア開発の進捗が継続し、マネージャー変更で失われないようにします。
• 最新の 360 フィードバックレビューと最新のパフォーマンスレビューを新しいマネージャーと共有することは、強みと改善領域について整合し、両方を発展させるためにパートナーシップを組む方法を議論する素晴らしい方法でもあります。

マネージャー向け: チームメンバーをあなたのチームに移動

新しいチームメンバーがあなたのチームに移動するとき、上記の「新しいマネージャーへの移行」の項目に加えて、新しいマネージャーが考慮すべきいくつかの追加事項があります。

• 以前のマネージャーと新しいマネージャーの間で機密トピックの初期 機密引き継ぎ を行います (以前のマネージャー、新しいマネージャー、チームマネージャーとの 1-1-1 とは別)。
• この 機密引き継ぎ を定期的に (おそらく移行後 2 週、4 週、6 週) 行います。これにより、初期の質問と考慮事項だけでなく、新しいものが発生したときにも出てくることができます。
• この引き継ぎには、機密で 1-1-1 では議論されなかったタレントアセスメント計画のために必要な情報を含めます。
• 新しい直属の部下が次の 6 か月で昇進する可能性がある場合、以前のマネージャーからサポートする情報の引き継ぎを必ず行い、1-1-1 で議論された情報と 機密引き継ぎ で議論された機密情報の両方を含めて、これを推進する DRI になります。

チームメンバー向け: 役割変更後のタイトルの更新

新しいタイトル変更を反映するために、いくつかの場所でプロフィールを更新する必要があります。以下に限定されません:

• GitLab プロフィール
• GitLab チームページ
• Zoom プロフィール (Zoom web で更新)
• Slack プロフィール (Slack 内で更新)
• Gmail 署名 (Gmail 内で更新)、ガイドラインを参照
• 採用に参加する場合は、ガイドプロフィール
• ハンドブック: README と他の静的タイトルエントリ (存在する場合)。

フィールドチーム向け:

• 必要に応じて、名刺。
• GitLab コミュニティプラットフォーム: Forum、Discord
• 講演活動のための略歴/履歴書 (Sessionize など)
• ソーシャルメディアプラットフォーム (LinkedIn、X、Fediverse、Reddit など)

脚注

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