How do udalenka accelerates innovation on gitlab

On GitLab, remote is not a business risk, but a competitive advantage.

I am a product manager on GitLab. I usually do the planning phase of the DevOps life cycle . I came in November 2016 and since then I have been admiring what leaps and bounds GitLab is developing as a product and as a team. Many newbies ask me for coffee about the culture of GitLab, especially about the remote, because we are just working . Over time, my views changed, and I want to tell why the remoteness seems to me not an obstacle, but a competitive advantage. Anyway, for GitLab.

How I got used to

When I came to GitLab, it seemed to me that the remote is a problem to be solved. Or at least control it. I thought it was a risk. For example, I wanted to meet with my team every day. Silicon Valley companies and smart books say you need to meet and communicate regularly, otherwise it’s impossible to create a successful product and win the market. To my dismay at the time, we have never met (and are not going to). And - strangely enough - we fruitfully cooperated and delivered products only on the way. This I definitely did not expect.

Then he began to get used to make products in the style of GitLab , and the remote seemed not so risky. There are, of course, a couple of minuses, but otherwise sheer joy. Here are the pros and cons , if interesting.

In fact, it is not enough to weigh the pros and cons to describe the importance of remote work for GitLab. With remote (and other key components of GitLab) we create innovations very quickly, which means we get a unique competitive advantage. And that's why.

Interdependent components

The remote fit fits so well in GitLab thanks to important interdependent components:

Asynchronous communication

Remote employees are scattered across the planet and work in different time zones. Therefore, we prefer asynchronous communications (usually in text form) , stretched in space and time. In this format, you have to write everything down, and be expressed clearly. Otherwise there is no way, because in a day it is sometimes possible to exchange only a phrase – another. We prefer the text, because on the Internet and modern applications (for example, in GitLab tasks ) the text is suitable for ordering, searching and hyperlinks. Text is easy to analyze and assimilate. This is a very effective form of communication, especially for collaboration.

Transparency

Digital asynchronous messages can be sent as many times as possible, unlike paper documents in the office. We do not fence off walls of each other, as in traditional companies. Our communications and work are transparent by default. Sometimes you have to add permissions and then manage them, and these are extra expenses. If you want to send a message, you need to think about who should receive it, and set up permissions. The recipients of the work is also added, because the content so simply can not get. This is an extra headache, and such things accumulate. We try to avoid them.

And so it is clear that anyone can see your message, even if it does not work here. So it is better to immediately say how to eat.

If everything is transparent to you, telling the truth is very simple, but there is no need to lie. This is not only correct, but also beneficial in terms of long-term business development. For example, and so it is clear that anyone can see your message, even if it does not work here. So it is better to immediately say how to eat, and quickly get used to it. No need to invent a separate version for each, and then also remember that to whom you sent. You have one source of truth, and you won’t get confused in it. There are no others. We usually have this description in the ticket.

Everybody is dancing!

When a single source of truth is available to everyone, everyone contributes . Everyone has the same information, and everyone can work with it. Remember, I said that the sender usually thinks who will receive the message? In our case, something useful can come from where it was not expected. Without transparency, this can not be done: artificial barriers hinder possible cooperation. Sometimes good ideas need to ripen. For example, you expressed some thought, but the conditions for it are not the most suitable. And then it turns out that it is just a matter of time. In the future, someone will dig up this idea and will develop further, using all the open discussions and developments.

When everyone can submit an idea, they become a carriage. On GitLab, sometimes the best solutions to complex problems come from completely different teams. But we still have responsible . They make decisions when we get stuck.

Iteration

How to collect all these communications and teamwork, if they are essentially transactional, distributed and unstructured? We have to work iteratively . Many (including me) think they understand the iteration until they come to GitLab. I constantly see newcomers who are surprised at how extreme we have brought this concept. The product and the code are delivered with minimal fragments so that the developer immediately receives feedback and knows where to work further. On GitLab, you cut off tiny pieces and start working immediately. We, of course, make ambitious plans, but do not dwell on detailed analysis. We just take the smallest task and solve it. Every day expectations, we consider the loss of profits. It is better to do at least something today and immediately get the result. We focus on action .

Every day expectations, we consider the loss of profits. It is better to do at least something today and immediately get the result.

And small fragments have small problems. It is logical that there are more people who want to solve minor problems: taking a look at the ticket description is not a two-hour presentation for you to sit through. And since the problem is transparent by default, anyone can solve it. Personally, I discuss 20–30 problems in parallel every day. I would hardly have mastered it if I had to go to special meetings every time. In the end, I somehow took part in an incredible number of projects. Multiply this by all the GitLab teams, and then by the whole GitLab community, and it’s immediately clear where all these innovations come from on GitLab.

GitLab does not suffer from a remote place, and with might and main it benefits from it.

Finally

I here talked about the endless correspondence and the fountain of ideas. So we work. It happens, newcomers after a few weeks notice that they are completely stuck in all discussions at once. This is not surprising, because we are developing, there are more and more ideas, our network is growing and the links between us are growing. But soon enough, beginners learn to choose only the most interesting. I think this is a good strategy, because good ideas attract more attention, and we trust our collective intelligence. But we still need well-defined roles and responsibilities so that narrow specialists and decision makers push our innovations in the right direction.
direction.

And how do you cope with the remote? Write a comment or tweet at @gitlab .