Recently, we caught up with a Fortune 50 company that wanted to understand how to enact change more quickly, bolster its product management practice, and execute projects more efficiently. This led to a conversation with our CEO and co-founder Sid Sijbrandij, who walked through a few key GitLab practices for improving communication in the workplace. Luckily, I was able to "shadow" this conversation as I was participating in our CEO shadow program at the time. After the discussion, we quickly realized it made sense to share our best practices. While these power our all-remote organization, we think they're good ideas for any company to consider.
Utilize directly responsible individuals (DRIs)
In our organization, we have the concept of the directly responsible individual. And, as you may have guessed, that person is directly responsible for the decision they are tasked with. This could be something routine, such as a prioritization decision (in this case the typical DRI is the product manager) or something bigger, such as choosing a vendor to partner with to implement product analytics. The DRI is expected to become informed about options and alternatives via their team, but is ultimately the one responsible for making the call. This helps because you don’t have to wait for consensus-driven decision-making. Most organizations are slowed down by governance teams or by a need to ensure every single person impacted signs off. While it’s important to communicate, it can slow you down if you wait for everyone to sign off. Consider implementing DRIs to help ensure high velocity decision-making.
Make product and engineering responsibilities distinct
At many organizations, the product manager is responsible for not only setting the priorities, but also must ensure those priorities are shipped on time. This leads to an odd situation where product is held accountable for shipping code, something that is typically outside of the team's control. At GitLab, we clearly outline that product is responsible for prioritizing and defining what is to be done and engineering is responsible for shipping the defined functionality. Setting clear boundaries around what each functional area is responsible for leads to an environment where people can get away from finger pointing and back to the job they should have been doing all along.
Share via InnerSourcing
At GitLab, everything is public by default and there should be a documented reason why an issue or line of code needs to be private. Why? The answer is simple: by making everything public by default, everyone in the community can contribute. Now, we realize public repositories and issue trackers may not be feasible for every organization, but this typically doesn’t apply inside the organization. InnerSourcing is a mindset shift that helps organizations share code and best practices internally. When code repositories and issue trackers become open, teams have a much easier time collaborating on problems and solutions that may be siloed. DevOps is all about breaking down silos and InnerSourcing is a great way to not only reuse code and ideas, but also encourage collaboration.
Write everything down
Can you recall a time where you went to a meeting, made a decision, and then came back next week to find people forgot that happened? Unfortunately, this is too common at many organizations and leads to unnecessary rehashing of the same information, arguments, and talking points. By writing everything down, it’s clear when a decision was made or a process was changed. Writing things down is a high leverage activity – it allows information to be documented once and then disseminated to many people with little effort on the part of the author. It also helps to maintain a record of what happened. At GitLab, we write things down in issues and merge requests. And for bigger things, we have a handbook of over 3,000 pages where we outline how the company works, its various processes, and our product strategy. This single source of truth is also constantly being updated because we encourage everyone to propose changes and additions to it.
Iterate, iterate, iterate
Iteration is one of GitLab’s core values for a number of reasons. When you iterate, you reduce the need for coordination amongst many teams and stakeholders. The smallest change or proposal you make, the fewer people you need to ask for permission. If you are going to take six months to build something, you will need to spend a lot of time getting stakeholder and executive buy-in to ensure resources are being leveraged appropriately. Conversely, if you are going to take two weeks to build something, less buy-in is required and it is much easier to know if you’re on the right path. In larger organizations, coordination is the thing that slows you down. Iterating allows for quicker feedback.
Understand the job to be done
The jobs to be done (J2BD) framework is popular for shifting away from correlation-based models and towards what the customer is trying to accomplish. We heavily utilize our user experience (UX) group to work closely with our product management team in order to identify and highlight the top jobs to be done. We invest heavily in user research to confirm the jobs to be done. The jobs are turned into scorecards which outline areas of potential improvement. These potential improvements are provided to product managers to consider when prioritizing features. The jobs-to-be-done framework is important to identify cross-service workflows such as code deployment which crosses many DevOps stages within GitLab. When you fully understand your users, you’re able to prioritize the improvements that matter, leading to a better product.
While not an exhaustive list, the six characteristics identified above are key to GitLab’s success as an all-remote company. And all of these practices can be taken and adapated for any organization looking to strengthen communication in the workplace or considering a move to all remote.
Most everything we do is publicly available, from our code to our roadmaps to our product management processes. If you’re interested, you can find out more in our product handbook, which outlines other axioms and best practices for software product development. And, as always, if what you’ve just read resonates with you, and you’d like to join the team, let me know. We’ve more than tripled our team in 2019, and we’ll likely be doubling again in 2020.
Cover image by Simon Abrams on Unsplash
