Mitigating Concerns

On this page, we document some of our concerns

Introduction

We frequently get asked questions like:

  • What are your top concerns?
  • What are your biggest fears?
  • What keeps you up at night?

On this page, we document some of our concerns and how we address, or intend to address, them.

Listed below are some of our concerns bucketed by type. We do not view the list as being static because we anticipate that the list, and potential impact of a concern, will change over time.

Culture

Loss of the open source community

  1. Keep our promises
  2. Keep listening
  3. Assign Merge Request Coaches
  4. Have Leading Organizations

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

It’s possible that a lack of diversity, one of our values, could lead to building a product that is not inclusive. To address 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 concern, 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.

Handbook Second

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 may lose these benefits.

To address this concern, we:

  1. Ensure all new hires read and understand the communication guidelines, as part of their onboarding
  2. Make the ability to coach team members to work handbook first a requirement for promotion to Director or above
  3. Explicitly ask CEO Shadows to promote working handbook first
  4. Empower all team members to help promote our communication guidelines

Loss of velocity

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

  1. Ensure we get 8 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
  4. Achieve our category maturity targets
  5. Ensure each group has non-overlapping scope

We were voted The World’s Most Productive Remote Team by HackerNoon.

Loss of customer centricity

As more folks work away from customers, it is easy to lose sight of whom we are serving. We can address this by:

Remote proliferation

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.

A particular concern 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.

Innovation and creativity are stifled

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.

Irresponsible transparency

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 others who may use GitLab’s handbook. While GitLab will continue to prioritize transparency, it must also promote “responsible” transparency as openly sharing information can have unintended consequences. To address concerns from irresponsible (or “radical”) transparency, we:

  1. Are clear with team members on which information cannot be public. This should be clearly captured in the not public section of the handbook
  2. Execute fast and efficiently drive results and stay ahead of competitors who read our handbook. As Peter Drucker says, “Strategy is a commodity, execution is an art”
  3. Educate team members on effective and responsible transparency. For example, we offer a transparency competency

Setting expectations incorrectly

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.

Functional Silos

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 address functional silos by encouraging cross-functional communication and relationship-building through:

  • Being public by default, enabling all functions to have simultaneous visibility into OKRs, direction, issues, and milestones within the handbook.
  • Coffee chats, including letting Donut help intro you to team members
  • Getting together in-person every 9 months for our Contribute
  • Contribute is multi-function; we try to do every in-person event as a multi-function event. An exception would be Sales Kick Off (SKO). SKO is an anti-pattern, though some cross-functional groups are invited to SKO that support sales (product, legal and marketing, for example).

Being obsessed with metrics (vs. being data-driven)

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 downsides of an over-obsession on metrics and reporting.

We can address this concern by:

  • Picking a small set of most important metrics (KPIs), based on Trusted Data, that represent our best view of how the company and a function are doing (and what they should be focused on)
  • Using easily understood metrics, that are directly tied to results desired (that can’t be gamed)
  • Automating reporting as much as possible
  • Give team members a voice in selecting KPIs

Playing politics

Political behavior is counter to GitLab’s values and make it harder to achieve results. We define political and non-political behavior on our Values page.

Product

Loss of great end-to-end experience

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 concern that the end-to-end experience in the application will break down.

In order to avoid this negative outcome, we:

  • Have research team interview personas to ensure a good end-to-end workflow for specific persona types - doing
  • Ensure adequate product leadership that is focused across the entire product line (Growth Director, Enablement Director, Product VP) - doing

Bad, insufficient and missing data

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 address this concern by:

  • Being honest and transparent about the quality of the data we are looking at (the Trusted Data framework is a great start)
  • Resisting making decisions on incomplete or not-trusted data. Being intellectually honest that the decision is ultimately a judgement call, as the data is not complete
  • Tracking down data inconsistencies, and restating old data - BUT not going back in time to post-judge previous business decisions made when data was insufficient

Technical debt ineffectively managed

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.

Enterprise product management

While building enterprise software, it’s possible to optimize the software for the buyer while creating a subpar experience for the end-users of the software. This is seen in the Concur effect

In order to prevent this effect, we will:

Frankenstein product

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 address this concern:

  • Follow our acquisition strategy
  • For Engineering, the deciding factor is whether the senior-most technical stakeholder–who is not a founder–is on board or not. Because this person will either get the engineers on board or foment resistance.

Inability to respond to technological change

Our value of iteration keeps us from marrying ourselves to timelines and product features that get planned years before development.

Insufficient Investment in Innovation

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 address 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.

Security and reliability

Security breach

Our customers entrust their application code and data to GitLab. A security breach that erodes that trust is a significant concern. To ensure we safeguard our customers data, we:

  1. Maintain a strong Security Operations team
  2. Hit our Application Security remediation SLAs
  3. Ensure our developers complete secure code training
  4. Regularly perform internal application security reviews
  5. Utilize bug bounty programs like HackerOne
  6. Have an internal Red Team
  7. Prioritize meeting the security requirements of team members, users, customers, and other community members

GitLab.com Reliability

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 concern.

We address this concern in a number of ways:

People/Managers

Lack of performance management

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.

Key people leave

GitLab’s success will create growth opportunities for team members inside and outside of the company.

To address the concern of key people leaving the company, we:

  1. Invest in a talent development program to increase team member engagement
  2. Identify and proactively invest in team members who drive the success of our organization through our talent assessment program.

Vesting

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.

Company size

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

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:

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 Reviews
  4. Have each job family include specific performance indicators
  5. Have a clear org-chart where each individual reports to exactly one person
  6. Have managers regularly ask team members if they understand job expectations and close any gaps in understanding.
  7. Ensure that at least 90% of the population responds favorably to the Engagement Survey question “I know what is expected of me to be successful in my job.”
  8. Celebrate our growth in revenue when we hit $100M in ARR instead of 1000 people. We put our attention in celebrating our output instead of input, per our results value.

Lowering the hiring bar

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:

  1. Have a standard interview structure
  2. Have a standard scoring system within a function; in other words, a “Strong Yes” should mean the same thing to every interviewer in Marketing.
  3. Ensure that interviewers are scoring candidates consistently. Some teams are actively doing this
  4. Review the interview scores of new hires to look for trends
  5. Identify and take action on underperformance
  6. (make this unneeded) Have the CPO and CEO sample new hires and review manager, staff engineer, principal product manager and up hires
  7. Compare the external title with the new title being given
  8. Conduct bar raiser interviews
  9. Review cohort performance in the company (completion of onboarding tasks, bonuses, performance review, 360 feedback, performance indicators)

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.

Founder Departure

Often startups struggle through the transition when founders leave the company, especially when those founders also serve as the CEO.

To address this concern we:

  1. Built a highly capable E-Group and Board of Directors
  2. Actively discourage a cult of personality around our CEO
  3. Have the CEO take normal vacations
  4. Actively help the CEO grow with the company, including training, coaching, and feedback

More layers of middle management creating problems

As a company expands, you get more layers of middle management.

This can cause the following problems:

  1. With growing middle management, people start focusing on being liked by others more than results because it’s hard to attribute results to a specific manager.
  2. When there are more middle managers, it’s harder to attribute success to the right person. The manager takes the credit for success but blame gets pushed downwards.
  3. There is a natural tendency to focus on underperforming team members and help them improve at the cost of focusing on your highest performers and making them more successful.
  4. It lowers friction that may arise if giving all team members the same increases, because you don’t have to defend the logic behind it and no goal setting is needed.
  5. A mistake can be more detrimental for your career than a good decision can help it, because mistakes draw more attention than success and mistakes are easier to attribute to a person.
  6. The more layers of management there are, the further the distance from the average individual to the customer.

Each one of the problems above has a specific solution:

  1. We address this by prioritizing our results value in our value hierarchy and by not playing politics.
  2. Drive praise downward in the organization. When something is a success, attribute that success to the DRI. It can be as easy as telling someone they did a good job.
  3. Focus disproportionately on the best performers by explicitly identifying the high performance. Leaders need to judge whether investment can help bring someone up to a higher level. If an investment of time adds value to the team member, the team, and the organization, invest in the team member. A meritocracy means that we invest in folks who are performing.
  4. Raises should not be spread evenly (there should be variability and dispersion).
  5. Incentivize folks to take calculated action. Make failure acceptable. There is a thin line between incentivizing action and recklessness, so draw the line carefully. For example, when team-member-1 accidentally dropped our production database, they were still promoted because we promote based on performance.
  6. Focus on customer centricity.

Market

Competition

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.

GitHub

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 address this concern, GitLab will:

  1. While both GitLab and GitHub are single applications, GitLab has a much broader scope.
  2. GitLab is focused on the enterprise use cases, GitHub on open source projects.
  3. GitLab is independent of the hyper cloud providers and the best way to be multi-cloud.
  4. Leverage our community to deliver new stages, categories and features faster
  5. Continue to focus on operational excellence to out ship even substantially better financially resourced competition

Operational excellence

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 self-managed applications and merged the CE and EE codebases
  7. How we make decisions

High Ambition

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.

Serve smaller users

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 smaller competitors may gain marketshare there and then have the community and revenue to go up-market.

We serve smaller users by having:

  1. A great free open source product that gets the majority of new features.
  2. A focus on memory consumption reduction to ensure it is affordable to run our open source version.
  3. A tiered pricing model with a very low pricepoint for our lowest tier.

Infrastructure Bundling

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 concern:

  1. Businesses are increasingly avoiding infrastructure vendor lock-in and pursuing multi-cloud strategies.
  2. Infrastructure players have been slow to develop user friendly, complete DevOps platforms.

Also, see the fork and commoditize move that is available to hyper-scale infrastructure providers.

Fork and commoditize

Since we are based on an open source product, there is the concern of fork and commoditize like what AWS experienced with ElasticSearch.

We address this concern 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:

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

Economic Downturn

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 address this concern, GitLab:

  • Maintains a healthy amount of cash on our balance sheet
  • Makes short term commitments so we can correct course easily
  • Is as small as we can be, while still being able to execute our product vision
  • Can slow operating expense growth to match any decline in revenue, if required

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 address this concern:

  • Empower our team members to take care of themselves and their family so we keep them safe
  • When speaking with customers, lead with empathy and help support their transition to remote
  • Be the example for how to be even more effective as a remote company