This is the second 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.
Results
One of the interesting parts of being in an all remote company is that there’s no one tracking who is in the office when and for how long. Flexible hours are lauded as a benefit, so team members are generally expected to work a certain number hours, but they get to choose when to put in those hours. Of course, since we don’t track our hours and there’s no office to track hours of physical presence, we focus on measuring results.
Meeting KPIs as a team, no individual quota
At GitLab, one of the ways we measure how we’re doing is using Key Performance Indicators (KPIs). The support team has a number of KPIs though in our weekly reviews, we focus primarily on those to do with Service Level Agreement (SLA) response times and customer satisfaction (CSAT) and our Objectives and Key Results (OKRs) often reflect that.
At a lot of organizations, support and similar roles are measured at the individual level. Many team members have shared that one of the reason they left the previous organizations they worked for was due to individual quotas that they had to meet. I’ve heard up to 100 tickets a day, which makes me wonder how you have time to do anything else, even checking your own email, or properly reading and answering someone’s message. One company I applied to previously said their quota was 60 customer emails per day.
When reviewing how we’re doing, our managers focus on how the team is doing, and what we can do as a team to improve.
Quality over quantity, using time as needed
At GitLab, thankfully, everyone understands that quality is better than quantity when responding to messages. While not being officially tracked, our managers have brought up reviewing the number of responses on a ticket before it’s solved, and thinking about how we can lower that number. The more completely we can answer a question in fewer responses, the sooner we can solve a ticket, and the better experience we can provide.
As a result, in support, we’re encouraged to spend the time we need to in order to understand the problem. Sometimes it’s a fairly simple matter of reading up on documentation for a feature, but other times we might spend a significant amount of time trying to reproduce the problem. Some might see spending hours on a single ticket seem like a waste of time, but learning and understanding more features of the product is never really a waste of time since it can help answer other questions later on.
Learning and improving
Beyond specific problems, we’re also given time to learn. In support, we have numerous bootcamps for self-paced learning so that we can become experts in a specific topic.
For everyone in the company, GitLab will also pay for coding courses, especially for languages that are relevant to our projects: ruby, rails, and go. Additionally, attendance to relevant conferences is supported as well.
Too many organizations have nothing or very little to encourage and support learning. Even courses in basic use of office software is denied in some organizations when it can make employees so more efficient and productive.
At GitLab, we are encouraged to contribute to any of our projects, and can contribute even more with some coding knowledge. Team members might help in many ways including to automate internal processes, write patches for the product, update documentation, and fix issues on the website.
Career growth path
Admittedly, one reason for self-improvement and learning is to advance in position and career, which in some organizations is impossible to do without official certification or similar, and/or without moving into management.
At GitLab, we can be recognized and get promoted as an IC based on the engineering career framework. Moving to management is not required.
When I first joined GitLab, I knew I wanted to work towards getting promoted to senior level, but figured it would be a long process. In organizations I’ve worked in before, you might be probationary or at least not “tenure” for anywhere between 1-5 years. I’m still amazed that I got promoted in less than 8 months, and for now, still the only senior support agent.
Bias for action and trust
One of the major factors that got me promoted though is the bias for action embedded into our work culture. At some point late last year, my manager explicitly told me that I didn’t need to ask permission or approval for everything, and that
we trust you to contribute.
I mentioned in my post about collaboration that many of the organizations I worked in expected me to get approval or consensus for almost every decision. While I started getting the idea after a few months, it was still a culture shock to be told so clearly that I needed to take more initiative since I was so often told in the past that I had too much of it.
That one conversation changed my work life, and the number of my contributions went up significantly.
Take Away
I believe that one of the major reasons GitLab is so productive is because there is a high degree of trust in getting results. We’re trusted to prioritize our work, get things done, do things in a way that helps the whole organization and/or our customers, and to take action and contribute.
There’s more to how we achieve high output and quality results, but what I’ve included is what’s been most impactful for me.
