With GitLab Inc growing to more than 150 people working remotely and steadily increasing, inevitably new challenges come up while building great software.
We never shied away from hierarchy, but recently I’ve been noticing a trend towards more traditional people management in an effort to maintain focus on shipping at scale.
I believe that creating overhead with meetings and reviews is a risk to the efficiency and remote culture of organisations. It should be actively avoided for an organisation to succeed remote at scale.
More people, less productivity
When a team grows from five to 30 to 100 people, some parts of the team will fail at some point: be that in the form of missing a deadline or not delivering quality work. Of course, larger organisations want to solve this permanently. If there already is an established hierarchy, it’s likely that the managers of the failing team will ask themselves:
How could we have seen this earlier?
A senior manager will think back to the old days when everyone was performing well as a small team.
Now, reader, how would you solve this? Obviously this was an oversight by management: they should’ve seen this earlier. The suggested solution might be to improve or create a reporting structure where management reviews the status of projects and teams more frequently. In addition, management should have more frequent meetings in order to review the status of the teams and handle these if necessary.
This is where productivity goes down significantly and remote culture is in danger.
Solution: Set clear expectations
Reviewing work in progress both directly, and indirectly through meetings is a waste of time.
Q: But what happens if things go off the rails? How will I know? Who will handle it?
A: Trust your people.
You must set clear expectations for any and all work. These expectations should include a clear scope, time of delivery, but more importantly: communication expectations. Communication expectations are easily outlined:
- I expect that you will let me know immediately if you think that this deliverable will not make the deadline.
- I expect that if you have doubts about the feasibility, functionality, scope, or outline of this deliverable, you will let me know.
- I expect that if you need help from colleagues, you will contact them and ensure their collaboration. If you get stuck with this, I expect you to communicate this to me.
Now this seems a little verbose – maybe it is, but it makes it very clear what is expected of those responsible. It even seems very obvious, but now that we wrote this down, do the additional reviews and reports still make sense?
Doing this remotely
Doing all of this remotely adds a layer of complexity. We’re fighting with two paradoxical goals: we want to maintain a single source of truth, and we want to be able to give a sense of urgency when working with deadlines, to be able to maintain a certain pace.
In practice this means that everyone is expected to over-communicate. For example, I might say in a GitLab issue to Sytse that our rocket engine won’t make it in time for the planned launch date, but because I know he’s way behind on email and Todos, I’ll also send him a message in chat.
For remote teams, such as our own, I’d add another expectation:
- I expect you to make sure that other parties you communicate with are actually reached.
This means sometimes you’ll have to ask someone else if Jane is absent or send her another message on chat if she doesn’t reply within a reasonable time. From personal experience, being a little more pushy and impatient than you’d be in everyday life is enormously beneficial to this end.
Over-communicating is a small cost to pay for the freedom of working remotely.
At GitLab
I wrote this as a response to observations I made at GitLab. That said, it already was a company policy to look specifically for people who manage themselves. This is what we write in our handbook on this topic:
We don't have project managers. Individual contributors need to manage themselves. Not everyone will be able to do this effectively and be fit for our organization. Making someone responsible for managing others will make the job of the people who can manage themselves worse. If you manage yourself you have a much greater freedom to make decisions, and those decisions are based on deep knowledge of the situation. We want to retain the people who can handle that responsibility and therefore we can't retain the ones that struggle. Assigning a project manager/coordinator/case manager/etc. to something is an indicator that something is wrong and we are picking the wrong solution.
We write these and other lessons in our single source of truth, our handbook. Like (almost) everything at GitLab, our handbook is open source and you're welcome to read it and contribute to it.
