This is the first 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.
Collaboration
In so many organizations, we encourage and espouse the need for collaboration, but in practice, I have rarely seen collaboration truly embraced as a value. GitLab has redefined the meaning of collaboration for me and made me realize why I so often struggled with the term in the past.
Sharing, by default
In many organizations, collaboration is defined as being willing to share your work and talk to other teams. While sharing is also a large part of GitLab, it goes beyond a simple willingness.
This is partly tied to transparency, since we make things public by default, there’s often no need to ask another team to provide details on an issue because if you have a link to it, then you can read all the details yourself.
This also helps efficiency because people read as much of the details as they need and don’t need to take up the other person’s time to explain what’s happening, which emphasizes our culture of working asynchronously as much as possible (which often times we are forced to do due to timezone differences).
Nonetheless, if people have questions, anyone who believes they might have an answer is encouraged to answer, or to open up a dialogue. Team members also often file an issue for further discussion, or if they have a more concrete idea, will file a merge request (MR) to propose a change.
Those who might be interested in or need to know are mentioned on the issue or MR. For further discussion, the author is responsible for reaching out, but of course, others can bring further members in. Sometimes specific teams or the whole company is made aware of an issue or MR through various means of communication to actively solicit feedback or for awareness. Since most project trackers are public (at least within the company), anyone can subscribe or comment without being explicitly invited and contribute to the discussion as well.
Giving and accepting feedback, being timely and assuming positive intent
At GitLab, when we share ideas or opinions, we assume positive intent. Granted, this isn’t always easy to do, especially if what’s shared is in opposition to your own thoughts or they’re not positive, but we try. We’re encouraged to share diverging opinions and bring up concerns on proposals. We’re also asked to give any more personal not-positive feedback 1 on 1 (1:1) via video if necessary and possible, but will often do it over direct message (DM), and of course, do it nicely.
What’s also important is to provide feedback in a timely manner. Discussions can move forward quickly, so if you feel strongly about something, you should speak up or the decision might be made without you (unless you’re the directly responsible individual (DRI)). Giving feedback to other people as soon as is reasonable is also important so that they can reflect on what happened and can easily discuss how to improve.
Personally, this was a big sticking point for me in some organizations’ cultures. In one organization, I was told that other people didn’t like my suggestions because the solutions came from my experience in organizations and didn’t apply to the current organization. To this day, I can only assume it’s because they felt I was an “outsider” and didn’t understand the needs of the organization.
The biggest problem though was that no one said anything until more than 6 months later. Some negative feedback was written in my performance review, and the situation was cited as an example (orally) when I asked the writer directly. To be fair, that was a single example to a greater problem. Nevertheless, as someone who has been a manager, my belief is that performance reviews shouldn’t have surprises, because people can’t become better unless they know what needs improvement.
At GitLab, we tend to call people out on things if they deviate from what’s written in our handbook (which includes our values), but for me at least, I’ve only become comfortable with doing that because members at every level of our organization have done this (from ICs to the CEO), and we learn a lot by example. I’ve also gotten a lot better at accepting feedback and not taking it personally because I see feedback as a regular, normal activity. As we get better at giving and accepting feedback, it motivates us to improve ourselves and how we work together, avoiding resentment and “walls”.
In addition to positive intent and recognizing that things (especially communication) are on a “two way street”, we try to be as blameless as possible. Many colleagues and I have shared discussions that we should foster an environment where failure is not seen as an entirely negative situation, but one that we can learn from. At GitLab, we do exactly that. When things go wrong, we avoid lingering on who made the decision, and instead focus on what went wrong and how we can improve the situation, both in the short and long term. This also improves results and efficiency since we don’t spend needless time on the blame and move forward with what we need to learn and do.
Not consensus
At too many organizations, collaboration is also conflated with consensus.
I have literally been yelled at for not being a “team player” because I didn’t ask everyone at a certain level of management for agreement or approval before asking an IC whether it was possible to go ahead with something that many staff had been asking for. There were other issues involved in this situation, like that I was stepping on their toes (at GitLab, we try to have “short toes”), but it’s also a good example of how too commonly, there are organization cultures which insist that decisions be made by or with approval from a group in the name of “collaboration”.
Collaborating with other teams does not mean that every decision needs to have consensus from internal stakeholders. At one organization, I was thankful when I managed to convince a committee that I wanted to ensure everyone had a chance to provide feedback, but that I was hoping that they would accept decisions and actions might be taken without consensus (especially between committee meetings) when they were based on need (e.g. security issue), or studies. Study results were reported to the group, and provided a chance for further feedback or questions, but the study results usually made most decision paths and recommendations quite clear. In cases where no study was involved, we worked together to brainstorm ideas, and discuss options. These were great discussions because the different perspectives and considerations meant a more informed decision, but ultimately, whether everyone agreed with it or not, the decision rested with the DRI and the final outcome emerged from that decision.
At GitLab, our decision making process works in more or less the same way.
When we need it
At GitLab, we also encourage people to decide themselves when it’s more efficient to work alone and when to work together. We often find that pairing can increase delivery, but some problems are easier to tackle alone.
Kindness
One of the reasons I genuinely love working at GitLab is because of people’s kindness. Everywhere else I’ve worked, people are polite or civil, but few were kind.
To add to the feedback piece, we encourage positive feedback in public spaces and even have a #thanks Slack channel where people can post their gratitude for things others have done, small (e.g. thanks for answering a question quickly) and big (e.g. landing a big customer deal, or building a feature). On our team, we started a thanks section in our week-in-review which encourages people to thank others on the team and includes a couple of positive comments from our users that come in through our ticket satisfaction survey that week.
In addition to assuming positive intent, people are open to dialogue and interested in getting to know you beyond just work. We’re encouraged to set up coffee chats with people in other teams and regions (and actually required as part of onboarding). While optional, we have a “donut” bot set up to randomly pair people for a coffee chat every two weeks. It doesn’t always work out because some people don’t have overlapping work hours, but it’s been a great way to get to know people whom I might not normally work with. Even outside of donut pairings, people don’t complain that you’re taking up “precious work time” if you set up meetings. While we encourage async work as much as possible (so that people don’t have to work outside their chosen work hours and decisions are captured outside meetings), we also want people to get to know each other, and understand that the connections we make across teams and regions improve our workplace.
Take away
I’ve heard almost every organization say that collaboration is important, but then don’t truly embrace it. GitLab has made me realize what true collaboration looks like in combining numerous things including sharing, positive intent, feedback, thanks, “short toes”, blameless problem solving, and most importantly, kindness.
Phew~ that was a lengthy one. I promise all the other ones will be shorter. Thanks for reading to the end! As a reward, have a group of bunnies working together on a snoozle pyramid.
