About two months ago I joined GitLab and in that time I have seen two new releases,
had the quickest and smoothest team onboarding I have ever had,
pushed dozens of changes and
have gotten to know almost everyone in GitLab.
So how do we move and ship so quickly at GitLab?
At GitLab we are a remote-only company which means communication is essential.
The GitLab Handbook
We have to diligently record and document knowledge to be efficient.
The result is if you ask any GitLab team-member an organizational question
the answer is always "It's in the handbook."
Our handbook is public, copy it, adapt it and make it your own.
"It's in the handbook" - Everyone who's been at GitLab for more than two weeks
Sid, our CEO, believes everyone deserves only one manager to report to
so that they easily know what needs to be done.
Want to know how GitLab is structured?
Take a look at our team page and
"Everyone deserves only one manager" - Sid Sijbrandij (CEO)
At GitLab we have a number of essential meetings mostly for keeping up-to-date
with teams and getting to know everyone:
- Weekly or biweekly one-on-one meetings with your manager
to align priorities and get guidance.
- Weekly standups with your immediate team to review what was done and what is next.
- Monday to Thursday team call with everyone at GitLab to receive important updates
and get to know the team by sharing stories of what we did the past weekend.
- One-on-one coffee break calls to get to just have a chat.
Hearing what other team members did on their weekends and sharing my stories
has been an extremely valuable experience. In a matter of weeks I have gotten
to know most of the team quicker than anywhere else I've worked.
I hear personal stories from people in all departments where normally
people tend to socialize within their department.
My team and I were fortunate to get a lot of time
with Sid during my first few weeks at GitLab and
Sid gave us the following simple productivity steps:
- Pick the next smallest thing you need to do.
- Don't over engineer for a future that might not exist.
- Don't do massive restructures (do step 1.)
- If it is better than what is there, merge it!
Over my years in software development I have notice that people
over discuss ideas instead of acting.
At GitLab each person knows what their objectives are because they have only one manager,
this means individuals can own their work, make the change and then discuss it.
The smaller the change, the less discussion there will be and then move to step 4 - merge it!
The final thing that ties together our communication and focus is iteration.
GitLab has always shipped a new version on the
22nd of every month no matter the day of the week.
I think that Gitlab already took a part of the market from Github and
that this progression is going to continue thanks to the
incredible rate at which the product is developed.
The existing features and the ones that are coming are
going to make Gitlab an even more central tool than it is today.
It is probable that, in a few months, we will not need
anything more than Gitlab to manage the whole lifecycle of a project. - Théo Chamley
MrTrustor's Shiny Blog: Gitlab's Master Plan
If you would like to be part of the GitLab team and
contribute to our culture and tools take a look our