This is the sixth 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.
Transparency
I have never encountered an organization that was more open and transparent as GitLab. Some people have called it “aggressively” transparent, but that has a negative connotation. Instead, some have suggested calling it “active” transparency because we constantly and intentionally making things as transparent as possible.
Kindly direct
I talked about this already in the collaboration post, but I think it’s worth reiterating briefly. Giving and receiving feedback in a timely manner is important. We do it in a straightforward, clear manner while also doing our best to be kind about it (and the receiver should assume positive intent). While it’s not always easy to do, it prevents negative feelings from building up, and builds a further sense of trust between team members.
Open source
The most obvious aspect of our transparency is that GitLab, the main product and the related tools are open core/source and publicly viewable. The main product is in large part open source, with many licensed paid features, which are unlocked with a license. However, even though they are paid features, because it’s a public project, all the code is viewable.
Along with the code, there’s also all the issues, primarily consisting of feature requests and bugs. In most organizations, development work and project planning are all private. You can provide feedback, but that feedback seemingly goes into a black hole. Instead, for GitLab, users can vote and comment. For bugs, the developers often answer questions directly on the issue to help users.
While Support often has to educate customers to get them used to us closing tickets in favour of issues, they can see the benefits of having the experts answer questions directly, whether that be engineers trying to solve bugs, or product managers prioritizing and understanding feature requests. It also makes Support more efficient because most of the time, we don’t have to be a middleman between customers and everyone else, instead we’re pipe fitters connecting users to the people who can fix or implement product features.
Saving time
One result of our transparency is being more efficient. In general, we save time by not having to ask people information that we can find ourselves.
We also make use of our Slack channels to ask questions so that anyone can answer, which gets answers faster, and not rely on a single person.
Public by default
In general, everything we do is public by default. Aside from the typical public facing things like the website and social media accounts, we have:
- our handbook, which is a guidebook on how we work, including OKRs and KPIs,
- GitLab Unfiltered, where team members can upload any recordings (public by default, set to private if necessary) including meetings, product and team updates, tutorials, and more,
- GitLab organizational tracker, where as the gitlab-org group is primarily for GitLab products and the like, our gitlab-com group is for internal or team discussions, and where a large proportion of decisions are documented.
If something can’t be public, then it’s available company wide by default. For example, each month, every GitLabber and board member receives the investor’s update, which includes our sales figures and brief budget updates.
Some things obviously remain private, such as employee records and various legal or finance issues. Nevertheless, more often than not, the process of how something is done or decided is documented in our handbook, or we provide not individual specific information, such as the salary formula and range for each position.
Single source of truth
In large part as a result of our transparency, we have a single source of truth (SSOT). For the most part, discussions happen in issues, and if not, we try to summarize real time discussion and decisions (whether Slack or video) as comments in issues.
Having a SSOT makes us more efficient because we can make a change in a single place. Different departments don’t have to keep a copy for their own reference because even if the information is “under” another department, it’s viewable to them and editable. Depending on where it is, we can refer to it by linking or have the system duplicate it automatically (always bringing fresh edits).
It also brings about a sense of trust that if something is documented, then that’s the current “truth”, without worrying if the copy they’re looking at is out of date or possibly wrong for some other reason.
Take away
The level of transparency at GitLab is very refreshing. While many organizations claim to be open or transparent, and most public organizations, especially government, should be open, there can be a great lack of transparency even within an organization. Having a high level of transparency helps to build the sense of trust, and increases collaboration, and efficiency as well. I can only hope that more organizations will adopt “active” transparency in the future.
Thanks again for reading, especially if you’ve gotten through the whole series!
