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.
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
