I’m a Product Manager here at GitLab, primarily contributing to the Plan stage
of the DevOps lifecycle. I joined in November 2016 and I’ve witnessed incredible
growth in GitLab the product as well as GitLab the team. Many
new hires have asked me during coffee chats
about GitLab culture and remote work in particular, since we're an all-remote
company. My view has evolved over this time and I wanted to share specifically why I think
remote is not a challenge to overcome, but actually a competitive advantage, at least for GitLab.
A remote journey
When I joined GitLab, I thought remote was a challenge to overcome or at least
to manage. It was a risk to be mitigated. For example, I really wanted daily standup
meetings with the engineering team I was working with. Silicon Valley-style tech
companies and product management books tell us that frequent, synchronous, face-to-face
communication is necessary for building successful products efficiently and to win
in the marketplace. To my dismay at the time, we never had in-sync standups (and
my team today still doesn’t have them). But curiously, we nonetheless had immense
collaboration and continued to ship product at a high velocity. Something really
weird and unexpected was going on.
<%= partial "includes/blog/content-newsletter-cta", locals: { variant: "a" } %>
Later on, as I started getting comfortable doing product the GitLab way,
I started to think that remote wasn’t really a risk, but that there were just a
few negatives, and that the overall effect was net positive. See the advantages and disadvantages of remote.
Today, I realize that even a positive-negative accounting of remote is insufficient
to articulate what remote means at GitLab. I think that remote
(along with a few other key crucial GitLab ingredients) gives us a differentiated
and competitive advantage, in particular allowing us to innovate at a rapid pace
that is truly unique. Here's why:
Interdependent ingredients
There are a several crucial and interdependent GitLab ingredients that make remote
truly work in our favor:
Async communication
Remote implies geographic diversity (since we hire all over the world),
and because most folks work during the day, that further implies time zone diversity.
Consequently, we prefer Async communication (primarily with text) as we scale our organization in
space-time. Async demands everything be written down and that it be clear and concise.
You can’t afford a prolonged back-and-forth conversation because every round-trip
transaction is possibly 24 hours in the worst case. In particular, we prefer text
because the internet and modern apps (for example GitLab issues) has allowed text
to be easily organizable, searchable, and even hyperlinked. Text is easy to parse
and thus consume. It is a highly efficient form of communication, especially for
transactional collaboration.
Transparency
The async communication we reference is also digital, making it infinitely
scalable. Unlike the printed page in a physical office, anybody should
be able to access a digital message. So, rather than re-erecting the walls and silos
that plague traditional organizations and inevitably block collaboration, we
make communications and work transparent by default.
Adding a layer of permissions is necessary sometimes, and in those cases it becomes an overhead cost to manage
and use (for example fixing a security bug.) The transmitter of communications
needs to figure out who should receive, and set the appropriate permissions. The
receiver themself needs additional work to access the content. It’s more pain. It
adds up. So we try to avoid it when we can.
Because you know everything you write down will potentially be viewed by anyone – inside or even outside the company – simply telling the truth is the optimal and most efficient strategy
Transparency also makes it really easy to tell the truth, and disincentivizes dishonesty.
Telling the truth is simply the right thing to do, but it’s also a great strategy
to grow a long-term sustainable business. In particular, because you know everything
you write down will potentially be viewed by anyone in the company or even outside
the company, simply telling the truth is the optimal and most efficient strategy
and you will thus adopt it with little friction. You don’t have to make up slightly
different versions for different stakeholders. You don’t have to keep track of all
these versions. And you only need a single artifact to document that one source
of truth, which will never be out of sync, because there’s only one! For
us, that single source of truth is typically the description in an issue.
Everyone can contribute
With a single source of truth that is consumable by anybody, it allows everyone to contribute.
Everyone has information parity. And so anyone is welcome to contribute. In fact,
remember I mentioned above that the transmitter of information typically has an intended receiver
in mind? In this case, oftentimes somebody who they didn’t expect can even participate
and add value. This isn’t possible if there’s no transparency because artificial
barriers pre-close the opportunities of potential collaboration. Also, everyone
can contribute means future folks can participate too. You may start a conversation
on an idea that turns out to be suboptimal in the current circumstances. But it
might end up being just a timing issue. And so posterity might be able to recover
the old idea and ship a feature later on, taking advantage of all the discussions
that were had and made available publicly.
Everyone can contribute also means that the diversity of ideas skyrockets. And so
at GitLab, people often cross departments and offer some of the best ideas to solve
big challenging problems. But we still have directly responsible individuals
to make decisions in order to avoid analysis paralysis.
Iteration
Finally, how can all this communication and collaboration truly function if the
mechanisms are so transactional, distributed, and unstructured? It works because
it forces us to be iterative. Most people think they understand iteration (myself
included) before joining GitLab. But I’ve discovered over and over again that new
folks are surprised that this concept is taken to an extreme. Product
and code are shipped in the absolute smallest piece possible in an effort to get
feedback and momentum. Implementing programs and processes at GitLab means breaking
off the smallest chunk and then putting it into action right away. We still make
big, bold plans and big bets on the future. But we don’t obsess over extended analysis.
Instead we find the smallest thing that we can do now and we do it. We believe that
waiting until tomorrow is an opportunity cost. Doing something small today is low
risk and results in immediate feedback. We have a bias for action.
We believe that waiting until tomorrow is an opportunity cost. Doing something small today is low
risk and results in immediate feedback.
And so if all our communication and collaboration is focused on small iterations,
the scope of a typical problem is small and manageable. And it turns out (unsurprisingly)
more people are willing to participate in a small problem if it literally takes
them a few moments to voluntarily glance at an issue description, instead of being
forced to attend a two-hour slide presentation explaining a big problem.
And since the problem is made transparent by default, the pool of contributors is
very high, as mentioned earlier. Personally, I am actively involved
in at least 20 to 30 parallel problem conversations on a daily basis. It is impossible
for anyone to achieve that level of productivity if all to those conversations required
dedicated, ongoing, synchronous meetings. This results in an incredible rate of collaboration
for myself. Multiply that by all team members at GitLab, and then also all GitLab
community members further still, and you can see now why GitLab’s pace of innovation
is ridiculously high.
Remote is not a challenge for GitLab to overcome. It’s a clear business advantage.
Ending caveat
The picture I’ve painted here is one of constant messaging and wild ideas. And
that’s intentional because it’s true. New folks joining GitLab often are inundated
by the number of discussions they find themselves involved in after several weeks
in. This is indeed an ongoing risk for GitLab especially as we scale and the level
of ideation grows exponentially in relation to headcount (since communication links
grow exponentially as nodes in a people network grow). I’ve observed that GitLab
team members usually figure out a way to cope soon enough, and typically become
more selective in their communications over time. I think this is a good general
strategy overall, because good ideas tend to get more attention, and we essentially
rely on the wisdom of the crowds to surface them. Of course we still have well-defined
roles and responsibilities that serve as guardrails too, that allow subject matter
experts and directly responsible individuals to strategically guide our innovation
in the right general direction.
How are you making remote work work? Let us know in the comments or tweet us @gitlab.
Cover image by amseaman on Unsplash
