This is the third value covered in a series of blog posts on what we can learn in implementing values that are the same or similar to GitLab’s CREDIT values. For background and links to the other posts, please check out the overview post.
Efficiency
There’s a lot of overlap of efficiency with the other values, but I’ll try to focus on how efficiency is improved even when mentioning examples from other posts.
Document everything
I mentioned under collaboration that we shared by writing things down in a public manner, which obviously leads to transparency as well. Additionally though, it helps us be efficient.
Often we can find our own answers without having to go through the process of formulating questions and clarifying our questions if they are unclear.
Even if people ask questions about things that are documented, we can often provide shorter answers with a link to more detail. How little or much they read is then up to them.
On a side note, if asked though, people are willing to provide longer answers with a detailed explanation, but hopefully it’s recorded in some way so that others can refer to it later.
If someone reads something and still has questions, then we encourage them to ask and document the answer. It means that we can fill in the gaps, so that the next person doesn’t end up with the same question.
This also helps with iteration since we can keep improving what we’ve written.
Minimal viable change
Minimal viable change (MVC) is a large part of how we produce so many results so quickly, but I’ll touch on this more when talking about iteration.
Approval not (always) required
Whenever we work on something, we take on responsibility and accountability in doing the work and the results. However, I mentioned the degree of trust in getting results, and there’s also a lot of trust in believe that we will involve others when necessary.
A lot of our work can be done without approval, which makes things more efficient. It’s up to each individual to decide when they need peer, maintainer, manager, or another team’s review.
Even if an approval is required, there’s usually a group of people who can take on the role of reviewer/approver. One of the upsides of a global company is that sometimes it happens while you’re asleep (or at least not working).
Meetings and calls, most optional, many ad hoc
At GitLab, there are almost no required meetings. For me, the only regular meetings I need to attend are my 1:1 with my manager, and team weekly meetings.
We do our best to make meetings optional in consideration of people’s time. We take notes, and when possible, we record the meeting and are encouraged to upload it to our GitLab Unfiltered YouTube channel, using the appropriate setting if it can’t be made public outside the company.
One of the main considerations for taking copious notes and recording meetings is that company wide calls will always be inconvenient for people in a range of timezones. Beyond that though, it’s also helpful for people who are out of the office for whatever reason.
Ironically, I attend more meetings now than in any non-managerial job I’ve ever had.
Due to our all remote nature, some calls are more “social” type calls, focused primarily on getting to know other people in the company. In addition to trying to alleviate some of the solitary feel that often comes with remote work, it allows us to get to know people from different departments at varying levels. It makes it easier to reach out to other teams when you’ve got a first point of contact.
In many other cases, I can “peak in” or “shadow” calls. Often it means learning new things, or contributing something where I can, and frequently, I can simply listen with half an ear on what’s going on, especially for calls where I’m not sure anything relevant to me will be discussed.
Of course, as an all remote company, some of our calls are not meetings so much as working together type calls. Since we’re not in an open office setting though, these are much easier to do since we do not physically have to move, and won’t bother other people if we start talking.
In Support, we often do pairing sessions or group “crush” sessions where we work on tickets and issues. Due to the sheer breadth of the product and the composition/size of our team, we often have to ask others for help. During one particular working session recently, we brought in no less than 3 experts, but they joined when asked, and could leave when we were done discussing the single issue we were asking their insights on.
Even with other teams, we can often ask “want to go over this in a quick call?” and just send over a link.
Using our own product
GitLab is an amazing product, and I truly believe that a large part of why we’re so efficient is that we use it for as much as we can.
We still have separate tools for HR, payroll, customer tickets, sales tracking, and others I don’t even know about. So while we recognize that GitLab is not a tool to do everything, we also want to be able to connect everything. We’ve built integrations and included almost everything into the API. We’re working to automate a lot the manual processes that we have.
Regardless, for a lot of day-to-day work, we use and rely heavily on GitLab. By using what we build, we can make sure it works well, and help others. On the flip side, we can also build what we need to be more efficient.
One of the positive side effects is that everyone, from sales to HR to engineering, knows the product at least at a high level, and can say they know what it’s like to use it. I don’t know of many other organizations that can say the same about their products or services.
Take away
Make small changes and be cognizant of other people, especially their time. Don’t bog people down with hoops to jump through. And if you can, make use of your own product, tools, or service for everyone to better understand the organization they work for.
