CEO

Intro

This page details processes specific to Sid, CEO of GitLab. The page is intended to be helpful, feel free to deviate from it and update this page if you think it makes sense. If there are things that might seem pretentious or overbearing please raise them so we can remove or adapt them. Many items on this page are a guidelines for our Executive Business Administrators (EBAs).

CEO Bio

Sid Sijbrandij is the Co-founder, Chief Executive Officer and Board Chair of GitLab Inc., the most comprehensive AI-powered DevSecOps platform. GitLab’s single application helps organizations deliver software faster and more efficiently while strengthening their security and compliance.

Sid’s career path has been anything but traditional. He spent four years building recreational submarines for U-Boat Worx and while at Ministerie van Justitie en Veiligheid he worked on the Legis project, which developed several innovative web applications to aid lawmaking. He first saw Ruby code in 2007 and loved it so much that he taught himself how to program. In 2012, as a Ruby programmer, he encountered GitLab and discovered his passion for open source. Soon after, Sid commercialized GitLab, and by 2015 he led the company through Y Combinator’s Winter 2015 batch. Under his leadership, the company has grown with an estimated 30 million+ registered users from startups to global enterprises.

Sid studied at the University of Twente in the Netherlands where he received an M.S. in Management Science. Sid was named one of the greatest minds of the pandemic by Forbes for spreading the gospel of remote work.

Sijbrandij pronunciation hint

A pronunciation hint for Sijbrandij: It’s like when you have seen some distilled wine, and want to point it out: Sid, see brandy

Related pages

• CEO shadow program
• CEO Job Description

Favorite Restaurants

Moved to a google document internal to GitLab team only. Please search in Google Drive file name: CEO’s Favorite Restaurants. If you have questions please message the Staff EBA to the CEO in #eba-team or DM.

Flaws

Transparency and directness are part of our values and I want to live them by sharing the flaws I know I have. I’m fully responsible for improving the things below, listing them is no excuse. They are listed here for two reasons. The first one is so that people know it is not them but my fault. The second one is so I can improve, I hope that listing them lets people know I appreciate when people speak up about them.

1. I look serious all the time, it is OK to say ‘maybe you can smile more.’
2. I love debating, it is OK to say ‘please stop debating and start collaborating’ or ‘we should have a dialectic instead of a debate.’
3. My English pronunciation, choice of words, and grammar are not great. I’m taking lessons but I welcome corrections when we’re having a 1:1 conversation and/or when it might confuse people.
4. When in a rush I will jump to conclusions, it is OK to ask ‘can we take more time to discuss this.’
5. I sometimes make reports feel like I’m scolding them, as in being angry for a perceived fault. It is OK to say, I don’t mind you making that point but your tone doesn’t make me feel respected.
6. In my feedback I sometimes sound more like I’m giving an order instead of offering a suggestion, even when I mean the latter. It is OK to say ’that sounds like an order, I would have appreciated it more in the form of a suggestion.’
7. I sometimes fail to distinguish which of the three levels of performance I’m talking about. It is OK to ask ‘is that a commitment, an aspiration, or a possibility?’.
8. I come across as negative since I focus on what can be improved. It is OK to ask ‘what recent improvements are you happy about’?

If you speak up about them I should thank you for it, it is OK to say ’this was on your list of flaws so I kinda expected a thank you’. I’m sure I have more flaws that affect my professional life. Feel free to send a merge request to add them or communicate them anonymously to one of our people operations team members so that they can send a merge request.

Not a flaw but something to know about me, I have strong opinions weakly held. Or as someone said, I come in hot but am open to new evidence.

Strengths

Sid is easy to talk to on any subject. He is good at drawing people out and challenging them to grow, in a supportive way. He can meet anyone on their level and have a productive conversation. Watch a quick video from a CEO Shadow recounting her observations.

Pointers from CEO Direct Reports

1. Sid takes hard feedback well, but he’s difficult to give feedback to because he can be intimidating. Build up your muster and don’t hold back.
2. Sid is worth managing up to. The learning curve he’s on is as steep as it gets, and he does learn/change/adapt readily, so you will see a return from investment.
3. Sid is GitLab’s product visionary.
4. He’s the anchor of all-remote.
5. Sid is the source of our transparency value.
6. Sid is also the driving force for our iteration value. For example, he may hold Iteration Office Hours.
7. Sid really values 1:1 preparation.
8. Sid believes in “strong opinions, weakly held.” He doesn’t always seem like it, but he will change his mind quickly if you present him with compelling new information and a data driven perspective.
9. Sid loves naming things, and strongly believes in the power of clear language. Learn and use (and add to) our terminology e.g. It's not a "best practice", it's a "boring solution". The product categories page is a good example. Sid advocates for using MECEFU terms to keep communication efficient.

Interviewing and conducting meetings

This section was started by GitLab’s Head of Remote Darren M. to coach and provide context to others who meet with and interview Sid. The below are suggestions based on a history of personal interviews, extracted lessons from GitLab Unfiltered interviews, and observations during a CEO Shadow rotation. Others are welcome to create a merge request and add more.

1. How scripted are interviews? Sid does well in unscripted interviews, but prefers questions outlined in a Google document and attached in the meeting invite in advance. The EBA to the CEO can assist you with this. Interviews tend to go well when it is clear ahead of time what the crux of the conversation will be about, and there is documented context which can be consumed asynchronously ahead of time.
2. What if questions arise which aren’t in the agenda? Do you add them and keep the conversation going? Expert interviewers will actively anticipate that new and unexpected questions will arise. You may be surprised by the question, but not that the question happened. The interviewer is responsible for keeping the conversation on track according to the agenda. If you feel that a question veers the conversation too far off track, document the question and add a to-do for a follow-up or asynchronous answer. At GitLab, agendas are revered; feel confident in using the agenda to keep the interview crisp.
3. Do you script perspective and commentary? Unscripted, authentic feedback and commentary is appreciated and shows preparation for the subject matter and an understanding of discussion flow. With Sid (and other interview subjects), practice gets you closer to perfection. Professional media training creates a deeper understanding of this concept.
4. Do you worry about saying the wrong thing? This may be challenging to overcome. A list of tips for overcoming this are below.
   1. Be comfortable with (seemingly) awkward silence. Sid appreciates time to analyze and gather his thoughts to provide the most thoughtful, cohesive response. Silence is not an indicator of his disapproval of the question or angle.
   2. Make it personal. Ask Sid “Why do you feel this way?” or “What did you learn from this?” or “What happens in your day that relates to this?” Sid is able to craft stories which involve personal anecdotes that create deeper understanding and learning for the audience.
5. Be bold in your questions. Sid enjoys the challenge of a hard or (thoughtfully) audacious question. Sid fields a lot of questions on a daily basis, many of which can be answered by referencing the GitLab handbook. By referencing a current state in the handbook and digging for more context and nuance, this provides opportunity for Sid to answer and provide value to more than just the interviewer — the new context should be added to the handbook after the interview to benefit all.
6. Apply to the CEO Shadow program. There is no equivalent to watching Sid meet with and interview a global array of people for two weeks. The program is an efficient way to gain a deeper understanding of Sid’s style and personality. Moreover, the program enables GitLab team members to realize that Sid is not only a CEO, but also an individual who enjoys working with others who will challenge him and accelerate his personal growth.
7. Don’t be ashamed with ending early. It is natural to try to fill an allotted time block with a CEO. Remember GitLab’s value of Efficiency and be bold if you’re able to progress through an agenda quickly. A recommend close-out statement is: “We were very efficient driving through the agenda. Any final points before we close?”
8. Listen to Sid’s interview on the Changelog podcast. There are hundreds of hours of Sid speaking on the internet, but this interview showcases a talented interviewer (Adam) extracting nuance and detail from Sid in a comfortable and professional way. The interviewer is thoughtful yet audacious in his questions, while also bold and considerate. He challenges Sid and commands mutual respect.

Communication

Thanks to Mårten Mickos for the inspiration for this section. All good ideas are his, all bad ones are mine.

I am a visual person much more than auditory, and I am a top-down person much more than bottom-up. This means that I love written communication: issues, email, Google Docs, and chat. Feel free to send me as many emails and chat messages as you like, and about whatever topics you like. I prefer chat over email.

If you have a great new idea or suggestion for me, I appreciate if you can convey it in a picture or in written words, because I learn by seeing more than I learn by hearing. I don’t mind if you send me or point me to plans that are in draft mode or not ready. I am happy if I can give useful feedback early. It doesn’t have to be perfect and polished when presented to me.

In written communication, I appreciate the top-down approach. Set the subject header to something descriptive. Start the email by telling me what the email is about. Only then go into details. Don’t mix separate topics in the same email, it is perfectly fine to send two emails at almost the same time. Try to have a concrete proposal so I can just reply with OK if that is possible.

I get many email on which I am only cc’d on, I would very much appreciate if you started emails intended specifically for me with “Sid,” or some other salutation that makes it clear that the message is for me.

Presentations and slide decks

Share slide decks in advance of meeting with me per few meetings with presentations communication guideline. I can be tagged in a relevant Slack channel.

When sharing slides with me, limit the content on each slide to one concept. Avoid condensing multiple concepts into one slide. Additionally, the slide title should be specific to the content on that slide. For example, instead of condensing two lists onto one slide, separate the lists onto two separate slides with slide titles specific to each list.

This also applies if you are providing slides for me to present.

Connecting on Social Media

I have accounts on LinkedIn and Facebook. I will not send invites to team members on those networks since as the CEO I don’t want to impose myself on anyone. But I would love to connect and I will happily accept your LinkedIn and Facebook friend request. Please ping the Staff EBA to the CEO in #eba-team on slack and they will accept your connection request. You can also find me on Twitter as @sytses, I won’t request to follow private twitter accounts, I assume I’m welcome to follow public twitter accounts, if not please let me know.

Communicating Follow Ups

Sometimes I will ask to be kept apprised of an action item or follow up. One common way for me to express this desire is by applying the CEO Interest label on a GitLab issue. When keeping me apprised please tend toward over-communication. The primary method to communicate your follow up to me should be via MR or issue updates posted in the #ceo slack channel including specific notification when an issue is completed or closed. It might feel like you are being bothersome or distracting, but it is not. If I ever feel like you are truly over-communicating, I will let you know.

Communicating in Slack

I get a lot of @ mentions in Slack, often when I’m being discussed. Please only @ mention me when you need me to see something or approve something, when you just want to refer to me you can just say Sid. This saves time and enables increased efficiency.

If there is a suggested message draft that you’d like me to post in Slack, you should send two messages to me. The first message should include the context behind the ask, the suggested timing for posting, and a link to the channel that the draft will be posted in. Under this message reply in thread with your second message. This should only contain the draft message. This allows me to easily copy and paste on mobile.

No Sacred Cows

I’ve been thinking about the notion of Sacred Cows since I heard that people use “Sid said” as an argument in conversations.

The phrase comes from the belief of devout Hindus that cows are sacred animals and should never be harmed. In the US, we use this term to mean “one that is often unreasonably immune from criticism or opposition.” If we’re truly practicing continuous learning, we have to question the Sacred Cows that can subtly and profoundly influence how we make decisions and conduct business. We need to examine Sacred Cows with ruthless compassion. By that I mean that we should be ruthless about examining and questioning their validity while being compassionate with the person citing the Sacred Cow.

Just because I said something doesn’t make it inviolable law like a law of physics. My utterances are usually merely an opinion based on the context of the discussion and the moment. As new context is revealed, we need to be willing to reexamine what we say and iterate.

What I propose is that next time ‘Sid said’ is mentioned you check in with me, I might say:

1. “Yes, here’s my reasoning .. what is yours” we then choose to:
   • Keep it and maybe document the reasoning so it can be falsified in the future.
   • Change it based on your reasoning

But it is also possible that:

1. “I never made the statement”
2. “I don’t recall making it”, or
3. “It’s been misinterpreted.” And
4. “Now that you mention it, it doesn’t hold up in light of the situation we’re in now”

Communicating Merge Requests

Please follow these steps if you’d like me to review a Merge Request (MR) for approval:

1. Create the MR
2. Have the MR reviewed by a peer or your manager if you’d like early feedback
3. Ensure that the MR is mergeable:
   1. All comment threads are resolved
   2. If the MR is a draft, mark the MR as ready
   3. The CI/CD pipeline ran successfully and deployed the latest review app
4. When the MR is ready for my review:
   1. Add @sytses as a Reviewer to the MR. You can use this quick action: /assign_reviewer @sytses.
   2. Post to the #ceo Slack channel, @ mentioning me asking for my review. Please provide a brief description sharing the context.
   3. Optional: Add a direct URL to the deployed review app to the Slack message for faster access
   4. Address any feedback I provide and ensure that the MR is mergeable (see #3 above)
5. After my approval is given merge the MR if I have not

Please chat me the subject line of emails

I prefer other forms of communication (e.g. slack) over email. I get a lot of email and I’m frequently not on top of it. I appreciate it if you send my EBA a slack message if I need to respond to an email. Please quote the subject line of the email in your chat message.

Sending email

If someone else in the company wants to have me send an email they should email me and cc my EBA with:

1. Instruction: “Please email this, please BCC: me on the outgoing email, forward any responses, and cc: me on any further emails.”
2. Recipient name
3. Recipient email
4. Email subject
5. Email body (text based, no HTML or rich text)

When receiving such an email my EBA should stage a draft email to the recipient and a draft answer ‘done’.

The email should only be the body. Greetings and niceties are handled by the EBA.

Meeting request requirements

For scheduling a video call or meeting with me or other execs, please see the EBA handbook page. Please do not use Zoom waiting rooms for meetings scheduled with me or on my behalf. If attendees are joining separate sections of a meeting, you can break the session into multiple Zoom calls or have a Slack channel to manage attendee entrances and exits.

CEO Meeting Cadence

As part of my role, I participate in a variety of meetings both internal and external. Please see below for a general overview of these.

Daily Meetings

1. Group Conversation. 25 minutes.

Weekly Meetings

1. 1-1s with my direct reports and EBA. 25-50 minutes.
2. E-Group Call. 120 minutes.
3. If there are open positions Talent Acquisition Syncs on key Executive hires. 25 minutes.
4. Topical conversations on top cross-functional initiatives or other areas of importance to the CEO. 25 minutes.
5. Candidate Interviews. 50 minutes.

Monthly Meetings

1. Key Review with Executives and function leaders. 25 minutes.
2. CEO Group Conversation. 25 minutes.
3. 1-1 with CEO Coach. 80 minutes.
4. Industry Analyst Meetings. 25-50 minute meetings.
5. Coffee Chats. 25 minutes.
6. Retrospective. 25 minutes.
7. Monthly Release Kick-off. 25 minutes.
8. CEO 101. 50 minutes.
9. Customer meetings or on-site visits. 25-90 minutes.
10. Executive AMA’s (Ask Me Anything). 25 minutes.
11. Investor Relations meetings at the request of the CFO and/or VP, Investor Relations. Range from 25 minutes to 1+ days.

Quarterly Meetings

1. E-Group Offsite Monday-Thursday. After QBR’s and before the Board of Directors meeting.
2. GitLab Board of Directors Meeting. 3.5 hours via Zoom. Usually preceded by a dinner or followed by a lunch for those who wish to attend in-person in San Francisco.
3. GitLab Board of Director Committee Meetings => Audit Committee, Compensation and Leadership Development Committee, and Nominating and Corp Governance Meeting. 50 minutes.
4. Skip Levels with direct report’s leadership team. 25 minutes.
5. 1-1 with GitLab Board Members. 25-50 minutes.
6. OKR E-Group Planning 50-90 minutes.
7. OKRs How to Achieve Meeting. 25 minutes with each function Executive.
8. Board Member AMA’s. 25-50 minutes.

Annual Meetings

1. Annual Planning with the GitLab Board of Directors. 50-80 minutes.
2. Fiscal Year Kickoff. 50 minutes.
3. Industry Conferences such as: DevOps Enterprise Summit, AWS re:Invent, KubeCon, Linux Summit

CEO Vacation Preference

I try to plan my vacations around times when many team members in the United States are on vacation. A rough overview of these times is captured on GitLab’s cadence page. Other team members may also preference taking off work during these windows as there tends to be less demand for synchronous collaboration during these times.

Candidate interviews

1. Candidate interviews should default to 50 minutes unless there is a specific request to make the meeting shorter or longer.
2. There should be an invite that includes both the candidate and the CEO. If this is a C-level candidate or it is otherwise requested, the meeting should have “private” visibility. Otherwise, it can be “public.”
3. There should be a second calendar invite from Sid’s account with the subject: [Shadow or No Shadows] CEO Briefing Doc: [Person’s Name]. This should follow the “private” conventions shared in item 2. This invite should include a briefing document that is shared with the hiring manager and recruiter (if there is one). The document contains the following information:
   1. Role with a link to the job family
   2. Candidate’s LinkedIn link
   3. Link to resume
   4. Link to the prep package from the recruiter (relevant for searches with external recruiters)
   5. Summary of interviews to date
   6. Concerns for the interviewer to dig into.
   7. Focus of the call. Is it more about evaluating the candidate or more about getting the candidate excited about the position?
   8. The Greenhouse link or a place for “CEO Notes”

Candidate interviews with GitLab Board Members

The recruiter should share a prep package with the Board Member at least 3 business days in advance of a candidate interview. This should include:

1. The purpose of the interview. The specific ask (for ex, sell, evaluate expertise in x) should be clearly stated
2. Summaries per interview of all interviews done to date
3. Any concerns
4. Guidance on how to provide feedback after the conversation

Pick Your Brain interviews

To schedule a Pick Your Brain interview with me, please see the EBA handbook page. To watch and read prior Pick Your Brain interviews about all-remote, please see the Interviews page.

For scheduling a video call or meeting with me or other execs, please see the EBA handbook page.

External Speaking Engagements

To schedule Sid to speak at an external engagement please contact the EBA to the CEO with the details outlined in the Executive External Event Brief. The EBA to the CEO will gain approval from the function head of the requester on whether the CEO will attend or not. Sid’s preference is to participate in 1:1 fireside chats or conduct a stand alone presentation (audience Q&A is fine). He does not participate in panels with multiple speakers.

Requests for audio/visual check meetings

If the organizer of an event requests a prep meeting with Sid to check audio and visual before a remote presentation, we can schedule for 5 minutes before the event for Sid to login and confirm that audio and visual are working as expected. A longer prep meeting is not required as Sid has a robust remote work setup.

Sales meetings

• I love to talk to users or potential users of GitLab anytime.
• Traveling is not efficient because it can take 2 to 10 times the time of the meeting itself.

Some general guidelines of what travel is appropriate, these guidelines are not fixed, feel free to ask for exceptions:

1. Check my availability with the EBA, reschedule with the EBA, cancel with the EBA, not me.
2. I’ll take any meeting via video conference or in our boardroom.
3. I’ll take a meeting in the Bay Area as long as it is not an SMB organization.
4. I’ll take a meeting outside the Bay Area but in the US with large or strategic organizations.
5. I’ll take a meeting outside the US with strategic organizations.

Consider the following to increase efficiency:

• Combine meetings with multiple organizations in the same location.
• Get meetings with multiple stakeholders in the same company.
• Apart from the formal meetings try to organize a meal with stakeholders.
• Record the meeting so you can distribute it to others in the organization.
• Please check with the EBA to look at my calendar to leverage my existing travel plans.
• Make sure to let the EBA know what you expect from me. E.g. arrive an hour before, do a pitch etc.
• Please plan audio only meetings only when the customer explicitly declines a video call.
• Any meeting that requires travel should be properly prepared and any lessons relayed to the marketing team.

Conferences

When at conferences I want to achieve results for the company and be efficient with my time. Please ask sales and/or marketing to set up meetings for me in advance. I don’t mind doing booth duty, presenting, or any other way I can contribute. I do mind unscheduled time randomly wandering the hallways, I’ve found this to be ineffective.

Each year I want to attend the Linux Foundation Member Summit (formerly the Open Source Leadership Summit). Please ensure:

1. We submit at least one talk.
2. We book the on-site hotel on the day it opens up.
3. We let the sales team know we would love to set up meetings and schedule these with my EBA at least a week before the conference.
4. There is same timezone EBA coverage during the conference.

If I am asked to keynote a conference, it is up to the executive of the function asking me to attend to decide. For example, if the request is coming from marketing, the CMO decides; if the request is coming from Finance, the CFO decides. Please follow the process outlined under [meeting request requirements]({{ ref “eba#meeting-request-requirements” >}}) and work with my EBA who will shepherd the decision about whether or not I will attend.

Teleprompter Preferences

If possible, I use a teleprompter when giving keynotes. I prefer to use the teleprompter app “PromptSmart” along with the “PromptSmart Remote Control.” Ideally, someone will scroll through the script on my behalf, at my pace.

Recording Content for Conferences

I’m always willing to record video content for conferences I’m unable to attend. Email my EBA to coordinate the recording.

Favorite Beverages

Often when attending an event, the organizers will reach out to see if I want a certain snack or drink. If possible, I would prefer:

1. Non-Carbonated Celsius. For example: Celsius Raspberry Acai Green Tea

Home Office Setup

People regularly ask what I use for my home office setup. Below is a list of the items I use:

• Microphone: Shure MV7
• Boom Arm: RODE PSA 1 Swivel Mount Studio Microphone Boom Arm
• Camera: Sony Alpha 7C Full-Frame Mirrorless Camera - Silver (ILCE7C/S)
• Camera Adapter: Tengdaxing NP-FZ100 AC Power Supply Adapter
• Camera Holder: Heron - 3FT Camera Mount with Desk Clamp
• Ports: CalDigit ts3-plus
• Desk: Jarvis Laminate Standing Desk
• Laptop: 13-inch MacBook Pro
• Stand: rain design mStand
• Keyboard: Apple Magic Keyboard
• Mouse: Microsoft Pro IntelliMouse
• Monitor: Apple Pro Display XDR and/or LG Ultrafine 5K
• Light: Elgato Keylight
• Green screen: I use a cloth one. Roll Down/up screens are a space saver but can be on the small side. Painting the room has mixed results because different surfaces reflect light different even with the same paint.

Note: I have paid for all of these items myself. Please refer to GitLab’s expense policy for office equipment and supplies when purchasing and expensing home office items.

CEO Voice

When preparing scripts or documents in my voice, please follow these guidelines. This list can help you prepare a draft that is as close as possible to my natural way of communicating. For additional information or questions, please contact the #external-comms Slack channel or the Chief of Staff to the CEO.

1. Avoid “we” or “our” when discussing the product. I don’t wish to speak on behalf of others or to imply that GitLab team members are owners of GitLab or its users. Everyone can contribute = everyone has some ownership of GitLab.
2. Less is more. If you can say something in fewer words, do so. I prefer speaking in shorter sentences.
3. Always be inclusive. No gendered terms if it can be avoided.
4. Be as direct and specific as possible. Don’t assume the reader/audience knows what you mean (low-context communication). No vague statements.
5. Remove unnecessary words, assuming statements or lead-ins that don’t add value. Ex: “As you know.”
6. When writing a script, read it out loud. If it’s not easy to say in one try, edit the script to make it easy to speak.
7. Any time you make a statement, consider whether there exist any data/proof points to back it up, and include the proof. This proof might exist internally through work our teams are doing, or externally through analyst reports or other such reporting.
8. Familiarize yourself with GitLab’s Misused Terms and avoid using these. For example, always use “Team members” instead of Employees.
9. Run text through a readability checker, such as the ones on this page. Aim to have a Flesch Reading Ease score above 80. This is the score for a document that is “easy” to read.
10. No interrupters. Interrupters are little thoughts in the middle of a thought and they complicate sentences. So use ‘Q2 was a great quarter. I am pleased with the results.’ instead of ‘Q2, happily, was a great quarter.’
11. Be exact, not approximate.
12. Don’t sugarcoat bad news.
13. Celebrate, but don’t boast or brag.
14. Rarely make comparisons to other people, especially negative ones. Comparing to competitors is fine, usually in the context of highlighting what differentiates GitLab.
15. Explain the why.
16. When providing slides for me to present, follow the presentations and slide decks guidance.

Transport

The CEO will pay for all transport expenses (flight, Uber, etc.) personally. By default flying business class. On short flight with other team members fly economy if we can sit together, in this case still pay personally.

Three levels of performance

There are three levels of performance:

1. Commitment: what we promise to our stakeholders.
2. Aspiration: want to get to 70% of this, these are our OKRs
3. Possibility: what we are intrigued by, inspired by, and what I talk about

I’m driven by what is possible, the aspiration, what can be. Others’ expectations of a person affect the person’s performance with high expectations leading to better performance, this is called the Pygmalion effect. What is possible is more than what we are satisfied with or what we promised to our stakeholders. We can be above what we promised and below what is possible and still have done a good job, we can win without doing everything we aspired to do, or everything that is possible. It is unlikely that we win without doing what we promised. I have to be clear in distinguishing these level when I discuss a goal with my reports.

How do we keep shipping

One of the hardest things in business is not to slow down as the organization grows. An applicant asked how we manage to do this and these are the factors that come to mind:

1. Don’t ever slow down because it is very hard to recover from that. As soon as you stop shipping (for a big refactor, a security initiative, etc.) it is very hard to get back up to the old speed. The organization has accepted a slower rate and there are always enough reasons to go slower. You have to do the refactors and other things during the course of business, never slow down.
2. Everyone in the business wants to do the right thing for the existing users and customers. The problem is that people already using you prefer stability in scope over change in scope. You need to optimize for all people, both the current users and people not using GitLab yet because it is missing features.
3. Separate execution from goal-setting. At GitLab, product decides what to ship and engineering is responsible for shipping it. Both report in to the CEO. If you have a head of product that also runs engineering, they are more likely to slow down because it will make engineers’ tasks easier.
4. Separate decision making from giving input. As detailed in our handbook we leave the decision to the person doing the work or their manager, this prevents the need for exponentially more coordination as we grow.
5. We iterate so that we keep learning quickly and reduce the risk of decisions.
6. We have functional teams that make us efficient but as mentioned in that text we promote organic cross-functional collaboration by giving people stable natural counterparts.

Evolution of the handbook

As the company keeps growing my use of the handbook is also changing.

1. Until 20 people I mostly did things myself.
2. From then on I focused on documenting things in the handbook.
3. Then I asked people to document things.
4. Now we documented to document it.

Iteration Office Hours

These office hours are an opportunity for GitLab team members to discuss how to take a more iterative approach to a specific activity or to highlight how a more iterative approach helped drive results. Iteration is one of the hardest things to learn about working at GitLab and these office hours are a great opportunity for me to help coach folks who are interested in better understanding it. We learned iteration at YC, where we took our plan for the next 3 months and compressed it into 2 weeks. Give yourself a really tight deadline and see what you can do. The smaller we split things up, the smaller steps we take and the faster we can go.

External Networking

I keep in touch with various industry leaders on a regular basis (monthly, quarterly or annually). They are people who have accomplished extraordinary things at prominent companies such as hypergrowth hiring, ambitious revenue growth, or created transformative technologies. In these meetings, I get to learn from and know senior leaders within the industry. This helps me to understand what great looks like as it offers me a lens into other companies and what has made them successful or held them back. I ask questions about how they would approach GitLab’s current challenges or opportunities. I often share insights from my conversations with functional leaders and other team members.

I have these conversations across all functions because it is important for me to have external, subject-specific mentors. Better understanding individual functions helps me set better targets, ask better questions, and be a better partner to functional leaders. This allows me to be a better manager and CEO.

I try to prioritize people from underrepresented groups, because I see value in learning from folks with different backgrounds. These same folks may eventually become GitLab team members who would add diversity to GitLab.

CEO scam

See CEO and executive fraud in the security practices section of the handbook.