Updates to exchange rate policy.

Why is this change being made?

The 3 major changes being made are:

1. Moving the exchange rate update date for FY25 to November 1 in order to provide the Compensation team sufficient time to complete budget modeling, secure approvals, and perform set-up/testing in Workday ahead of Annual Compensation Review launch.
2. Reducing currency conversion update from 2x per year to 1x per year to alleviate administrative complications and downstream impacts.
   1. The Sales Comp team has to administer new plans with each exchange rate update which takes considerable time and resources.
   2. Exchange rates are too volatile to predict and properly set aside budget to adjust team members into range during the mid-year update. This left some team members under range (due to the set up of the comp calc converting from USD to local) until we are able to address it during annual compensation review.
   3. In order to ensure a competitive range and competitive range placement for team members, it is important for this to occur as part of set up for an upcoming Annual Compensation Review cycle. Solely updating exchange rates doesn't address the other inputs to our ranges such as benchmarks and location factors.
3. Removing the policy to fluctuate pay for those not paid in local currency.
   1. Team members who opt in to be paid outside of their local currency do so in order to not experience the volatility of their local currency. Fluctuating salaries up and down during currency reviews created a volatile experience for team members and was counter to the goal of this program.
   2. This process was put on hold in the last few years due to extreme volatility during COVID and ongoing wars. This update is to formally remove the policy. For any team member who would have received a decrease as part of the reconciliation of this policy being put on pause will instead maintain their current salary.

Approved outside of GitLab.

Author and Reviewer Checklist

Please verify the check list and ensure to tick them off before the MR is merged.

• Provided a concise title for this Merge Request (MR)
• Added a description to this MR explaining the reasons for the proposed change, per say why, not just what
  • Copy/paste the Slack conversation to document it for later, or upload screenshots. Verify that no confidential data is added, and the content is SAFE
• Assign reviewers for this MR to the correct Directly Responsible Individual/s (DRI)
  • If the DRI for the page/s being updated isn’t immediately clear, then assign it to one of the people listed in the Maintained by section on the page being edited
  • If your manager does not have merge rights, please ask someone to merge it AFTER it has been approved by your manager in #mr-buddies
  • The when to get approval handbook section explains the workflow in more detail
• For transparency, share this MR with the audience that will be impacted.
  • Team: For changes that affect your direct team, share in your group Slack channel
  • Department: If the update affects your department, share the MR in your department Slack channel
  • Company: If the update affects all (or the majority of) GitLab team members, post an update in #whats-happening-at-gitlab linking to this MR
    • For high-priority company-wide announcements work with the internal communications team to post the update in #company-fyi and align on a plan to circulate in additional channels like the "While You Were Iterating" Newsletter

---