We frequently get asked questions like:
On this page, we document the biggest risks and how we intend to mitigate them. We also have a biggest tailwinds page to see what waves we are riding in our current market.
The list below has a rough ranking of risks. The items toward the top of the list have a higher probability of occurring and/or anticipated level of consequence if are to occur.
Our customers entrust their application code and data to GitLab. A security breach that erodes that trust is a significant risk. To ensure we safeguard our customers data, we:
As more customers depend on GitLab.com instead of self-managed instances, the reliability and security of GitLab.com is crucial to the success of the organization. Even customers who use a self-managed GitLab instance are affected by GitLab.com outages because of the negative effect of the organization's reputation. Outages not only cost customers money, they also affect the company's valuation and have led to lawsuits. Disruption to GitLab.com's availability is a reputational risk.
We mitigate this risk in a number of ways:
There will always be competitive products. We tend to be much more cost effective because we build on open source, iterate quickly, get open source contributions, and only have to integrate new features with GitLab instead of a large number of tool combinations.
After GitLab core and home-grown DIY devops platforms, GitHub is GitLab's biggest competitor. After the Microsoft acquisition they have started to follow the single application strategy pioneered by GitLab.
In order to counter this risk, GitLab will:
We will always have competition. To deal with competition, operational excellence can be a surprisingly durable competitive advantage.
We encourage operational excellence in the following ways:
Our focus on improvement and commitment to iteration keep us rooted in what's next. This could result in us lowering our ambition. While we focus on what's next, we must also maintain a level of ambition to compete in the future in places where others might not think it is possible today.
We have large competitors and smaller ones. The larger competitors naturally get attention because we compete with them for large customers. According to the innovators dilemma: "the next generation product is not being built for the incumbent's customer set and this large customer set is not interested in the new innovation and keeps demanding more innovation with the incumbent product". So it is really important that we also focus on the needs of smaller users since the next generation product will first be used by them. If we don't do this we risk smaller competitors gaining marketshare there and then having the community and revenue to go up-market.
We serve smaller users by having:
The largest cost in application delivery is typically infrastructure. Large hyper-scale infrastructure providers could bundle their own native DevOps platform usage with their infrastructure. There are a couple of industry trends which limit this risk:
Also, see the fork and commoditize move that is available to hyper-scale infrastructure providers.
In a similar vein, it is important that we do not slow down, which means being very proactive in addressing underperformance. We should identify and take action as early as possible.
GitLab's success will create growth opportunities for team members inside and outside of the company.
To mitigate the risk of key people leaving the company, we:
Key people may leave as they vest and achieve their economic goals.
As reflected in our compensation principles, we don't want people to stay because they feel like they have golden handcuffs, but we do recognize the alignment that comes with options vesting. Beginning in FY22, eligible GitLab team members will be reviewed for a refresh grant once per year.
Alternatively, early team members may leave because working at a company the size of GitLab today or the size of GitLab in a year is different than working at an early-stage startup. Big companies are organizationally different than small startups, but there are many things about the spirit of a startup that we can maintain, notably:
Keeping the feel of a small startup, despite a growing headcount, may help retain employees who would otherwise leave.
Ineffective management could lead to decreased team member retention and team member satisfaction, as well as make functioning difficult.
In order to address this, we:
It's easy for a culture to get diluted if a company is growing fast. To make our values stronger, we:
It's possible that a lack of diversity, one of our values, could lead to building a product that is not inclusive. To mitigate this, we have many DIB initiatives, including diversity goals in leadership and throughout the company and referral bonuses for underrepresented groups.
When asked in an interview on GitLab Unfiltered to elaborate on this risk, GitLab co-founder and CEO Sid Sijbrandij offered the following context.
If you lose the values that bind a company, you lose the ability to coordinate. For example, take our Iteration value. If one person is iterating, and they have a minimal, ugly feature that they wish to add, while another person who came from another company insists that 'This is nowhere near finished!,' you have a conflict.
It's not that one approach is better than the other. It's about aligning. You set the company up for a lot of conflict if you don't have shared values.
We work Handbook First. As we say,
Having a "handbook first" mentality ensures there is no duplication; the handbook is always up to date, and others are better able to contribute.
If we work handbook second, we risk losing these benefits.
To ensure we avoid this risk, we:
Most companies start shipping more slowly as they grow. To keep our pace, we need to:
We were voted The World's Most Productive Remote Team by HackerNoon.
As more folks work away from customers, it is easy to lose sight of whom we are serving. We can address this by:
Remote work is a diminishing competitive advantage for GitLab, which is a net positive for the world but creates unique pressures to retain team members. Key people may leave as remote opportunities proliferate, impacting talent retention, recruitment, team continuity, and financial pressures related to total rewards.
GitLab team members are distinctly positioned to be recruited by newly-remote and transitioning organizations. As a workaround for the acute shortage of operational talent in the remote transformation space, organizations may be inclined to prioritize hires for existing roles from GitLab and other established remote firms, justifying above-market compensation by factoring inbuilt expertise on managing a remote team. This is akin to someone who speaks multiple languages receiving more regard and compensation for the same role, with GitLab team members serving as a proverbial remote work translator.
Accelerated by the COVID-19 pandemic, more organizations are now willing to hire remotely. While hybrid-remote is a suboptimal experience compared to all-remote, investment in equitible workplace experiences will narrow this gap.
At particular risk is GitLab's geographic diversity. Team members farthest from major cities may leave to achieve accelerated financial success at newly-remote organizations which utilize a different compensation philosophy.
As the number of layers increase and middle management layers increase, innovation and creativity are stifled. While this could be reflected in loss of velocity, innovation is also about the ideas that are being brought to the table.
In addition to keeping our hiring bar high, we have the benefit of our community to help bring new insights and use cases creating issues. We can keep this momentum by continuing to value and engage with our community. We have Merge Request Coaches who help contributors to get their merge requests to meet the contribution acceptance criteria, and wider community contributions per release is a GitLab KPI.
Due to the breadth of our product scope, and the fact that our product and engineering teams work in isolation in stages and groups, there is a risk that the end-to-end experience in the application will break down.
In order to avoid this negative outcome, we:
Making decisions on bad data will cause inefficiency, re-work and ultimately bad decisions. The lack of data for key parts of the business will put GitLab at a competitive disadvantage to other companies who do have similar data.
We can mitigate this risk by:
As we add more layers of management to accommodate the new people, it's easy to become confused about what is expected of you.
To make sure this is clear we:
Transparency is a GitLab value. It is central to how we operate and our success as a company. It is important for employee recruitment and retention. It is also valued by GitLab customers, contributors, and the many folks who utilize GitLab's handbook to better their own businesses. While GitLab will continue to prioritize transparency, it must also promote "responsible" transparency as openly sharing information can have unintended consequences. To mitigate risks from irresponsible (or "radical") transparency, we:
As we continue to grow our company, there is pressure on departments to meet their hiring targets. It is better for us to miss our targets than to hire people who won't be able to perform to our standards since that takes much longer to resolve. To ensure the people we hire make the company better, we:
We are onboarding many people quickly, making it easy for things to fall behind. Therefore we:
Since we are based on an open source product, there is the risk of fork and commoditize like what AWS experienced with ElasticSearch.
This risk is reduced, because we're application software instead of infrastructure software. Application software is less likely to be forked and commoditized for the following reasons:
| Dimension of software | Application software | Infrastructure software | Reason |
|---|---|---|---|
| Interface | Graphical User Interface (GUI) | Application Programming Interface (API) | A GUI is harder to commoditize than an API |
| Compute usage | Drives little compute | Drives lots of compute | Hyperclouds want to drive compute |
| Deployment | Multi-tenant (GitLab.com) | Single tenant managed service (MongoDB Atlas) | Hyperclouds offer mostly managed services |
| Feature richness | Lots of features | Few features | More features leads to more hard to commoditize proprietary features |
| Ecosystem activity | Lots of contributions | Few contributions | Infrastructure is more complex to contribute to |
What we need to do is:
An economic downturn will likely prolong our sales cycle. Our opportunity should still be there since GitLab saves companies money on licenses and integration effort.
In order to counter this risk, GitLab:
COVID-19 and impact of a pandemic:
As a remote first company, we have the tools and culture to work from home and be productive during this unprecedented time of COVID-19.
Here are the things we can do at GitLab counter this risk:
Often startups struggle through the transition when founders leave the company, especially when those founders also serve as the CEO.
To ensure we avoid this risk we:
As a company expands, you get more layers of middle management. This can cause the following problems:
Each one of the problems above has a specific solution:
This is especially a problem if there are acquisitions of new technologies. We address this for acquired technology by having acquired organizations remake their functionality inside our single application.
Otherwise, we have a clear and consistent prioritization framework across engineering and product that helps ensure we are continuously making progress on the most important issues.
While building enterprise software, we run the risk of optimizing the software for the buyer only while creating a bad experience for the end-users of the software. This is seen in the Concur effect
In order to prevent this effect, we will:
Not following our acquisition strategy, not rebuilding what we acquire, could lead to poorly integrated acquisitions. As we continue to grow and potentially acquire additional companies, we want to rebuild their product inside of GitLab to avoid needing to maintain different code bases and applications. In order to manage this risk:
If we don't set targets appropriately and communicate about those expectations effectively, team members, investors, and other community members may not understand how we're performing. Missing a super-high goal while achieving really, really high results is still something to be acknowledged and celebrated. We need to set and communicate targets that both drive the highest possible results and also ensure constituents understand the business results and in context.
Our value of iteration keeps us from marrying ourselves to timelines and product features that get planned years before development.
GitLab is a functionally organized company. Projects in Sales are worked on by Sales. Projects in Marketing are worked on by Marketing. This could lead to functional silos, which could lead to loss of efficiency, duplicative work, or miscommunication.
We mitigate functional silos by encouraging cross-functional communication and relationship-building through:
Collecting as much data as possible is great. But then reporting on all of that data because you have it can lead to sub-optimal results, as team members won't know what is important or what to optimize for.
This article explains some of the risks of an over-obsession on metrics and reporting.
We can mitigate this risk by:
We've seen other companies struggle when they have been unwilling or unable to invest in future product innovations or disrupt current offerings to meet future demands. We mitigate this by allocating a portion of R&D budget to future innovations and exploring new opportunities through Single-Engineer Groups. Iteration helps us to place small bets and justify future investment after seeing initial momentum.
