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 delievered 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.
For new department approvals and more detail on the process, please reach out on the #fpanda channel in Slack for desktop procedures.
GitLab's operating plan is a guideline to understand how much capital it needs and how the capital will be consumed. The operating plan helps GitLab answer questions like "how fast can we hire and when?" The operating plan consists of three main components: the revenue model, the rolling 4 quarter forecast and the budget. The operating plan can also be considered a bottom-up plan.
The revenue model predicts new business based on the growth persistence model and growth from existing business based on net retention assumptions. Understanding how much revenue is anticipated determines how much capital will be needed for growth in the foreseeable future.
The rolling 4 quarter forecast builds off of the revenue projected in the revenue model. During the rolling 4 quarter, departments build out plans to help meet their strategic goals. Understanding the departmental plans determines how much of the capital will be consumed for foreseeable future.
The budget looks to GitLab's long term profitiablity goals and incorporates plans made during the rolling 4 quarter forecast in addition to revenue forecasts from the revenue model. In order to have a budget, GitLab must have a forecast(s) for it's operating plan. Therefore, the revenue and rolling 4 quarter forecasts are critical to set budgets. Budgets help GitLab understand how it's spends its cash and help predict long term targets, but ultimately budgets are a guideline.
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 profitablity 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.
Our Plan is intended to ensure that the Company has sufficiently considered what is required to support the Company's financial goals. The Plan ensures that there is accountability across all divisions that can be measured. The Plan is not intended to represent a cap on what we can invest in support of maximizing the growth of the Company. We encourage our team members to actively seek opportunities that will help us grow faster. Those growth initiatives will be evaluated, as follows:
GitLab creates an annual Plan which establishes our financial objectives for the coming fiscal year and is used for measurement of the Company's ability to achieve goals. Things move quickly and our forecast needs to iterate quickly to keep up with the business. Accordingly, we run a rolling 4 quarter forecast process. This means that we are always looking out a minimum of 12 months when projecting revenue and expenses, and we update those forecasts at least once per quarter. 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 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.
Note: During the last quarter of the year, GitLab runs a 5 quarter forecast that aligns with it's annual planning efforts.
The Finance Business Partner for Sales & 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.
This is an interim process until report automation is complete. The desktop procedures are as follows:
Each month we send to our investors an update no later than the 10th day following the end of the month. For further reference see our blog post.
@mention e-group members with asks for topics related to the investor update agenda.1: Sales Metrics 2019 Monthly Metrics
2: Periscope
3: Metrics Report (SFDC)
4: All Pipeline Report (SFDC)
5: Late Stage Report (SFDC)
6: Orders Processed Report (SFDC)
7: Revenue Spreadsheet sent from Controller
8: Cash Flow Forecast (Accounting Will Send Over – typically within the 4th of the Month)
9: Pingdom
10: LTV for Metrics
11: BambooHR
12: Zendesk
13: Snowflake
14: Sales Pipeline Analysis
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.
In the event an organization is asking to spend money outside either the Annual Plan or Quarterly Forecast, you should develop a business case showcasing what the spend is for and how Gitlab can benefit from spending it.
This business case should be completed in conjunction with your Finance Business Partner (FBP) to articulate the financial impact of the request. Below are a few examples of the question you should be trying to answer:
Together with your FBP , this analysis should be presented to your leader for approval.
Each month after the financials have been published, GitLab reviews department spend data in detail. The goal of this analysis is to compare department budgets with actual results and examine any material discrepancies between budgeted and actual costs. These costs are reviewed at the divisional department level, allowing GitLab to measure progress in meeting its plan, forecast, and operating model. 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:
Following the month-end close, the Finance Business Partners will 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.
At GitLab, different measures of materiality thresholds are measured during the variance analysis process, including the Monthly Finance Planning Meeting. During the variance analysis processs 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 difference between the budget vs expected cost
The study of differences between budgetary and expected cost.
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 Periscope dashboard provides the data for the threshold analysis via a color coded legend.
The total is inclusive of all Revenue activities including subscription, professional services, swag shop and other revenue streams.
< 5% of plan OR < $0 is considered immaterial> 10% AND > $10,000 of plan is considered material5-10% OR $0 - $9,999 of plan is subject to judgement and reviewThe total is inclusive of all COGS activities including Customer Support, Professional Services, and other allocation expenses.
< 5% of plan OR < $0 is considered immaterial> 10% AND > $10,000 of plan is considered material5-10% OR $0 - $9,999 of plan is subject to judgement and reviewThe totals are exclusive of the sum of operating expenses. Each operating expense line item (i.e. Sales, Marketing, R&D, G&A) should be measured on a line item basis
< 5% of plan OR < $0 is considered immaterial> 10% AND > $10,000 of plan is considered material5-10% OR $0 - $9,999 of plan is subject to judgement and review< 5% of plan OR < $0 is considered immaterial> 10% AND > $10,000 of plan is considered material5-10% OR $0 - $9,999 of plan is subject to judgement and reviewWe follow the cadence below in our planning process:
Throughout the year the Executive Business Partner team 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.
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.[^3]
Our long term profitability target for EBITA (Earnings Before Interest Taxes and Amortization) is 20% of revenue. Our long term gross margin target is 85% but is dependent on the revenue mix between products - self managed and gitlab.com and professional services. Gross margin is defined as total revenue less cost of revenues as defined by GAAP and reported in the Company's financial statements. This analysis can be found on the Finance Dashboard. Other financial planning targets are described in the divisional area (e.g. sales, marketing, development, etc.) in this handbook. We plan to achieve our long term profitability target as our revenue growth rate approaches 30%. The long term target for operating expenses as a percentage of revenue for G&A is 10%.
| Division | Long Term Target |
|---|---|
| Cost of Sales | 10% of Revenue |
| R&D | 20% of Revenue |
| Marketing | 13% of Revenue |
| Sales | 23% of Revenue |
| G&A | 10% of Revenue |
| Total | 80% of Revenue |
| Division | FY20 Expense Target |
|---|---|
| Customer Support | 10% of ARR |
| Customer Solutions | 80% of PS Recognized Revenue |
| Engineering | 70% of IACV |
| Sales | 75% of IACV |
| Marketing | 45% of IACV |
| G&A | 10% of Total Operating Expense |
We don't use this at GitLab today.
The hypergrowth rule is a standard for measuring and thinking about profitability at any growth rate.
It's inspired, in part, by the Rule of 40, a SaaS rule of thumb for growth that Revenue Growth % + Free Cash Flow % = 40.
There is a high correlation between level of attainment of this combined metric and company valuation - although data suggests that current investor valuations models are more highly correlated with revenue growth rate.
We believe that strong correlation is a result of the importance of capturing market share. Using the Rule of 40 as an example, when Revenue growth is greater than 40%, there is an implication that negative profitability is encouraged, but this fails to answer key questions, such as:
The below hypergrowth rule can help answer the questions that the Rule of 40 doesn't answer:
Optimal % of revenue for a department = (((Revenue growth - Eventual Profit Margin) * Growth lever ) * model % ) + model %)
At GitLab, that means:
Optimal % of revenue for a department = (((Revenue growth - 20%) * 1.5 ) * model % ) + model %)
Our model target is our long term profitability target.
The growth lever is equal to 1 / (sum of target departmental % of revenue for departments that should be variable based on growth).
For GitLab, it is: 1 / (Sales + R&D + G&A + Marketing % of Rev), which would equal 1.25, but because cost of sales and hosting don’t increase with faster revenue growth, we can remove those (17%), and what's left is 1/(80%-17%) which ~ 1.5.
This makes the full formula for the growth lever: 1 / (Sales + R&D + G&A + Marketing % of Rev - Variable Non-Delayed Costs).
Below is an illustrative example, using the hypothetical case of revenue growth being 150%:
| Factor | Formula |
|---|---|
| Revenue growth | 150% |
| Revenue growth - 20% | 130% = 1.3 |
| (Revenue growth - 20%) * 1.5 | 1.3 * 1.5 = 1.95 |
| ((Revenue growth - 20%) * 1.5 ) * model % ) | 1.95*0.23=0.4485 |
| ((Revenue growth - 20%) * 1.5 ) * model % ) + model % | 0.4485+0.23=0.6785 |
| Optimal % of revenue for a department | 0.6785 = 67.85% |
Measures the number of days from Rolling Forecast Kickoff to Quarterly Board Meeting. The time period is quarterly. The target is 30 days.
Measures the team morale by using the tool Lead Honeslty. The time period is monthly, but will use a weekly average based on weekly 1:1s. The target is 9 on a scale from 1-10.
Measures the number of days from month end close to release variance analysis to business leaders. The target is five business days.
Measures the percentage deviation between the actual costs and the planned costs over the same time period. The time period may be monthly, quarterly, or yearly. The target deviation percentage is +/- 1.5%.
Percentage Deviation= (actual expenses-planned expenses)/planned expenses * 100
Position Description - Engineering Specific
Position Description - Sales Specific
Measures the days from Accounting Close to distrubtion of Budgets vs Actuals to Finance Business Partners. The time period is monthly. The target is 1 day after Accounting close.
Measures the days from 1st of month to release of the investor update. The time period is monthly. The target is 1 day after Accounting close. The target is 5 days from 1st of the month.
Measurements can be found under the Data Teams Performance Indicators
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, divison, 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.
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 specifc 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 it's 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 allocation cycle for GitLab's SaaS offering GitLab.com starts. The Finance Business Parter 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. The model can be found by searching My Drive > GitLab.com Model. The allocation for GitLab.com is broken out into two different methods.
These allocation breakouts will be documented in the GitLab.com model and will flow into the Post Allocation P&Ls. GitLab allocates these expenses to 3 Cost Centers
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.
If you create and/or update to a model that materially impacts it, please make sure to make a quick note of what you did in the ChangeLog. This is important because it keeps us on all the same page.
Note: At this time, GitLab use's the term Division to describe the makeup of its internal structure. In the future, the plan is to use the term Function to describe it's internal structure.
