Blog Culture How to become the best distributed software development team? My interview with GitLab's CEO
Published on September 15, 2017
6 min read

How to become the best distributed software development team? My interview with GitLab's CEO

FineTune CTO Kwan Lee sits down for a 'pick your brain' meeting with GitLab CEO Sid Sijbrandij.


GitLab CEO Sid Sijbrandij occasionally sits down for a "pick your brain" meeting with people seeking advice on open source, remote work, or discussion of other things related to GitLab.

It was great to find the time for us to pick Sid’s brain and learn from the history and the organizational challenges that GitLab had overcome so that we may reference them for building a better organization. There were some cultural elements, tactical organizational elements and software development process-related elements that were valuable pointers.

Lessons in remote work

Having 178 people in 38 countries was quite an impressive distribution of employees across different geographies. Sponsoring travel to work with fellow members of the company was a great program that they have to bridge the distributed nature of the company. We are also a very distributed company and we want to grow a company where a distributed team can scale and collaborate actively while continuously increasing the motivation to build higher quality software at higher velocity for our customers.

One of the challenges of being remote is that, although we are part of one company, it is tricky for us to interact in a casual manner as we do in a physical co-working environment. GitLab promotes virtual coffee breaks and all-team meetings to promote these. People can arrange coffee breaks with others at their will to catch up. During all-team meetings, they go around introducing personal updates about themselves. The team being remote requires everybody to still feel part of one company. In order to feel part of the company, it requires participation from everybody and their willingness to share their personal lives.

In order to feel part of the company, it requires participation from everybody and their willingness to share their personal lives.

At FineTune, we are not used to taking coffee breaks during the day with coworkers, but we try to have regular meetings where we try to catch up personally for the first five minutes. Our weekly company meetings have been a little bit informal and did not give opportunity for each of the members to speak. We plan to keep encouraging people to share more as we want to grow a culture of sharing more as we grow and scale.

Sid also described various rooms for social interaction in the company. Some more interesting venues for social interaction that were suggested by Sid were:

  • Team call four times a week (20 minutes)
  • Summit: every nine months they fly everybody to one place, for interactions that are less organized with scheduled activities and forbidden to have team meetings ('unconference')
  • Asynchronous discussions via merge requests, while they sometimes get on video call to summarize what has been concluded or decided

Writing things down is important due to the remote nature of the company. We have been pretty bad at keeping consistent standards on documentation and keeping them up to date. It also hinders communication flow, making it difficult to discover and share knowledge when we do not have such consistency. We are working on ways to improve this nowadays.

Writing things down is important due to the remote nature of the company

Lessons in organization

When it comes to organization and growth, what we got most out of it was that we need to find the gaps in our team and try to fill in those parts we lack when we hire new members. Currently, we have a gap in frontend tech lead, and by thinking through what gaps exist in our development and future of our company we found that we would like to find a tech lead who has extensive experience modularizing frontend software components and has worked with complex microservice APIs that would facilitate the flow of communication between frontend and backend members.

Some other organizational lessons learned from growing from 15 to 50 was that:

  • Sid was the only Sales (non-development) team member
  • Get things done on time and having well defined tasks are very important
  • One boss to give approvals
  • No project managers

We want to organize ourselves so that we are making decisions quickly and moving fast. I believe that as long as the priority framework for decision-making is clear, everybody should feel free to make the decisions that move the company forward.

Lessons in the development process

In terms of development process, we realized we needed to shorten the time to release and try to keep shipping. Importance of fast iteration was emphasized by Sid and shipping fast by cutting scope. We should not fall into the trap of building the car and not shipping when the bicycle is ready. We also need more discipline to maintain good, coherent design documentations that allows us to be all on the same page.

It was interesting to see the scale of work that the distributed team worked on. When a new sprint starts, product and UX team already had designed and product team had schedules for release. Ad hoc dev teams get formed for big features (every release has around five big features and 100s of small issues), making a chat channel, discussing issue descriptions, figuring out when you hand off from backend to the frontend team.

"always finish the flow first"

GitLab's approach of "always finish the flow first" (breadth vs depth) to take care of coordination resonated strongly since that involves more people and requires people to be on the same page to further dive in deeper. Also, the "building better a experience" and "releasing a more integrated experience" brings a lot of emergent benefits.

Some mistakes seen were people having hard time iterating and sometimes over engineering implementation which risks release deadline. Everyone can contribute, but at the end person doing the work makes the decision.

Lessons in leadership

As a final question, we asked what prevents a software company from growing. The answer we got was the lack of ambition. We as the founders or development team may not be as ambitious as we should be. Our company has been in the ed tech industry for 10 years and had not seen much growth. What we realized was that our goals and bars were set too low. We have a lot of strong design and engineering capability that we have built up over the last six months and now it is our time to think and act with more ambitious goals. There is a lot of value in helping people to write better and measure the quality of written content since most communication nowadays is done via writing.

We want to become an important company that helps with not only K-12, higher-ed education in EdTech industry, but also with professional development and employability across any industry that requires written communication to succeed. We have a long way to go, but the invaluable discussion we had with Sid informed us some of the good practices to follow and a trajectory to aim for around our next growth path.

Cover image by Blake Connally on Unsplash

We want to hear from you

Enjoyed reading this blog post or have questions or feedback? Share your thoughts by creating a new topic in the GitLab community forum. Share your feedback

Ready to get started?

See what your team could do with a unified DevSecOps Platform.

Get free trial

New to GitLab and not sure where to start?

Get started guide

Learn about what GitLab can do for your team

Talk to an expert