Building a culture of collaboration in the modern enterprise

Best practices for working in the open

By Cormac Foster

October 28, 2020

How can you overcome the challenges to transparency and build a culture of collaboration in your org?

Even before the recent and sudden shift to remote work, the modern enterprise was changing. Our workforce and customer base are global, and an increasing reliance on software development has created teammates from employees who formerly met only at the company picnic. Complex applications, conflicting business priorities, and a mountain of incoming data have made collaboration increasingly difficult, but even more critical.

GitLab has been all-remote since our inception. Collaboration isn’t the only challenge of managing an all-remote business (we’ve written an ebook on that topic if you’re interested), but it might be the biggest. With nearly 1300 team members in more than 60 countries, a large open source project, and a global customer base, making sure everyone can contribute takes planning, effort, and diligence. We’ve found some collaboration practices that work for us, and we hope they’ll work for you.

Key challenges to effective collaboration

Information discovery

The truth is out there – we’re just not sure where. For decades, businesses have fought against data silos by enforcing documentation practices and creating systems to aggregate information. Over time, that documentation grew stale and redundant, and those systems became their own silos. Confronted with piles of potentially inaccurate data, users resort to ‘asking someone who knows’ and bypassing the ‘correct’ process altogether. Users need to be able to find accurate, trustworthy information fast, or they won’t try at all.

Data fatigue

When everything is a crisis, nothing is. Pushing data and alerts can exhaust users, and too much information will force users to ignore it entirely, and seek out alternative sources for answers. At its best, this is inefficient and scales poorly. At its worst, this reinforces incorrect information, creates traceability gaps, and increases employee frustration.

Synchrony

8:00 AM in Seattle is 8:30 PM in Bangalore. Vacations happen. Children get sick. While some situations (e.g. pair programming or a crisis room) will always require real-time interaction, forcing synchronous communication as the norm dramatically reduces the window of available collaboration, compromises worker happiness, and almost always results in poor outcomes.

Cross-functional breakdowns

Businesses can no longer just ‘throw a spec over the wall’ to IT. When software is your product, developers and business stakeholders must work together throughout the entire development lifecycle. Legacy concepts like ‘cost centers’ and ‘revenue centers’ can hamstring that teamwork, as can incompatible goals, terms, and systems. Without a common language (or at least a way to map ‘story points’ to ‘dollars’ and ‘sprints’ to ‘quarters’), the team may never even begin its work.

Collaboration tips from GitLab

Create a single source of truth

Collaboration is about process and culture, but tools build a foundation on which that culture can flourish. The core of that foundation is a Single Source of Truth (SSOT) – one repository for all relevant information. An SSOT is a universally acknowledged ‘good idea’ – but like many good ideas, it’s often implemented poorly. Too often, the SSOT is simply an output (e.g. ‘it’s all in the manual’) but lacks the contextual information to be an effective basis for true collaboration.

At GitLab, for example, our handbook is the SSOT for the way we do business, but it’s also a living, growing document with more than 4,000 pages and many updates throughout the day, every day. To manage that kind of constant evolution and understand where we want it to go, we need to be able to understand not just where we are, but where we’ve been.

Unsurprisingly, GitLab (the company) uses GitLab (the product) to manage our handbook and collaboration around it. We’re big fans, and we think you might be, too, but regardless of the tool you choose, it needs to perform the following functions:

Versioning. For many reasons, from understanding the ‘why’ behind the current state, to rolling back to a Last Known Good configuration, to satisfying compliance requirements, you need a historical record of every change of every record, document, or piece of code.
Contextual association. The system should store and associate relevant inputs that led to changes and relevant outcomes from those changes. For example, a history of code changes should also include related requirements and discussions about how to apply them; a list of code committers and approvers; actions taken before commits; the results of any tests prior to deployments; and the impact of those deployments on performance and usability. It’s a lot to associate, but building a system to do so will lead to substantial improvements in productivity and significantly less friction during audits and retrospectives.
Integration. Even if all work doesn’t take place in your system (for example, if you use one vendor for project management and another for source code management), the systems should integrate tightly enough to retain information throughout the lifecycle of planning to delivery.
Actionability. High-level reporting only takes you so far. From anywhere in your system, users should be able to drill into actual work items to contribute.

Desynchronize

GitLab employs a conscious bias toward asynchronous communication. Because of our geographic distribution, and focus on results and efficiency, we’ve embraced the idea that asynchronous communication is actually an asset. To enable that, however, we’ve needed to shift core attitudes about the way a business should work.

Our handbook provides comprehensive documentation of our processes, but some key features include:

Documenting everything, whether we’re planning goals or providing opinions. All work should happen in writing as publicly possible, to provide immediate context, and to encourage cross-collaboration.
Enabling self-empowerment. Spending the extra time now to build documentation and systems that scale to allow large numbers of people to locate, process, and contribute later.
Minimizing meetings. Attendance at most meetings is optional, and planners should share detailed agendas in advance to allow asynchronous participation. Meetings should be recorded and shared, wherever possible. Everyone in attendance takes notes.
Avoiding DMs. Whenever possible, rather than sending direct messages, team members should @mention relevant teammates in shared channels. This allows others to choose to participate asynchronously and creates a historical context to which additional team members can be added.

Think globally: find common ground in data and value

With the SSOT in place, you can begin the work of building a shared language of value and expand the concept of a self-organizing, cross-functional team to stakeholders from across the company. Different groups will always have needs, and not all of those can be aligned, but everyone should commit to a common understanding of customer value and a bias toward hard data.

Framing your specific needs in terms of customer value will help others understand your sense of urgency or concern. For example, it might be hard for a product owner to justify spending cycles on ‘addressing technical debt’ at the expense of feature development, but ‘reducing change failure rate by 50%’ will deliver more value to customers more frequently, and could be worth significant investment.

Act locally: MVC + DRI = iteration

At GitLab, we think small. Very small. We’ve embraced a concept called the Minimum Viable Change, or MVC. An MVC is the smallest possible change you can make that adds value and improves outcomes for the user. It could be a single line of copy on a web page, or a formatting change in a form field that improves readability. If it adds value, we do it, and we do it now. By making the change, we can solicit feedback on real outcomes and impact, rather than engaging in rounds of theoretical what-ifs. If it works, we build on it. If not, we roll back the change, gaining valuable knowledge and losing minutes or hours instead of days.

The MVC works because we’ve also established Directly Responsible Individuals (DRIs) for everything. Every web page, product feature, and business process has a DRI, and it’s usually the person closest to the work – not the person highest on the org chart. That means everyone, wherever they are and whenever they’re working, can act as they see fit to push us forward, and we can all build on the work of others without being in the same time or space. With the rapid feedback these frequent iterations encourage, we can course-correct constantly, so we’re delivering more value, more frequently, and with less time wasted on fruitless efforts.

If you’re looking to do something similar, we have a few pieces of advice:

Execute. The best way to advance an idea is to actively contribute. Collaboration is not consensus. DRIs have a responsibility to act so others can react.
Version everything. Not all your DRIs’ choices will be correct. If you can roll back your changes as you learn, you can embrace failure as a learning experience and use it to validate your decisions.
Work in the open. Transparency is a core GitLab value. By default, we work in the open, making issues and code changes available to the public for comments and collaboration – working confidentially only when necessary. Every business has a unique tolerance for this kind of arrangement, but greater transparency results in more context, more collaboration, and ultimately, more effective use of time and resources.
Be excellent to each other. This kind of collaboration requires constant feedback, and not all of it is affirmative. Build a culture of respect and trust that delivers feedback constructively, and encourages recipients to assume positive intent.