Constantly look for opportunities to improve performance
Process Improvements
Analytics
Education
GitLab's Operating Plan vs Integrated Financial Model
Operating Plan
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 bottoms 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.
Integrated Financial Model
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 tops down plan.
Operating Plan
Forecasting Growth Using a Growth Persistence Model
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.
Operating Plan Diagram
Planning @ GitLab
Making Changes to the Plan to Optimize for Growth
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:
If the investment will allow us to exceed our IACV plan by at least an equal amount in the current year we will do it. The e-group will be informed of the increased spend and anticipated impact.
If the increased spend will allow us to exceed our IACV targets next year then we will quantify the impact and raise our financial guidance for the following year. The e-group will review these investments and will, in some cases, request board approval for relief against current year planning targets.
If we need to exceed spend to achieve our current plan we should review as an e-group and inform the board. We won't necessarily get plan relief unless there are extenuating circumstances but we will do what is right for the business.
Rolling 4 Quarter Forecast
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.
Tips - Rolling 4 Quarter Forecast
Meeting each department and function leader prior to the planning cycle is a must and useful for building long term relationships. Set up a coffee chat to do an informal intro.
Having a Rolling 4 Quarter Forecast kickoff helps everyone know that the planning cycle is about to begin.
This should generally occur 3-4 weeks out before the planning cycle starts and should be communicated through as many channels as possible (Slack, Team Calls, Company Call, etc)
Scheduling invites 3-4 weeks out with department and function leaders around the same time as the kickoff is important. This helps get on everyone's calendar and ensure topics are not rushed
Having a templated calendar invite helps save time. There will be multiple folks involved in the process, broken out by each function.
It also helps if the Rolling 4 Quarter Forecast models are up to date prior to meeting. This would include the current team, planned hires, and program spend so leaders have a clear guide during the meeting. It won't be perfect and will inevitablty change during or shortly after the meetings, but this is an efficient way to make the meetings productive.
Meeting with the function leads after the department leads help tie everything together. However, if possible, it can be beneficial to meet with the function leads before and after to ensure buy in and close any gaps.
When applicable, it is important to always include the function operation leads to the meetings so they can help faciliate any work or changes during or after the meetings.
Continously gather feedback from stakeholders on what can be done more efficient
Planning is a team sport. It requires effort and communication on all sides to make it work well. Build the relationships, be patient, and be humble as some folks have less experience with planning while others have a lot of experience.
Note: During the last quarter of the year, GitLab runs a 5 quarter forecast that aligns with it's annual planning efforts.
Monthly Investor Update
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.
Format
Thanks
Asks
Key Metrics
Lowlights
Highlights
Expectations (next month)
Process
On the 1st day of the month, the FinOps lead prepares a draft of the previous months investor update in a google document and posts in the #investor-update slack channel.
On the same day the draft is added to the #investor update slack channel, the FinOps lead will @mention e-group members with asks for topics related to the investor update agenda.
The e-group members will have no later than the 9th of each month to review and add input.
No later than the 10th of each month the will CEO send the update to the investor mailing list.
Once the investor update is sent to the investor mailing list, the FinOps lead will add the current investor update to the #investor-update slack channel, along with highlight commentary on GitLab's operating metrics.
Relevant Locations for Investor Update Process
Revenue Model & Metrics Tab within the Financial Model
Expiring Subscriptions gets updated once every 3 months
Won Renewal ACV → Renewal ACV (Line 8 Revenue Model)
Lost Renewals ACV + Growth Downgrade IACV + Growth Refund IACV + New Refund IACV + New Downgrade IACV → Lost Renewals, Credits, Downgrades (Line 11 Revenue Model)
Update new month with % of Lost Renewals, Credits, Downgrades
TCV –> filter out Professional Services, sum all relevant information, & in Revenue Model paste number in Line 34 for TCV
Double check to see if Revenue model Net IACV = Net IACV in Sales Metrics Sheet
Note: ACV on Sales Metrics Sheet will not equal ACV on Revenue Model because of Professional Services in the Sales Metrics Sheet
2: Periscope
Exit ARR –> Filter data by current MRR month & then sum using (=subtotal(109, ARR column))
Retention
Licensed Users –> Make sure EDU & OSS are excluded
Active Self Core Hosts
Customer Count By ARR
3: Metrics Report (SFDC)
Gives an overview of what happened within the stated month
4: All Pipeline Report (SFDC)
Relevant number is the Grand Total Sum
Make sure the month is correct
5: Late Stage Report (SFDC)
Relevant number is the Grand Total Sum
Make sure the month is correct
6: Orders Processed Report (SFDC)
Ensure that closed deals are updated for the month (Bottom of Funnel Forecast Line 56 - 64)
7: Revenue Spreadsheet sent from Controller
Non-GAAP Revenue -> Pull grand total and input into Line 29 in Revenue Model
8: Cash Flow Forecast (Accounting Will Send Over – typically within the 4th of the Month)
Step 1: Find Ending Balance for Latest Month (Line 60)
Step 2: Add to Financial Model Balance Sheet
9: Pingdom
GitLab.com Availability, Response Time
10: LTV for Metrics
LTV with DCF Tab (Line 116)
Go back to the Metrics Tab (Current Month and 2 Months Prior – get the average)
Put that average number * .90 (GM) in Line 116
Pull LTV number into Line 123 & input into Financial Model
11: BambooHR
To get updated team members number – check Income Statement Monthly
If not updated within IS Monthly, go to BambooHR and pull actuals –> Put new numbers into IS Monthly (Lines 47 - 51)
12: Zendesk
Step 1: Reporting –> Insights
Step 2: Corp Dash - OKR Overview should have the relevant information for Customer Support
Put them in the metrics tab (Line 8,9,& 10)
13: Snowflake
Get GitLab.com Licensed Users –> Filter down by product category (Bronze, Silver, & Gold) –> Get grandtotal of each category and overall
Additionally, Add Revenue for each Product in the GitLab.com Model –> Information comes from Revenue spreadsheet listed above (Number 7)
14: Sales Pipeline Analysis
Model is being updated & TBD
Once Metrics & Financial Model Are Completed for Investor Update Process
Add relevant numbers to the GitLab.com & GitLab Allocation Model
Copy All of Metrics Tab in the Financial Model & Paste it in Static Metrics Sheet
Note: Remember to remove forecast, format new month to actual (from orange to light blue), copy/paste hyperlinks for names within static sheet, & anything in the previous month that was italicized needs to be back to normal.
Budgeting @ GitLab
Out of Budget Business Case
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:
What is the purpose of the spend?
How much is the spend?
What kind of spend is it? (One time, contract, utility-based, etc..)
What is the Return on Investment?
If the ROI cant be measured what KPI are we trying to move?
Can we measure the impact in terms of ROI or KPI improvement?
Have we investigated any other options?
Together with your FBP , this analysis should be presented to your leader for approval.
Monthly Finance Planning Meeting
Purpose
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:
Company results
Bookings IACV, TCV
Spending OpEx vs Plan
Divisional level review
Last month and last fiscal quarter (once per quarter)
Department level review
Last month and last fiscal quarter (once per quarter)
Review next 4 quarters vs Plan for the Division and for each department
Process
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 Buisness Partner.
Timing
The Accounting Manager will send the income statements on or before the 15th of each month.
The Finance Business Parters will prepare a templated budget vs actual reporting package for distribution to the divisional and departmental leaders.
With guidance from the Finance Business Partners, each division and department leader will review the budget vs actuals in the same month.
Expense Controls and Improving Efficiency
The primary mechanism to ensure efficient spend of company assets is the approval process prior to authorization. See Signature Authorization Matrix.
The second mechanism is the budget vs actual review to determine reasons for variances vs Plan.
Calendar of Events
We 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.
Monthly Update
Hold Departmental Metrics Meetings to review how well the departments are operating.
Send out Investors Update
Update our Budget vs Actual model with revenue, expense and headcount actuals.
Perform an actuals vs budget/forecast variance analysis.
Distribute monthly results to budget owners.
Monthly Important Dates
10th of the Month - Update Metrics Report
10th of the Month - Update Revenue Model
10th of the Month - Send out Investors Update
15th of the Month - Update Financial Models
15th of the Month - Distribute monthly results to budget owners
Quarterly Forecast
All of the activities in the Monthly Forecast.
Budget owners update headcount planning templates and non-headcount expenses.
Revenue model updated and signed off by CMO and CRO.
Quarterly Important Dates
14th of the Last Month in Fiscal Quarter - Send out calender invites to review non-headcount & headcount expenses
22th of the Last Month in Fiscal Quarter - Finalize non-headcount & headcount planning with departments
22th of the Month - Finalize Revenue Model signoff from CMO and CRO
Annual Plan
All of activities above.
Revise and update the annual sales compensation plan.
Set annual quota assignments for revenue producing roles.
Review product investments vs expected revenue generation.
Set expected amount for annual compensation increases.
Set targets for any contributors on a company based performance plan.
Set company targets for board, investors and creditors.
Our Annual Plan is viewable internally as a google slide presentation. Search on "[current year e.g. 2018] Plan" to view.
Annual Planning Important Dates
14th of September - Sales Compensation Direction
15th of September - Four quarter rolling forecast kick-off
30th of September - Four quarter rolling forecast completed
1st of November - Preliminary outlook reviewed at Board of Directors
6th of November - Plan iteration and discussion at egroup offsite in Sonoma
30th of November - Product Roadmap and Investments (board review)
6th of December - Sales Ramp and Compensation (board review)
13th of December - Marketing and Demand Generation (board review)
5th of January - Sales compensation plans distributed to sales team
25th of January - Plan sent to Board for Approval
31st of January - 20xx Plan Approved by Board
Terminology
Plan is the term we used for the current plan of record which has been approved by the Board. Typically this is set at the beginning of the year.
Forecast is a dynamic assessment based on current expectations of financial performance.
Target is a goal or objective that may be higher or lower than the Plan or Forecast. Targets are typically used in conjunction with setting OKRs, compensation plans or other performance objectives.
Baseline is a measurement of actual expense or revenue that relates to a certain point in time (i..e month, quarter or year). We use baselines to measure progress of improvement against actual results. The progress can be stated in monthly, quarterly or annualized terms.
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.
GitLab Integrated Financial Model
Business Drivers
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]
Long Term Profitability Targets
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. 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 in FY25-Q4. The long term target for operating expenses as a percentage of revenue for G&A is 10%.
FY20 Financial Planning Goals
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
FP&A Team Responsibilities
Manager, Financial Planning & Analysis
Responsibilities
Coordinates Monthly Investor Update
Coordinates Rolling 4 Quarter Process
Coordinates Annual Planning Process
Ensures GitLab's financial model and forecast is accurate
Partners with Business Operations to ensure Financial Systems & Integration Roadmap
Develops data processes in partnership with the Data team
Responsible for financial and mechanical integrity of the operating model and street model
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:
Create an issue using the dept_change template.
In the issue, add the appropriate team members from each department included in the checklist.
Disclose the nature of the new department. Is the new department simply a name change, or there is a structural modification?
Provide all detail necessary to ensure team members are assigned to the newly created departments.
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.
By Division - Where GitLab team-members Report
Sales
Marketing
Engineering
Product
G&A
Meltano
Alliances
Corporate Marketing
Infrastructure
Product Management
Business Operations
Meltano
Channel
Demand Generation
Development
CEO
Commercial Sales
Digitial Marketing
Quality
Finance
Customer Solutions
Field Marketing
Security
People
Customer Success
Marketing Ops
UX
Recruiting
Enterprise Sales
Product Marketing
Customer Support
Field Operations
Community Relations
Allocation Methodology
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:
Workflow
Pre-Allocation P&Ls
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.
Allocation Methodology
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.
Step 1: Yellow Process
The allocation methodology is applied to the G&A Company Allocation department, Business Operations Program Spend, and the Recruiting department. Only items that are used by the entire company are captured in Business Operations Program spend (examples include gmail and slack). In addition to Business Operations Program Spend and Recruiting expenses, there are times GitLab needs a catch all account for one off expenses (examples Contribute, payroll service fees, etc). Those expenses are allocated in the same fashion as Business Operations Program Spend and Recruiting, but those expenses are recorded to the G&A Company Allocation department, before allocation.
Business Operations Program Expenses. All 6060 Spend
Recruiting Department
G&A Company Allocation department for all one off expenses.
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.
Step 2: Red Process
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.
Free vs Paid Users
Infrastructure
3rd Party Expenses [i.e. Hosting Services]
Percentage of Revenue
Customer Support
Allocation for Infrastructure and 3rd Party expenses are based off of usage from free, paid and internal users of GitLab.
Allocation of Customer Support are based off of expected revenue from GitLab's self hosted and SaaS offerings.
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
Marketing - Free users
R&D - Internal users
Cost of Sales - Paid users
Step 3: Blue Process
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.
Post Allocation P&Ls
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.
Diagram
Misc
Creating & Updating Models
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.
