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.
We should escalate up the management chain when the team members involve agree to the escalation. We speak directly to each other about our feedback and requests in order to resolve our own conflicts. When we do need to escalate, we do it in an effective way.
When we identify that our focus is slipping to things that can be solved by our team members, we commit to empowering them to own the work. Managers shouldn't spend time in conversations that we aren't needed in or problems that their teams can solve.
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.Alternatively you can create your README dogfooding GitLab's README profile customization feature. Follow documentation on how to add details to your GitLab profile with a README. Do not forget to add your profile's link to you division's holding page.
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 Executive (SAE) 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.
Team members should feel comfortable escalating issues when help is needed to resolve unexpected challenges. Effective escalations are good, because they speed up decision making. When team members escalate an issue, another person is brought in as a decision maker or adviser as other team members disagree or need help with alignment or a serious trade-off is needed. Escalation can offer clarity and a path forward, and can be a sign of seniority for the person initiating the escalation when they know what, how, and when to escalate.
As noted in this medium article, explicit esclatation should answer these four questions:
Folks who are escalating an issue should avoid surprising folks in the management chain. This means that other relevant team members should be aware that an escalation is occurring. For example, in E-Group, members agree that they will not go to the CEO with an escalation without first notifying other relevant members that this is happening.
There may be some exceptions to first notifying managers or peers. For example, a team member feels unsafe in voicing a concern to a manager or their peers and feels that they can't effectively escalate with standard notification without retribution. While exceptions may be appropriate, they should be rare.
After a team member escalates an issue, it is OK if they disagree, commit, and disagree with the decisions made by the person they escalated to.
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:
Watch the replay of our conversation with Jeb Hurley, Co-founder and Managing Partner Brainware Partners where we discussed:
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:
M-teams are management support groups made up of 3 to 6 managers who are in timezones that allow for sync meetings among members. M-teams should set up a regular meeting on a cadence agreed by the members with the agenda being "what's challenging this week?". Decide who will facilitate and each person will get a chance to have their challenge discussed in the meeting. When it's your turn, you talk a little about what you're struggling with. M-groups agree to a level of confidentiality so that group members are willing to be vulnerable; vulnerability leads to trust and better outcomes for the group.
If you're interested in starting or joining an m-team meeting, reach out to other managers in the #managers Slack channel.
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.
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 Mitigating Concerns. Many of our values help to mitigate some of these concerns.