How udalenka accelerates innovation on GitLab

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

I am a product manager on GitLab. I usually do the planning phase in the DevOps life cycle . I came in November 2016 and since then I admire what leaps and bounds GitLab is developing as a product and as a team. Many newcomers ask me for coffee about the GitLab culture, especially about udalenka, because we only work like that . Over time, my views changed, and I want to tell you why udalenka seems to me not as an obstacle, but as a competitive advantage. Anyway, for GitLab.

How i got used to

When I came to GitLab, it seemed to me that udalenka was a problem that needed to be solved. Or at least control. 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 is impossible to create a successful product and conquer the market. To my horror of that time, we never met (and are not going to). And - a strange thing - we cooperated fruitfully and delivered products only on the road. I certainly did not expect this.

Then he became accustomed to making products in the style of GitLab , and the udalenka seemed not so risky. There are, of course, a couple of minuses, but the rest is sheer joy. Here are the pros and cons of udalenka , if interested.

Actually, weighing the pros and cons is not enough 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

Udalenka fits so well in GitLab thanks to important interdependent components:

Asynchronous communications

Remote employees are scattered all over the planet and work in different time zones. Therefore, we prefer asynchronous communications (usually in text form) , extended in space and time. In this format, you have to record everything, and be expressed clearly and clearly. It doesn’t do otherwise, because sometimes it’s possible to exchange only a phrase or two a day. We prefer text, because on the Internet and modern applications (for example, in GitLab tasks ), text is suitable for organizing, searching, and hyperlinks. Text is easy to parse and assimilate. This is a very effective form of communication, especially for collaboration.

Transparency

Digital asynchronous messages can be sent as many as you like, unlike paper documents in the office. We are not fenced off by walls, as in traditional companies. Our communications and work are transparent by default. Sometimes you have to add permissions and then manage them again, and this is an extra expense. If you want to send a message, you need to think about who should receive it and configure permissions. Recipients also get more work, because you won’t get to the content so easily. 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’s better to say right away.

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

Everybody dance!

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 they did not wait. You cannot do this without transparency: artificial barriers impede possible cooperation. Sometimes good ideas need to mature. For example, you expressed some idea, but the conditions for it are not the most suitable. And then it turns out that it's just a matter of time. In the future, someone will dig up this idea and develop it further, using all 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 those responsible . They make decisions when we are stuck.

Iteration

How to collect all these communications and collaboration if they are essentially transactional, distributed and unstructured? We have to work iteratively . Many (including me) think they understand iteration until they come to GitLab. I constantly see newcomers who are surprised to what extreme degree we have brought this concept. The product and code are delivered in minimal fragments so that the developer immediately receives feedback and knows where to work next. On GitLab, you cut off tiny pieces and immediately get to work. Of course, we are making grandiose plans, but we are not fixated on a detailed analysis. We just take the smallest task and solve it. Every day of waiting, we consider it a lost profit. It’s better to do at least something today and get the result right away. wefocused on action .

Every day of waiting, we consider it a lost profit. It’s better to do at least something today and get the result right away.

And small fragments have small problems. It is logical that there are more people interested in minor problems: looking at the ticket description is not a two-hour presentation for you to sit down. And since the problem is transparent by default, anyone can solve it at all. Personally, I discuss 20-30 problems at the same time every day. I would hardly have mastered it if I had to go to special meetings every time. As a result, I at least somehow participated in an incredible number of projects. Multiply this by all the GitLab teams, and then by the entire GitLab community, and it’s immediately clear where all these innovations come from on GitLab.

GitLab doesn’t suffer with the remote, but in full benefits from it.

Finally

I here talked about endless correspondence and a fountain of ideas. So we work. It happens that newcomers in a few weeks notice that they were bogged down 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 ties between us are multiplying. But pretty soon, 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 mind. But we still need clearly defined roles and responsibilities, so that narrow specialists and decision makers push our innovations in the right
direction.

And how do you deal with udalenka? Post a comment or tweet on @gitlab .