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 organizational chart.
"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 jobs page.