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.
