In December I participated in GitLab’s CEO Shadow program. To say “I learned a lot” would be a massive understatement; it felt like a semester of business school in 2 weeks.
My rotation was particularly unique since I was able to get a behind the scenes look at how GitLab delivers an earnings report; from preparation of the public presentation to responding to analyst questions, and finally sharing the result with employees at our quarterly GitLab Assembly.
In a given week (earnings call or not), Sid meets with members of GitLab’s Executive Group, Chief of Staff Team, product leadership teams, takes Valley Meetings and has coffee chats with a range of individual employees. Outside of GitLab, Sid has founded OpenCore Ventures and The GitLab Foundation; since these are new endeavors, he’s heavily involved in their early stage development and meets with their leadership often. In the case of the GitLab Foundation, it’s encouraging to see the values that made GitLab a success being applied in an effort to provide access to opportunities and training to help people break into the tech industry who normally would never have a chance to do so. It demonstrates that a well-conceived value system can succeed beyond GitLab Inc.’s business model.
Two aspects of Sid’s approach to management and working style stood out to me:
-
Win small (and often): Regardless of the complexity of the topic, the level of confidentiality, or seniority of the audience; the majority of Sid’s guidance was centered around breaking down large challenges into small iterations that can be delivered quickly to create a habit of continuous improvement. Leading with a mindset that prioritizes delivering small, frequent results encourages short feedback loops. Short feedback loops minimize the possibility and impact of mis-allocating resources across the organization, and compels individual teams to remain focused on their own objectives and key results while staying aligned with the company’s vision.
-
Maximize each tool: Between Google Docs, Slack, GitLab and others, there are many different software applications being used day to day. With so many tools it’s not uncommon for them to be under-utilized or for users to employ hacks to invent a feature that does not exist, or does exist and were just not aware of. An example of this was someone had put a date in the filename of a Google Doc that several people had been collaborating on. Sid mentioned this as an anti-pattern for several reasons; first, Google Docs track changes by users with a date and time, you don’t have to do that. Second, what does it even mean - the date the file was created? The date it was finished? Each user of the document might have a different interpretation of that date than its intended meaning. It’s a small example but the idea scales to the biggest platforms and tools (including GitLab); reducing confusion - even in a filename - is a tiny boost to efficiency, and these tiny improvements add up for the individual and multiply when carried across the organization.
Adopting an iterative approach to work goes against the typical “Huge Wins” and “Grand Opening” style of results in professional culture; it forces you to be transparent, even a bit vulnerable to say “this isn’t 100% perfect yet, but here’s the path we’re taking and how long we think it will take to get there”. And while every company strives to be efficient; without clear and intentional guidance on how to maximize the potential of the tools in the arsenal, the efficiency gains are inconsistent at best.
Leading a startup-turned-public company with zero office space and thousands of team members spread across dozens of countries and cultures, requires a unique hierarchy of values in order to continue to scale. I can see how this might not be for everyone, but the value hierarchy has produced positive results for GitLab and each iteration deliberately moves the company further down the path of success.