Purpose: Identify and agree on long-term investments and capabilities that will position GitLab for success over the long-term. Determine whether near-term priorities and funding need to change in order to achieve long-term goals and financial targets.
What: The Long Range Plan (LRP) is a three to five year strategic and financial plan:
Principles:
Governance: The LRP is reviewed and discussed by the board of directors every year.
What: The Street Model is a three statement excel model that we will use to guide Wall Street on a quarterly and annual basis.
Governance: Street model in the form of company guidance will be prepared by corporate finance, signed off on by CFO and eGroup. Reviewed by the Board of Directors.
Purpose: GitLab's Board Plan identifies GitLab's company goals for the next year and strategies for achieving them. Provide guidelines to understand how much capital is needed to achieve these goals.
What: The Board Plan includes the annual strategy, business Plans/budgets for each function, plans for how we will achieve our key metrics and forecasts for all of our key metrics. The Board Plan is a three statement (Income Statement, Balance Sheet and Statement of Cashflow), non-GAAP bottoms-up plan that spans the current fiscal year. The revenue is forecast off 90% confidence bookings plan and expenses are planned at the headcount and vendor level. The Board Plan is a 90% confidence Plan and expenses for R&D and G&A are based on the revenue in the Plan. Expenses for sales are based on capacity to achieve Company Target (below).
Governance: The Board Plan is approved by the board of directors every year.
Purpose: Build a go-to-market business plan to achieve the company's tops-down target.
What: This is the plan with Targets for bookings and revenue at a 50% confidence level with supporting marketing and sales inputs. We will build enough sales and marketing capacity to achieve this goal and will measure operational success internally against these Targets.
What: Actuals are results that have been reported or exist in a system that is designated as a single source of truth for the item that is being measured. Each month accounting closes the month and financial results are recorded in our ERP system and are published in our financial statements. These actuals are compared to the Board Plan, Target and our forecasts.
Purpose: In a dynamic high-growth business, GitLab's needs may change through the year and we need to be able to predict what is going to happen.
What: Forecast is a dynamic assessment based on current expectations of financial performance. The FP&A team will publish a monthly forecast for revenue driven by bookings and expenses driven by headcount and vendors. A monthly forecast does not extend the forecast period. For example in March 2020, the forecast will span from February 2020 to January 2021 with February actuals and March 2020 to January 2021 forecast - this will be called the (1+11) forecast. A monthly forecast will not be formally compared to actuals in variance.
Governance: The monthly forecast is approved by VP Finance and reviewed with CFO.
Purpose: In a dynamic high-growth business, GitLab's needs may change through the year and we need a guidepost to hold business leaders accountable. We plan our expenses at a high level (e-group) and we expect this group to make prioritizations and trade-offs while remaining accountable against the plan parameters. By formally reforecasting quarterly, we can quickly evaluate and incorporate new initiatives into our forecasting model. That being said, we do follow an annual plan to set our goals and measurement for our top-level targets of revenue, profitability and expense management.
What: Forecast is a dynamic assessment based on current expectations of financial performance. The (3+9), (6+6) an (9+3) quarterly forecasts include revenue driven by key metrics and expenses driven by headcount and vendors. On the quarterly forecast another quarter will be added to the end of the forecast period so that we have a valid rolling four quarters. For example in May of 2020 we will forecast from Feb 2020 to April 2021 adding FY22-Q1 with FY21-Q1 (Feb 2020-Apr 2020) as actuals. The team may go out farther to the end of the next fiscal year.
Governance: The quarterly rolling forecast is approved by the eGroup and CEO and reviewed with the board of directors. eGroup will be held accountable to the quarterly rolling forecast for expenses. For revenue the company will always be held accountable to Plan.
GitLab’s FP&A team participates in a rigorous monthly close process. The close process has clear deadlines to best support our accounting team, key dates to deliver information to the EVPs / department heads, analyze the performance of our budgets and forecasts against actuals, update our internal forecasts and eventually update our investor guidance to prepare for the quarterly earnings call. Our philosophy is to compare our forecasts to results so that we can constantly improve our forecasting methodologies and approaches to hold ourselves accountable. Additionally, this process drives accountability to the business owners of the budget.
These dates are based on a 10 day accounting close. FP&A needs three BDs to publish variance analysis post-close and another day to lock rolling forecasts and complete guidance analysis.
BD=Business Day, so for example BD4 means four business days after the month has ended. Let’s say the month ended on a Thursday. BD1 would be Friday, BD2 would be Monday, etc.
Bold denotes Accounting deliverable
4 weeks before earnings call
3 weeks before earnings call
2 weeks before earnings call
1 week before earnings call
Step 1: Run all forecasts for bookings
Step 2: Review key metrics trends and reforecast
Step 3: Analyze revenue
Step 4: Analyze expense profile and EBIT
Step 5: Generate guidance proposal, ranges and waterfalls
The CFO will review the guidance with the CEO and CRO at the monthly revenue committee sync meeting. The CFO will make sure the meeting is scheduled at the correct time to review the guidance.
Each month after the financials have been published, GitLab reviews all aspects of the business including Corporate Metrics, Bookings, Revenue, Gross Margins, Expenses, and Cash Flow. The goal of this review is to do a comprehensive review so that finance leadership has a pulse on the business and the financials. Based on insights from variance analysis, the FP&A team makes actionable recommendations to the CFO and eGroup to ensure continued performance to Plan/Target.
The variance analysis will compare department budgets with actual results and examine any material differences between budgeted and actual costs. Additionally, the actuals for expenses will be compared to the quarterly rolling forecast. The expenses are reviewed at the divisional department level, allowing GitLab to measure progress in meeting its Plan (Q1-Q4) or rolling forecast (Q2-Q1). The team also evaluates the accuracy of forecasts, and operating model.
The study of differences between budgetary and expected cost. At GitLab, different measures of materiality thresholds are measured during the variance analysis process, including the Monthly Finance Planning Meeting. During the variance analysis processes the GitLab FP&A team analyzes and isolates any variance in question to the lowest level possible. The team reviews detailed items in order to identify the root cause of the variance. This could include transaction date, cost center, vendor, location, department or additional low level details.
At GitLab, analysts begin the variance analysis process with trended data to understand if there is a recognizable pattern. This helps determine if the variance was caused by incremental change or driven by one particular event and helps identify the root path quickly.
The FP&A team takes the following into consideration while evaluating variances in relation to materiality thresholds:
The FP&A team delivers an FP&A expense flux review document at each monthly close, documenting and quantifying business drivers for variance. The goal is two-fold:
We measure our team performance based on our forecast accuracy, also known as variance percentage. Variance percentage is defined as the difference between actuals and Plan or rolling forecast. We calculate it as follows:
Variance Percentage (Plan) = (Actuals - Plan)/Plan or
Variance Percentage (Forecast) = (Actuals - Rolling Forecast)/Rolling Forecast
Our goal is to have revenue and EBIT variance percentage within +/- 2% on a quarterly basis.
Generally accepted accounting principles (GAAP) does not provide definitive guidance in distinguishing material information from immaterial information. Therefore, GitLab uses a percentage based approach for defining materiality thresholds and can be found below. The Plan vs Actuals vs Forecast Sisense dashboard provides the data for the threshold analysis via a color coded legend.
We believe that Revenue & EBIT actuals that have a greater variance of +/- 5% vs Plan or Forecast is considered material.
Each finance business partner will run a meeting with the VP of Finance and the EVP to review the past month. The information should be presented as timely as possible. Given the accounting close is 10 days, the team is asked to use pre-close numbers for the review to increase the speed of information. During the meeting, the Finance Business Partners will review GitLab results in addition to a detailed overview. Each division can expect to review the following during the monthly meetings:
Process Following the month-end close, the Finance Business Partners will create a variance deck and distribute department income statements to the related budget owners and the e-group members. Each department is then responsible for comparing these reports, which contain actual costs, to the budget. Departments, with guidance from the Finance Business Partners, should analyze their data and if necessary, discuss items of interest and take appropriate action. Any questions regarding the cost data should be discussed with the Finance Business Partner.
In partnership with Marketing Operations and Accounting, we set out to improve the timing and accuracy of budget vs. actuals tracking for marketing programs opex and to provide data driven insights to these teams during the close process by BD3 at the beginning of a new monthly accounting period.
The utilization of campaign finance tagging for marketing program spend enables month-end reconciliation of expense actuals, prepaids, and accruals at the budget line item level. The components of this analysis are as follows:
Once these components are in place, a comparison showing the difference between budget vs. actuals may indicate the need for an accrual or indicate a budget overage. The finance business partner can then take appropriate action with the accounting team or the business to resolve. The basic structure of this analysis should resemble the following:
| Campaign Finance Tag | A: Expense | B: Prepaid (GL Acct# 1150) | C: Total (A+B) | D: Budget line item | E: Variance (D-C = Potential Accrual/Overage) |
|---|---|---|---|---|---|
| ISOdate_CampaignShortName | $000's | $000's | $000's | $000's | $000's |
As part of the variance and monthly review process we will evaluate two types of investments: ROI positive investments: There are an array of reasons we would want to invest in additional resources - here are some examples and eGroup will generate a full list:
Business Plan drivers to review quarterly:
eGroup will generate a full list of the top items that were not funded in the Plan / would we would want to be gated.
Scenarios that we could be in and will be discussed every month:
ARR Plan refers to board Plan in which the expense Plan was built.
| Scenario | Action to be taken |
|---|---|
| Behind ARR Plan based on actuals and forecasted pipeline. | Need to slow hiring and control expense on non-revenue generating heads. Potentially redirect dollars to specific areas in sales and marketing to correct the course watching CAC. Decision will be made by eGroup. |
| On ARR Plan and expense Plan based on actuals and forecasted pipeline. | Need to evaluate ROI positive initiatives against existing spend and reprioritize dollars. For example Alliance is doing really well but we are not ahead of Plan - we would want to invest more in Alliance but need to fund from somewhere else. Decision will be made by eGroup. |
| On ARR Plan and spending less than Expense Plan based on actuals and forecasted pipeline. | Identify and isolate the expense difference. We analyze the impact to our key metrics and collectively as an eGroup evaluate whether we reallocate the dollars. |
| Ahead of ARR Plan (and either spending at or less than expense Plan) based on actuals and forecasted pipeline. | Identify and isolate the expense difference. We analyze the impact to our key metrics and FY23 and collectively as an eGroup evaluate whether we reallocate the dollars. |
| Trending ahead of ARR Target and have confidence we will sustain based on actuals and forecasted pipeline. | Review FY23 impact and decide as an eGroup where to invest ahead of FY23 |
When we are on track to exceed our bookings target, we can consider off-cycle budget approvals. This will help to accomplish the following:
Please note these process details:
Throughout the year the Executive Business Administrator to the CEO puts together a calendar of events for board members and other events associated with planning. Those events can be found in the GitLab Board Calendar sheet.
Below is a table showing the structure of GitLab departments as they exist in NetSuite. Please check out the Team Page to see our org chart.
| Cost of Sales | Sales | Marketing | R&D | G&A | GitLab.com |
|---|---|---|---|---|---|
| Education Delivery | Business Development | Content Marketing | Product Strategy | Business Operations | |
| Consulting Delivery | Channel | Sales Development | Infrastructure | CEO | |
| Customer Support | Commerical Sales | Field Marketing | Development | Finance | |
| Practice Management | Partner Marketing | Quality | People Success | ||
| Customer Success | Strategic Marketing | Security | Talent Acquisition | ||
| Enterprise Sales | Brand & Digital Design | UX | Legal | ||
| Field Operations | Marketing Ops | Product Management | Accounting | ||
| Inbound Marketing | |||||
| Campaigns | |||||
| Digital Marketing | |||||
| Owned Events | |||||
| Sponsored Events | |||||
| Community Relations | |||||
| Communications | |||||
| Awareness |
| Sales | Marketing | Engineering | Product | G&A |
|---|---|---|---|---|
| Business Development | Content Marketing | Customer Support | Product Strategy | Business Operations |
| Channel | Sales Development | Infrastructure | Product Management | CEO |
| Commerical Sales | Field Marketing | Development | Finance | |
| Practice Management | Partner Marketing | Quality | People Success | |
| Customer Success | Strategic Marketing | Security | Talent Acquisition | |
| Enterprise Sales | Brand & Digital Design | UX | Legal | |
| Field Operations | Marketing Ops | Accounting | ||
| Education Delivery | Inbound Marketing | |||
| Consulting Delivery | Campaigns | |||
| Digital Marketing | ||||
| Owned Events | ||||
| Sponsored Events | ||||
| Community Relations | ||||
| Communications | ||||
| Awareness |
GitLab provides our investors updated information on the state of the business on a quarterly basis. The update includes highlights,lowlights, and what we're focusing on for the next quarter.
GitLab uses several different methods to budget specific revenue and expenses. During the Rolling 4 Quarter Forecast planning process GitLab may use one of the following methods to allocate revenue or expenses.
Recording activities based on the percentages across a certain time period. This can either be on a percentage spread or an amount spread
Recording activities based on a one time basis across a certain time period. These activities are geared toward, but not limited to, marketing expenses.
Recording activities based on headcount growth across a certain time period.
The Finance team is the owner of the GitLab Hiring Plan (GHP), which is the SSOT for GitLab’s hiring plan for the future rolling 12 months. The GHP is a live document that is maintained by the Finance Business Partners (FBPs) and contains the current hiring plan that is used in the GitLab Financial Model. We have a SSOT to ensure there is one place hiring managers, finance, and talent acquisition go to see what hiring is included in the forecast and is eligible to be opened up in Greenhouse. This increases our predictability as a company and streamlines the hiring process.
When you are ready to open a new vacancy reach out to your Recruiter. They will open a GitLab issue or communicate directly with your FBP to get a GitLab Hiring Plan ID (GHP ID.) While GitLab strongly believes that you should be able to backfill a role when someone departs, please check with your eGroup member before reaching out to Talent Acquisition for all backfill positions.
Each role has a unique GHP ID number listed, which is part of the information you need to provide to the Talent Acquisition Manager or Lead for your department to have the position opened in Greenhouse. If there is no GHP ID, the job will not be opened in Greenhouse.
If you are looking to pull forward a headcount and are in the Sales division please follow this process. Due to the territory alignment related to Sales headcount, please also reach out to the Sales Strategy & Analytics team before reaching out to your Finance Business Partner.
When a hiring manager comes to you to open a role please work with the appropriate FBP to get a GHP ID. This process is unique to each division.
On a weekly basis FBPs will update their department’s hiring forecasts in Adaptive. FBPs may update their headcount forecast on a more frequent basis depending on their individual department’s business needs, but at a minimum it must be done on a weekly basis. This could require adding new roles, deleting roles, trading out roles, or adding backfills. Every vacancy requires a GHP ID once it is ready to be opened in GreenHouse. A vacancy could be for a net new hire, a backfill due to leaving the company or a backfill due to internal movement.
To determine what GHP ID to use the FBP references the appropriate GHP ID numbering for their department. The numbering for the GHP IDs are similar to a credit card. The first two digits of the unique GHP ID represent the FBP’s division, the next two numbers represent the department. Then there are seven digits that start with 0000001 that sequentially grow from there for every role.
Once a number has been used in Greenhouse for a job, it can not be reused. If the role is a future role and has been deleted, but was never input into Greenhouse, the FBP can use that number for it’s replacement or a different role since it was not used yet.
When a job is opened in Greenhouse it is routed for approvals. The second required approval is from Finance. This allows the FBPs another opportunity to check the GHP ID on open jobs and ensure everything reconciles. If something does not reconcile to what is in the forecast, the FBP will reach out to the hiring manager to discuss. Ideally conversations with hiring managers and leaders will occur when the initial request for a GHP ID occurs from Talent Acquisition. But if the conversations do not occur then, they will occur at this time to ensure that everyone is in agreement and that if tradeoffs need to be made for financial reasons, they can be made then.
Finance is also a required approval on all job offers. This allows Finance to see the financial details of the job offer before any offer is sent, so that they are enabled to have conversations with their leaders about implications to their Plan if needed.
The primary mechanism to ensure efficient spend of company assets is the Procure to Pay process, and specifically completion of the vendor and contract approval workflow prior to authorization. The procurement team or your finance business partner can assist with questions related to this process.
The second mechanism is the budget vs actual review to determine reasons for variances vs plan.
The Finance Business Partner for Marketing will review transactions within the general ledger accounts for marketing program expense (6100’s) on a weekly basis to ensure that campaign tags are present. An exception report will be delivered to the Marketing Operations team either validating that all tags are present, or pointing out those transactions where the tag is missing. Marketing Operations will then work with the Marketing team to add back the missing tags.
A live dashboard to assist in identifying these transactions can be found in Sisense, but it is not linked here due to the sensitive nature of this data. The weekly desktop procedures for this process are as follows:
GitLab maintains a financial model and communicates high level financials five years out.
GitLab's integrated financial model is synonymous to its operating plan, but the integrated financial model is based soley on business drivers. The integrated financial model dynamcially answers questions like “What are our limits in comparison to the total addressable market?” and provides "What-if" scenarios. The integrated financial model also helps set the long term profitability goals. GitLab has established business drivers in each function of the business and continues to refine them to ensure its tracking accordingly. The integrated financial model can also be considered a top-down plan.
Scale Venture Partners developed a Growth Persistence Model based on research on private and public software companies. The Persistence Model shows that ARR growth rates typically decline year over year, with each year’s growth being, on average 85% to that of the preceding year. We use this methodology to set our growth targets.
At GitLab, planning starts with long term goals. GitLab uses business drivers to forecast out long term goals by division. By using division specific business drivers that tie into the long term goals, GitLab is able to quickly and dynamically shift priorities based on external or internal changes.
Business drivers are the key inputs and activities that drive the operational and financial results of a business. Business Drivers cited by CFI
| Division | Long Term Target |
|---|---|
| Cost of Sales | 15% of Revenue |
| R&D | 20% of Revenue |
| Marketing | 12.5% of Revenue |
| Sales | 22.5% of Revenue |
| G&A | 10% of Revenue |
| Total | 80% of Revenue |
Successfully creating new departments require that various company systems be updated to capture newly defined department structures. Once the need for a new department arises, follow these steps:
Below is a table showing the structure of GitLab departments as they exist in BambooHR and netsuite. Please check out the Team Page to see our org chart.
At GitLab, the lowest level of tracking reporting structure starts with departments. For reporting and accounting purposes, departments are assigned both a cost center and a division. In certain cases, a department may span multiple cost centers based on GitLab's allocation methodology.
The cost center, division, and department reporting structure can be found in the Data Team repo located below. In efforts to keep a single source of truth for organizational and reporting purposes, the Data Team maintains any changes implemented by the FP&A team as a result of an organizational change.
A grouping of departments within GitLab to which costs may be charged for accounting purposes.
A grouping of departments in which specific activities are carried out within GitLab. Aligning specific departments to divisions ensure the proper operations and efficiency for supporting and creating value for GitLab's customers.
An area of special expertise or responsibility within a GitLab division.
We produce all our forecasts and plan within Adaptive Insights. To see more details, see here
GitLab allocates cost items based on consumption of resources or headcount. Below are the workflow and diagrams that illustrate how various cost items are allocated:
The grid highlighted as Pre-Allocation P&Ls in the diagram below highlights what GitLab P&L structure would look like if there were no allocation methodology. The grid represents Cost Centers and Departments that fall within those Cost Centers. In order to support different dimensional P&Ls and ensure expenses are flowing to the proper Cost Center, GitLab applies an allocation methodology. Therefore, the Pre-Allocation P&Ls is meant to provide clarity and be a starting point to the allocation methodology process.
The grid highlighted as Allocation Methodology in the diagram below highlights the specific processes that occur in order to achieve proper expense allocations to their respective Cost Centers.
The allocation methodology is applied to the G&A Company Allocation department. Items that are recorded to the G&A Company Allocation department are software expenses and one off expenses. The software expenses are for software used by the entire company (examples include gmail and slack). At times one off expenses are also recorded to the G&A Company Allocation department (examples include Contribute, payroll service fees, etc).
While credit card processing fees are not allocated company wide, it is important to call out the distinction of applying credit card processing fees to Sales. GitLab does not consider credit card processing a cost to its product or service. GitLab believes that its credit card processing fees are more appropriately classified as marketing and selling expense because these fees are related to the cash collection process for completing customer orders, which supports sales and marketing classification.
Note: One thing to note during the Yellow Process is the Infrastructure expenses are removed. Infrastructure is allocated during the next phase of the allocation cycle. Therefore no shared expenses will hit the Infrastructure P&L.
The Finance Business Partner owns gross margin and is responsible for developing and maintaining the allocation methodology for GitLab’s SaaS offering, GitLab.com. The Finance Business Partner for R&D maintains an allocation model to provide Accounting with an allocation breakout of expenses as well as a P&L based on allocation. Our allocation policy is to align the expenses with 1) revenue for paying users and place in Cost of Revenue on our P&L, 2) internal usage and consumption for Research &Development, and 3) free user usage for Sales & Marketing. The GitLab.com Model can be broken out into three different sections Customer Support, Hosting Expense, and Infrastructure outlined below:
Customer Support is only available to paid users in our product entitlements, however in some circumstances are required to support free users. The allocation should align customer support costs to the tiers receiving the services. The metric used to allocate the expense is Ticket Time to Resolution by Tier. This data is sourced directly from Zendesk and represents the total time spent on tickets closed within the month. In Zendesk, at the time of ticket submission, each support ticket is tagged based on the customer’s subscription level. This data is reviewed on a monthly basis by the support team to ensure it’s accuracy.
It is possible that a support ticket may be tagged to a free user. There are three reasons for this: 1) Free users, who are not entitled to support, submit a ticket 2) a free user requires SaaS administrative support 3) the customer’s subscription has expired and needs help with renewal or licensing. While the third scenario the user is tagged free, all tickets associated with licensing and renewals are reallocated out to the paid tiers.
The first part of the Hosting Expense allocation is Rackspace/GCP costs, representing the majority of total hosting costs. GCP Costs are made up of the following drivers: object storage, repo storage, CI Compute, Other Compute, Networking, and Discounts. These costs are mapped according to the SKU descriptions, updated monthly.
Object Storage
Object Storage is primarily used for container registry, artifacts, and uploads and is mapped, by tier, using both count of namespaces and Gigabytes (GBs) usage on a monthly basis. GBs usage, total object storage costs are the usage drivers that are used to allocate the costs to paid, free, and internal users.
Repo Storage
Repo storage is used for project, snippet, and wiki storage and is mapped, by tier, using both count of namespaces and Gigabytes (Gbs) usage on a monthly basis. Gbs usage is the driver that is used to allocate costs to paid, free, and internal users.
CI Compute
The CI project within GCP is used for runner-management and all other individual runner jobs. These costs are mapped, by tier, using both count of namespaces and minutes used on a monthly basis. Count of CI minutes consumed,is the driver used to allocate cost to paid, free, and internal users.
Other Compute & Networking
We currently do not have any metrics to track monthly usage for other compute costs and networking. Costs are allocated based on the cost allocation of object storage.
Data
Data is obtained from the GCP billing portal and mapped by SKU into the cost categories (link to mapping tab). The mapping is reviewed and updated on a monthly basis. For redundancy, the data is also downloaded directly from GCP using BigQuery.
GCP Discounts
Once the allocations are complete. Sustained Use, Committed Use, and Spending Based Discounts are allocated proportionally based on the allocations completed.
Other Vendor Allocations
There are two types of ElasticSearch costs: logging and search clusters. The search functionality is available only to paying customers so this is 100% allocated to Cost of Revenue. Logging is treated as a marketing expense as we are gathering data to better serve customers, it is allocated to free users.
For all other vendors, allocations are based on the following criteria:
Internal: Based on the proportion of GitLab headcount compared to gitlab.com Monthly Active Users
Paid: Based on total paid users compared to total gitlab.com Monthly Active Users
Free: Based on total free users compared to total gitlab.com Monthly Active Users
The Infrastructure teams costs are allocated according to the final hosting expenses allocation. Using the internal, free, and paid percentage allocation from hosting, the infrastructure team costs are allocated at the same weighting.
GitLab.com COGS Allocation = (Paid Tier Hosting Usage (%) _ Total Invoiced Hosting Costs) + (Paid Tier Hosting Usage (%) _ Infrastructure Team Costs) + (Paid Tier Ticket Resolution Time (%) * Total Support Team Costs)
GitLab.com Free User Allocation = (Free Tier Hosting Usage (%) _ Total Invoiced Hosting Costs) + (Free Tier Hosting Usage (%) _ Infrastructure Team Costs) + (Free Tier Ticket Resolution Time (%) * Total Support Team Costs)
GitLab.com Internal User Allocation = (Internal Tier Hosting Usage (%) _ Total Invoiced Hosting Costs) + (Internal Tier Hosting Usage (%) _ Infrastructure Team Costs)
The Blue Process, which encapsulates the Yellow and Red process, is meant to bring the full allocation cycle together before the Post Allocation P&Ls are rendered.
The grid highlighted as Pre-Allocation P&Ls in the diagram below highlights the final process during the allocation cycle. As a result, new P&Ls are generated to show the breakout of the Infrastructure team across Cost Centers as well as GitLab.com.
Issues the FP&A team works on have the ~"FP&A" label. This applies to both the Finance and Analytics Issue Trackers. This will ensure that expectations are set accordingly and the work gets delivered in a timely and professional way.
The Analytics part of the FP&A team focuses on delivering project based works and at times will assist with ad-hoc analysis.
Since we are a remote company, we utilize a Slack plugin called Geekbot to coordinate various status updates. There is currently 1 status update configured in Geekbot:
The Weekly Status Update is configured to run at noon on Fridays, and contains three questions:
What progress was made on your deliverables this week? (MRs and Closed Issues are good for this)
The goal with this question is to show off the work you did.
What do you plan to work on next week? (think about what you'll be able to merge or close by the end of the week)
Think about what the next most important thing is to work on, and think about what part of that you can accomplish in one week. If your priorities aren't clear, talk to your manager.
Who will you need help from to accomplish your plan for next week? (tag specific individuals so they know ahead of time)
This helps to ensure that the others on the team know you'll need their help and will surface any issues earlier.
The FP&A Team holds a quarterly planning retrospective to discuss what went well and what didn't go well. The team will take action items away from the Retrospective to improve the planning process and overall efficiency at GitLab.
The FP&A Team uses GitLab's Engineering methodology to hold the Retrospectives, which are detailed on the Team Retrospectives page.
Note: During the last quarter of the year, GitLab runs a 5 quarter forecast that aligns with its annual planning efforts.
