The Nuts and Bolts of Working for an All-Remote Company
Conventional companies new to remote working can learn from the successful start-up GitLab, which has never had an office since its inception in 2014.
This article is part of a series titled “The Future of Management”, about how changes in culture and technology are reshaping what managers do. INSEAD professors Pushan Dutt and Phanish Puranam serve as academic advisors for this series.
Thanks to Covid-19, all-remote companies – that select group of (mainly tech) firms that function without a physical location of any kind – have gone from eccentrics to exemplars in the eyes of the larger business community. Companies contemplating a possible open-ended future of obligatory remote working for much of their staff would do well to learn from these elite early adopters.
INSEAD professor Phanish Puranam and post-doctoral fellow Marco Minervini’s ongoing research into software development start-up GitLab explores how a company with no office and more than 1,200 employees scattered across more than 60 countries can successfully manage itself. Emphasis on the word successfully – in September 2019, GitLab was valued at US$2.7 billion ahead of an IPO set for November 2020.
Puranam and Minervini’s soon-to-be-published INSEAD case study “GitLab – Can ‘All-Remote’ Scale?” takes a close look at the company’s day-to-day operations, imparting a strong sense of what working life is like for its global staff of digital nomads.
GitLab: The basics
There is a hall-of-mirrors aspect to GitLab. Its core product is a set of “continuous integration” (CI) tools for collaborative coding that GitLab’s own employees use every day in their projects. Essentially, these tools help solve the coordination challenges affecting dispersed teams of developers, by automating the process by which individual contributions are assimilated into the existing code base. This saves the expense (in terms of time and money) of having a human being check the compatibility of each new line of code with overall group output.
In other words, not only is GitLab a pioneering (formed in 2014) all-remote company, but it is also at the forefront of creating the invisible infrastructure that would allow much of the tech industry to abandon physical offices too.
Read More: Are Offices Obsolete?
Onboarding
GitLab emphatically does not treat its people like glorified gig workers. It aims to replicate the intangible benefits of conventional employment (cultural cohesion, collective identity, etc.), while reinventing the work experience to suit the decentralised paradigm.
CEO Sid Sijbrandij knows that the onboarding process is critical to employees’ future success with the company. New team members spend their first week getting up to speed on GitLab’s unique culture and working style, rather than jumping right into project-based tasks. In most companies, the employee handbook is reissued on a yearly basis at best, and copies mostly sit unread in desk drawers. GitLab’s, by contrast, is a living digital document updated constantly and available to the public. Before writing any code whatsoever, rookies are expected to familiarise themselves with the handbook and complete a series of administrative tasks meant to smooth their entry into the organisational network.
Also towards that end, new hires are required to initiate virtual meet-and-greets with at least five other employees (preferably from other departments and time zones) during the first week. All GitLab employees, regardless of length of tenure, are encouraged to chat with one another informally several times a week. For those who might be introverted, shy or feel awkward, planned spontaneity primes the conversational pump, in the form of twice-weekly “take a break calls” in which participants choose what to talk about from a rolling list of five topics. Further satisfying the need for social interaction, GitLab’s Slack dashboard features channels dedicated to non-work topics such as gardening.
“Asynchronous and public”
The company’s “Git-based workflows” take some getting used to. They are designed to facilitate what GitLab calls an “asynchronous and public” process, ideal for teammates scattered across the world, who may communicate in real time erratically if at all. Full transparency is necessary so that projects can continue despite being attended to by different sets of developers over the course of 24 hours. Ideally, this should result in heightened productivity, compared to conventional co-located teams that are totally logged off for as much as two-thirds of every working day.
The pursuit of full transparency is behind one of GitLab’s most countercultural rules: a total ban on internal emails. For example, employees seeking information or help are required to request it through the appropriate Slack channel, which may eventually trigger changes to the employee handbook or another key document. The intent is to crystallise and capture the pooled expertise of the collective, rather than letting it slip through the organisation’s fingers. In this way, GitLab aspires to be a company where nothing valuable is lost or wasted.
Further, these workflows have a bias towards “minimum viable changes” instead of completion. Employees are encouraged to lock in their work via merge requests to the code base at each significant step, enabling others to keep track of their activity and, if appropriate, contribute (presumably pushing the project forward faster). In asynchronous (i.e. time-lagged) environments, it pays for employees to be liberal about what they expose to the light of day, because work done in darkness may invite costly redundancy and knowledge gaps.
Hierarchy
As I described in a previous piece about all-remote working, GitLab’s transparency doctrine ensures near-total availability of salient information throughout the organisation – but that does not necessarily translate into democratised decision making. Indeed, the company has a fairly standard-looking org chart. Like team leaders everywhere, GitLab’s managers are responsible for assigning and prioritising tasks to employees (the in-house term for this is “triaging”).
Managers are free to triage however they see fit. The case study covers several approaches. For example, one manager prefers to raise proposed issues or problems for group discussion within a shared document. After everyone’s feedback has been submitted and absorbed, this manager converts the items into tasks for specific team members to tackle. Another manager opts to generate tasks herself with no prior input, but allows employees to choose what they’d like to work on.
Once assigned to a task, an employee may be granted “directly responsible individual” (DRI) status, making them the final authority on the matter. GitLab’s cultural norms encourage open-minded solicitation of feedback, but the DRI is entirely empowered to adopt colleagues’ suggestions, or go with her gut. The flipside, of course, is that she and no one else will have to answer for the success or failure of the task she’s responsible for.
In addition, changes to the code base or handbook are never automatically accepted, but must first pass muster with a “maintainer”, or an authorised employee with expert knowledge of the area the proposed change pertains to.
Are we all GitLab now?
Of course, a gulf lies between GitLab and most companies that have had all-remote working forced on them. As mentioned above, GitLab’s “asynchronous and public” way of working stems from the need to coordinate team members when their ability to communicate cannot be taken for granted. Conventional companies do not have this challenge. Their employees live fairly close to each other and to the temporarily unavailable office. They can hop on a Zoom call at a moment’s notice.
Even so, Puranam and Minervini’s research suggests GitLab’s style should perhaps be more widely emulated. Asynchronous tools are more flexible, they observe, despite being much less popular with companies that are relatively new to remote working. Freeing employees from the temporal chains binding them to one another and the company restores their autonomy and enables them to set healthy work-life boundaries. Full transparency, a focus on “minimum viable changes”, etc. are apt adaptations to our new normal of tele-working that can act as a buffer against mounting Covid-19 burnout.
Check out more articles on what could be the future of the work landscape with the app Necole. Necole is an Artificial Intelligence (AI) powered learning app that that curates personalised learning just for you.
Functional
Tags: Case Studies, Business Model
