Gitlab hero border pattern left svg Gitlab hero border pattern right svg

Biggest risks

  1. You are here:
  2. Handbook
  3. Leadership
  4. Biggest risks

On this page

Introduction

People frequently ask the CEO things like:

On this page, we document the biggest risks and how we intend to mitigate them.

Lowering the hiring bar

We are growing rapidly (more than doubling headcount in CY2019 again), and 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:

  1. Have a standard interview structure
  2. Review the interview scores of new hires to look for trends
  3. Identify and take action on underperformance
  4. Have the CPO and CEO sample new hires and review manager and up hires
  5. Compare the external title with the new title being given
  6. Conduct bar raiser interviews

Ineffective onboarding

We are onboarding many people quickly, making it easy for things to fall behind. Therefore we:

  1. Measure the onboarding time
  2. Measure the time to productivity in sales (ramp time) and engineering (time to first MR, MRs per engineer per month)
  3. Make sure we work handbook-first, so the handbook is up to date.

Confusion about the expected output

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:

  1. Document who is the DRI on a decision.
  2. Have clear KPIs across the company
  3. Have Key monthly reviews
  4. Have a job family that includes performance indicators
  5. Have a clear org-chart where each individual reports to exactly one person

Loss of the values that bind us

It's easy for a culture to get diluted if a company is growing fast. To make our values stronger, we:

  1. Regularly add to them and update them
  2. Find new ways to reinforce our values

Loss of the open source community

  1. Keep our promises
  2. Keep listening
  3. Assign Merge request coaches
  4. Contributing organizations

Loss of velocity

Most companies start shipping more slowly as they grow. To keep our pace, we need to:

  1. Ensure we get 10 Merge Requests (MRs) per engineer per month
  2. Have acquired organizations remake their functionality inside our single application
  3. Have a quality group that keeps our developer tooling efficient

Fork and commoditize

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:

Type of software Application software Infrastructure software  
Interface Grafical 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 (MongDB Atlas) Hyperclouds offer mostly managed services
Feature richness Lots of proprietary features Few proprietary features More proprietary features make it harder to commoditize
Ecosystem activity Lots of contributions Few contributions Infrastructure is more complex to contribute to. ????

What we need to do is:

  1. Keep up velocity
  2. Keep the open source community contributing
  3. Follow our buyer-based-open-core pricing model

Competition

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:

  1. Efficiency value
  2. Long Term Profitability Targets
  3. KPIs
  4. Open source with a lot of wider community contributors who make it easier to uncover customer demand for features and allow our organization to stay leaner.
  5. A single application makes the user experience better, allows us to introduce new functionality to users, and it makes it easier for us to keep our velocity.
  6. Run the same code for GitLab.com and and self-hosted applications and are merging the CE and EE codebases
  7. How we make decision

What isn't a risk

We're in a great market and have multiple waves that we're riding:

Edit this page — open Web IDE — please contribute. Creative Commons License