Fast-growing companies sometimes need leadership in new initiatives before there's time to hire a team member dedicated to them. This is how we tackled this challenge.
In the last two years GitLab has grown from about 15 people in a handful of countries to now well over 180 people in more than 30 countries. In a company that is growing as fast as GitLab is, there is always some team that needs to be built, or some team to be temporarily led while a leader for the longer term is found, or some initiative to be started that doesn't (yet) fit within existing teams or departments. We can – and do – add people to the GitLab team to tackle these challenges. But hiring takes time and isn't always appropriate for a one-off or early-stage initiative. GitLab is also a fully remote and international organization that moves fast, and we can't afford to wait for these challenges to sit idle.
So who should build that team, be that interim leader, or start that initiative?
At GitLab, we've addressed this with the role of VP of Scaling. The word "scaling" in this case relates to the organization instead of, for example, sales or user-base. Think of the VP of Scaling as a full-time interim manager rotating between vastly different functions, building teams and scalable processes. The job is to "get in" and to figure out how to "get out" responsibly. (As an aside: at first we struggled to come up with a good name for this role and considered everything from janitor/plumber (sweeping /connecting the entire company – vetoed), to Mr. Wolf (fixes problems on demand – too negative), until eventually settling on the key word of "scaling.")
What does the role involve?
A VP of Scaling should be broadly deployable in the company and go where the challenges are. For us, the first task at hand was to scale up our team, starting with our ability to recruit and hire quickly and efficiently. And so it was that I began in the role of Interim Head of People Operations; from sending out employment agreements and setting up an candidate tracking system, to laying the groundwork for our hiring process, building the beginnings of the People Operations team, and developing the first iteration of the global compensation calculator. Once the People Operations team was left in more experienced hands I moved on to help as (interim) Support Lead, followed more recently by time as interim Director of Infrastructure, and currently interim Director of Security.
With each of the teams that I've worked with, the challenges they've faced are a direct result of the success of the company. The Support team "feels" it through more customer tickets, and the Infrastructure team "feels" the increased usage of GitLab.com. Although no two teams are identical, there are some common approaches that I have found to be helpful in an interim leadership role.
Perhaps the most important point is to listen to the team – and to never stop asking questions.
Perhaps the most important point is to listen to the team – and to never stop asking questions. The individuals in our team are smart, they have domain expertise, and they often have great ideas on what needs to be done in order to be successful as a team. Regarding the "never stop asking questions" part, well, I think I've had that bit covered ever since I had the ability to talk.
Coming onboard with a new team, I listen to the concerns and ideas from the team and from the management chain that they report into, and sort the challenges into those that need to be addressed right now (e.g. add more people to the team through hiring or borrowing; unblock a decision on topic X) from those that need to be addressed on a longer timescale. Once the immediate needs are taken care of, with the help of the team and sometimes outside experts we start sketching out what Utopia looks like for this team. What does the team, and the service the team provides, look like in a world where GitLab is 10x more popular? How about 100x?
Once the immediate needs are taken care of, with the help of the team and sometimes outside experts we start sketching out what Utopia looks like for this team.
For example, the Support Team faces the dual challenge of a growing customer base as well as a growing product in terms of product scope and capabilities – straining the team. The "right now" solution involved adding support turbos and hiring people in multiple timezones to spread the customer ticket load evenly. To make it scalable beyond the immediate needs is part of the Utopia for any team. In this case, our Support Engineers iterated quickly with the new hires to enable a mostly self-guided onboarding process as well as self-guided pathways for continuous learning.
Jumping from team to team in an interim role also provides for a great opportunity to help spread best practices from team to team, and to erase or manage "interfaces" between teams. For example, the Support Team feels the customer's sense of urgency around needing bug fixes or feature development, but did not have a great way to effectively communicate that sense of urgency to the rest of the team without just making a lot of noise. So the team came up with a quantitative metric using issue priority labels, with good success. When we noticed that the Infrastructure team – as the largest "customer" of GitLab Enterprise Edition – was having similar escalation problems, it was easy to adopt priority labels for security as well as availability and performance.
What are the challenges of the role?
A key challenge (and attraction) of this role is that I need to get up to speed quickly on areas of the company and product in which I do not have much prior experience. I rely on the kindness and the expertise of the team, and benefit a lot from our dedication to documenting everything (which we do as an integral part of being successful in a remote-only setting). Of course I contribute back to this documentation as well: as we worked on reducing the latency of GitLab.com, I found myself wondering, "What actually happens when a user enters a GitLab.com URL in their browser?" and then documented the answer(s) on our handbook page about GitLab.com performance. Another challenge is, unsurprisingly, that I get somewhat attached to the teams that I'm actively working with. I enjoy learning from them, I enjoy working with and enabling them, and I enjoy getting to know the people behind the GitLab handle. It can be difficult to fully move on to the next assignment, with a few pending issues tenaciously hanging on to my todo list for way too long.
Despite the odd job title and the fluid nature of the job itself, I like to think that it has worked well for us here at GitLab. Do you have a similar role at your company? We'd love to hear about it!
Cover image by Ricardo Gomez Angel on Unsplash
