Only Healthy Constraints

1. You are here:
2. Handbook
3. Only Healthy Constraints

On this page

• Introduction
• Importance of choosing to stay a startup
• Resisting unhealthy constraints

Introduction

Many companies regress to the mean and slow down over time. While some changes are required as a company grows and matures, not all change is inevitable or should be allowed to passively happen. As GitLab grows, we are conscious of how we operate and how it enables us to continue to operate with the agility of a startup while realizing the efficiencies of a scaling company. This is key to efficiency, enables iteration, and helps us to drive results. It also helps us to see progress as we maintain speed and manage cycle time.

Importance of choosing to stay a startup

A senior candidate once referenced the "Letter From Our CEO" in GitLab's S-1 (filed with the Securities and Exchange Commission on September 17, 2021). In it GitLab's CEO, Sid Sijbrandij, documented some of the ways that GitLab plans to avoid the stagnation experienced by most early stage companies as they mature. The person said, "your letter is good at reminding everyone that you are still a startup and need to retain that mindset. It's super hard, as you know. When I reflect upon all the amazing things I experienced at [Company X], it is a poorly managed company. The systems (legal, procurement, security) that grow with success are also designed to manage the downside. I see the same thing here at [Company Y]. I'm fighting to re-create the challenger mindset to reflect our market position outside of virtualization and networking. Cruft everywhere. You have an opportunity to minimize this as you scale."

We try to avoid the downside of maturation, because this better enables us to achieve results and mitigate many of our concerns. It also helps us to dodge many of the coordination headwinds that often plague more established companies.

Resisting unhealthy constraints

1. To operate like a startup, we find ways to reinforce the startup ethos within the organization. We document the ways that we are still a startup.
2. We share information through GitLab's handbook. The handbook's over 2000 pages of text provide guidelines, not rules, for how team members should operate. Information is easily shared and accessible. If something needs to be updated, all team members (and even members of the wider-community) are empowered to suggest changes.
3. We have directly responsible individuals (DRIs) who are accountable for not only project success but optimization of the process that leads to the outcome.
4. We don't make key changes to how we operate just because it is what more mature companies have done. If the change challenges our ability to operate as a startup, we often quantify the impact of the change. For example, when we were preparing to become a public company, folks challenged GitLab's stance on transparency and focused on the risk of sharing information. We were able to quantify the significant value of transparency from team member efficiency, prospect awareness, and talent recruitment (among other things). Instead of discussing whether GitLab should be transparent, we were able to shift the conversation toward how to maintain responsible transparency.
5. We proactively recruit and hire team members who demonstrate an ability to excel in entrepreneurial work. We provide financial security and an environment in which they can continue to work with autonomy as managers of one.
6. We learn from more mature companies that have been successful at maintaining a startup ethos as they scale. Apple, for example, has been called the "world's largest startup." It manages tight headcount while achieving ambitious goals and sticking to timelines. This does cause burnout, which is something we actively watch and try to mitigate.
7. We try to be true to GitLab's brand: GitLab empowers everyone through knowledge access, job access, and the DevOps platform. Part of knowledge sharing involves being transparent beyond team members. An example of this is a list of 50 learnings and best practices from our CEO, CLO, and CFO from our IPO that we plan to publish in FY23-Q1. Another is GitLab being the first company to publicly livestream its IPO, empowering anyone with an internet connection to share in the experience.
8. Team members should feel empowered to understand the why behind what they are being asked to do. If they don't, they should ask for context, so they they can make fast progress toward understood goals.
9. We create direction pages. For example, GitLab Direction and Product Direction - Growth. When folks know what they are trying to achieve, proactive direction can replace the reactive approvals that can slow things down.
10. We put expiration dates on processes or decisions that are introduced in response to immediate needs or short-term issues.
11. It's best practice to start a discussion where possible with a Merge Request (MR) instead of an issue. An MR is associated with a specific change that is proposed and transparent for everyone to review and openly discuss. The nature of MRs facilitate discussions around a proposed solution to a problem that is actionable. An MR is actionable, while an issue will take longer to take action on.
12. Some merge requests that involve a big decision or change tend to collect a large amount of feedback. As GitLab grows in size, it is unrealistic for a single person to respond to potentially hundreds of comments. To remain efficient in these MRs and to make it scalable, it is important for the DRI to receive a clear signal of input that is shared on the merge request. Some MRs may be marked as "Manager Mention MRs" by clearly designating them as such at the beginning of the MR.
13. We look for ways to measure administrative burden. This helps us to understand and mitigate the impact of bureaucracy or administration on the speed at which we can operate.
14. We explore new ways to remove constraints. These constraints can be steps, limits, or approvals. Some challenges to constraints under consideration include:
    1. Make removing constraints someone's job
    2. Add as core part of the efficiency value
    3. Reward the best challenge to a constraint
    4. Constraints challenge escalation process
    5. Optimize for change. Focus on removing existing constraints instead of preventing new ones. Can remove recent constraints.
    6. Measure cycle time (not just for DevOps but also other processes that change states)
    7. Launching a bureaucracy busters day or finding other ways to encourage bureaucracy busting
    8. A constraint busters day in which team members are encouraged to challenge existing ways of doing things and propose alternatives
    9. If we have a kick off, we should do a retrospective. If we could justify the time for alignment on the frontend, we should reflect on and action what can be improved as we implement future projects.
    10. Add relevant questions to team member engagement surveys. For example:
        1. Turnaround time of team members?
        2. To what extent does the handbook process constrain your day to day?
        3. Are we still a startup?
        4. To what extent do Finance/Legal/People/Security help you to do things more quickly?
15. Propose to stop a project or initiative if you feel it is no longer providing value
16. Suggest ways to improve a project or initiatives efficiency if it is inefficient
17. "Because we've always done it" is not a valid answer when someone challenges a decision or direction. Avoid sacred cows
18. We hire folks who are dedicated to GitLab's mission and vision. Pournelle's Iron Law of Bureaucracy explains why this is important:

In any bureaucratic organization there will be two kinds of people:

First, there will be those who are devoted to the goals of the organization. Examples are dedicated classroom teachers in an educational bureaucracy, many of the engineers and launch technicians and scientists at NASA, even some agricultural scientists and advisors in the former Soviet Union collective farming administration. Secondly, there will be those dedicated to the organization itself. Examples are many of the administrators in the education system, many professors of education, many teachers union officials, much of the NASA headquarters staff, etc. The Iron Law states that in every case the second group will gain and keep control of the organization. It will write the rules, and control promotions within the organization.