This page contains leadership pointers. The first couple of headers indicate which group they apply to, using the groupings defined on our team structure page.
In an all-remote organization, we want each team member to be a manager of one. A manager of one is an attribute associated with our Efficiency value. To be successful at GitLab, team members need to develop their daily priorities to achieve goals. Managers of one set the tone for their work, assign items and determine what needs to get done. No matter what role you serve, self-leadership is an essential skill needed to be successful as a manager of one.
In the CEO Handbook Learning Session above, GitLab CEO Sid Sijbrandij gives more context on individual contributor leadership and managers of one.
We want leadership from everyone at GitLab. Since we are remote, there is a high expectation to do your work without direct supervision. It means that every team member is responsible for communication, structuring decisions, and managing your workload individually.
In some cases, a individual in the Management group, Director group, S-group, or even E-group may have an "Interim" or "Acting" title.
In either case, they will be fulfilling the full responsibilities of the role. If you have any questions, about the future of the role, please ask them or their manager.
Individual departments will have their own criteria for who is eligible to occupy these roles, so please check the career development page for your department.
Please see the Making Decisions Leadership page.
Most companies communicate from top to bottom through a chain of command. This communication flow often empowers managers, but it also introduces inefficiency as team members are not able to connect directly with the people they need to communicate with in order to get their work done. At GitLab, every team member is encouraged to reach out to whoever is the correct person (or people) to quickly unblock issues, solve problems or support in other ways. Do be courteous of your direct manager and copy them on the request. We don't encourage unnecessary friction in asking team members to escalate through managers and wait for responses to come back. What matters is efficiency in getting to results. Slack the CEO, Slack a VP, or Slack a peer. Do what you need to do to make GitLab successful.
Managers should not be bottlenecks or silos for communication. Anyone should feel comfortable reaching out to anyone else with the best information they can to solve a problem. This is a more efficient, transparent, and collaborative way to work.
Giving regular feedback is extremely important for both managers and team members. Feedback can take the form of coaching sessions, separate from 1-to-1 meetings. Giving feedback is also about being prepared and, depending on the situation, you should create separate agendas and structure them as follows:
Sometimes when performance dips, the best way to tackle it is to try to determine the root cause. This is easier said than done. There is a great tool that CEB (now Gartner) created to help with this called performance issue root cause diagnostic. It may not always be possible or appropriate to determine the root cause, so the underperformance process should be followed.
As a leader, the way you respond to negative feedback makes a significant impact on your team. Remember that it can be difficult for people to approach someone in authority with concerns and respond with sensitivity and appreciation. In particular, we recommend that you keep the following in mind:
Please see /handbook/leadership/1-1.
Please see /handbook/leadership/skip-levels.
A team member's README page is intended to help others understand what it might be like to work with them, especially people who haven’t worked with them before. It's also a well-intentioned effort at building some trust by being intentionally vulnerable, and to share your ideas of a good working relationship, to reduce the anxiety of people who may be on your team, now or in the future.
READMEs provide a genuine report on how a person works, reducing bias/assumption and enabling people to work together based on a common framework. As part of GitLab's transparency value, we encourage each GitLab team member to consider creating their own README.
GitLab division README pages are linked below for context. Reading other READMEs is an important way to get ideas on what you can include in yours. Let these serve as a guide and inspiration to you.
/handbook/marketing/readmes, creating /handbook/marketing/readmes/dmurph)readmes) within your division's handbook section first, then create your username directory within readmes.Once your README is created, consider adding a link to it from following places:
This provides maximum visibility to others, so that they may read your README in advance of working with you. This allows them to take your working style and communication preferences into account, ideally increasing the overall level of empathy expressed.
READMEs are particularly powerful when working with those outside of GitLab, who may be unfamiliar with our values. A README is a beacon of transparency, and helps set the tone for any working relationship.
Coaching is about helping others help themselves. It is not about giving advice, instruction, or telling someone what to do. Coaching is about focusing on the future and identifying where the coachee wants to be and what they want to achieve. At GitLab, we've defined coaching as a conversation that helps people think for themselves, find their own answers, and commit to action they design. As a coach, your role is to clarify the pathway from the current state to the future. Coaches do this by enabling the coachee to make informed choices based on deeper insight.
Please see /handbook/leadership/no-matrix-organization
We want to promote organic cross-functional collaboration by giving people stable counterparts for other functions they need to work with. For example, each Strategic Account Leader (SAL) works with one Sales Development Representative (SDR). With our categories every backend team of developers maps to a Product Manager (PM) and a frontend team.
Giving people a stable counterpart allows for more social trust and familiarity, which speeds up decision making, prevents communication problems, and reduces the risk of conflicts. This way we can work effectively cross functionally without the downsides of a matrix organization.
We want the best combination of a factory and a studio. The studio element means anyone can chime in about anything, from a user to the CEO. You can step outside your work area and contribute. The factory element means everyone has a clearly assigned task and authority.
Process has a bad reputation. It has that reputation for things that we try to avoid doing at GitLab. When you have processes that are not needed it turns into a bureaucracy. A good example are approval processes. We should keep approval processes to a minimum, by both giving people the authority to make decisions by themselves and by having a quick lightweight approval process where needed.
But process also has good aspects. Having a documented process for how to communicate within the company greatly reduces time spend on on-boarding, increases speed, and prevents mistakes. A counterintuitive effect is that it also makes it easier to change processes. It is really hard to change a process that doesn't have a name or location and lives in different versions in the heads of people. Changing a written process and distributing the diff is much easier.
Managers have an tremendous responsibility around talent acquisition and retention of team members.
GitLab leadership and management approach was built using principles covered in the book "High Output Management." Please see High Output Management to learn more.
Building a team to deliver results is a very important aspect of improving efficiency and iteration. A high-performing team will always deliver results. As a leader at GitLab, your role is to develop a high-performing team to reach the desired level of performance and productivity. There are certain traits that high-performing teams display at GitLab:
Skills and behavior of building high performing teams competency for Managers:
The Drexler-Sibbet Team Performance Model is an excellent tool to help build high performing teams at GitLab. The model provides a roadmap for a team and a common language. It is a simplified description of how a team works together that highlights the most important things the team needs to focus on to reach high performance. At GitLab, we can use it as a frame of reference to developing high performing teams. It can help Managers ensure new and existing team members know the mission and direction of the team by the following:
7 Stages to developing high performing teams:
Books in this section can be expensed.
Notable books from the E-Group Offsite Book Selections may be added to the list below.
We sometimes self-organize book clubs to read through these books as a group.
When you give leadership training please screenshare the handbook instead of creating a presentation.
Managers can participate in our manager challenge program, focused on developing foundational management skills to lead high performing teams.
Feel free to reach out to anyone in the People Group for further support on leadership development topics. You can find us on the team page, using the People Group dropdown. The team may also be reached in the #people-connect chat channel.
Learn more on GitLab's view of being a public company.
We have a page which documents our biggest risks. Many of our values help to mitigate some of these risks.
