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.
Managers of One
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.
At GitLab, leadership is requested from everyone, whether an individual contributor or member of the leadership team.
As a leader, GitLab team members will follow your behavior, so always do the right thing. Lead by example with effort.
Everyone who joins GitLab should consider themselves ambassadors of our values and protectors of our culture.
Behavior should be consistent inside and outside the company. We do the right thing outside the company, too.
GitLab respects your judgment of what is best for you, since you know yourself best. If you have a better opportunity somewhere else don’t stay at GitLab out of a sense of loyalty to the company.
In tough times people will put in their best effort when they are doing it for each other.
We are not a democratic or consensus driven company. People are encouraged to give their comments and opinions, but in the end one person decides the matter after they have listened to all the feedback.
It is encouraged to disagree and have constructive debates but please argue intelligently.
We value truth seeking over cohesion.
We avoid meetings, when possible, because they don’t support the asynchronous work flow and are hard to conduct due to timezone differences.
Start meetings on time, be on time yourself, don’t ask if everyone is there, and don’t punish people that have shown up on time by waiting for people or repeating things for those that come late. When a meeting unblocks a process or decision, don’t celebrate that but instead address the question: How can we unblock in the future without needing a meeting?
Saying something to the effect of “as you might have heard”, “unless you’ve been living in a cage you know”, “as everyone knows”, or “as you might know” is toxic. The people that know don’t need it to be said. The people that don’t know feel like they missed something and might be afraid to ask about the context.
Act as a CEO of yourself and your role by taking responsibility to set goals and appropriate timelines. Prioritize your contributions and know it’s impossible to know everything.
Communicate clearly with your team and people leader on the status of your goals. Act quickly to address areas that pose a challenge or to reassess goals that cannot be reached in an alloted timeframe.
Examples of actions from managers of one at GitLab
A team member blocks out dedicated time for learning and development to implement a regular practice of self-serving and self-learning.
A team member in a new role finds an inefficiency in a process they are learning. Without being asked or supervised, they open a merge request (MR) proposing a change and assign it to their manager for review.
When a scheduled meeting agenda is complete 10 minutes before the call is set to end, an attendee ends the call early.
A people leader hires a new team member that demonstrates our CREDIT values.
Before asking for others’ time to discuss a topic, they dedicate time to process their thoughts and make a proposal.
A manager of one prioritizes well-being by blocking their calendars for fitness, meals, paid time off, and personal appointments.
A team member surfaces blockers as opposed to assuming their manager or team is already aware, and simultaneously works to unblock others by working in public and with a low level of shame.
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.
Acting means that someone is occupying this role temporarily and will move back to their original role after a set amount of time or other conditions, such as an external hire.
Interim means the individual is working on a promotion into the role.
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.
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 Feedback
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.
Responding to Negative Feedback
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:
Don’t argue or get defensive. Accept the feedback for what it is: an attempt
to help you improve your work or your professional relationships. If you do
have to explain yourself, try to remain empathetic.
It’s fine (even preferable) to defer action. When presented with negative
feedback, we often feel like we have to either justify our actions or promise
change, and since change isn’t always easy when you’re responsible for a
large team, justification becomes the default. It’s OK to say you need time to
evaluate the feedback and decide how to proceed.
If a team member from your department or another part of the org comes to you and says they do not feel like they or their reports’ contributions are valued by your reports, the manager should try to resolve this. Research shows that this is more likely to happen to underrepresented minorities. Please note that DRIs are free to ignore feedback without acknowledging it and that valuing contributions isn’t the same as agreeing with them. This is about co-opting someone else’s idea without attribution and/or dismissing an idea with an ad-hominem remark.
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.
READMEs by Division
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.
Copy the README-template and paste into your favorite Markdown editor. If you do not have a Markdown editor, Typora and Bear are recommended.
Fill out the recommended sections. Note that each section is optional. You can remove those you aren’t comfortable filling out, and add sections that are interesting or important to you.
Once complete, you’ll need to create an issue with the Digital Experience team to add a page to GitLab’s website.
If your divisionalready has a page to host READMEs (see above), follow the guidelines to add a new page within that directory (e.g. Darren M., a member of the marketing team, would add a new directory and page within /handbook/marketing/readmes, creating /handbook/marketing/readmes/dmurph)
If your division does not yet have a holding page for READMEs, follow the guidelines to add a new page (readmes) within your division’s handbook section first, then create your username directory within readmes.
Bonus points if you add your README & yourselves as codeowner to the .gitlab/CODEOWNERS file.
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.
Advertising Your README
Once your README is created, consider adding a link to it from following places:
Google Doc agendas or calendar invites
Your GitLab.com profile
Your Slack profile
Your Email signature
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
What is coaching?
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.
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.
Factory vs. studio
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.
Effective escalations
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:
Why is this important to the person/team I’m escalating to?
What are the relevant details of the challenge?
What have you tried?
What do you need?
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 advocate with the decisions made by the person they escalated to.
Process gets a bad rep
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.
Talent Acquisition and retention
Managers have an tremendous responsibility around talent acquisition and retention of team members.
Voluntary departures should be low, especially unexpected ones. The most common reasons for resignations can be tied back to the manager.
We want few candidates to decline an offer, especially when the reason isn’t compensation.
We need adequate candidate pipeline volume and quality, especially for crucial positions.
Candidates that have a proposed offer should meet the bar, especially for more senior positions.
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:
Have a clear vision of their objectives and goals
Stay committed to achieving their goals
Manage conflicts
Maintain effective communication and a healthy relationship with each other
Models and encourages teamwork by fostering collaboration, communication, trust, shared goals, mutual accountability and support
Fosters an environment where results are balanced with time management of multiple assignments and Direct Responsible Individuals (DRI’s) on important topics
Empowers team members to be a Manager of One and gives them the tools to grow professionally in their careers
Attracts and retains top talent by creating an inclusive environment built on trust, delegation, accountability, and teachability
Strategies to Build High Performing Teams
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:
To form your team
To guide what your team does
To monitor how well your team is doing
To diagnose where your team may be struggling or identify the keys to your team’s success.
7 Stages to developing high performing teams:
Orientation - Why are we here? Team members need to see a sense of team identity and how individual team members fit in.
Trust Building - Who are you? Team members share mutual regard for each other and are open and supportive of trust-based relationships.
Goal Clarification - What are we doing? Assumptions are made clear; individual assumptions are made known with a clear vision of the end state.
Commitment - How will we do it? Team members understand how it will make decisions and do the work.
Implementation - Who does what, when, where? Team members have a sense of clarity and can operate effectively due to the alignment of shared goals.
High Performance - Wow! The team is accomplishing more than it expected. The team has taken off, creativity is fostered and goals are surpassed.
Renewal - Why continue? The team is given recognition and celebrates achievements of individuals that produce valuable work. Reflect on lessons learned and reassess for the future.
Building and maintaining high performance includes staying mindful of team well-being and potential burnout. With GitLab’s results-driven culture, the demands of product innovation around AI, the fast-paced and ever-evolving business environment, our organization recognizes the crucial balance between achieving ambitious goals and maintaining the well-being of our team members. Everyone can access this handbook resource designed for managers to identify & address burnout. This has an ongoing impact on team performance.
Manager M-Team Groups
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.
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 via HelpLab.
Maintaining an effective and efficient agenda is important to get the best out of the 1-1 (read as: one to one) meetings you have with your team members. Furthermore this page will take you through other tips and tricks to conduct an effective 1-1 meeting.
The 1-1 Agenda
Make sure you use a consistent agenda format for each 1-1.
Both parties add items to the agenda. Preferably, the majority added by the team member. If the manager puts more than half of the items on the agenda this is an indication that something is wrong.
We believe that the market opportunity for a complete DevSecOps platform designed as a single application for the software development lifecycle is several billion dollars and expanding. There are three primary trends outlined below that we have identified as the most significant to supporting the long term success of our business.
We also have a Mitigating Concerns page.
From time to time, we run internal book clubs on a book from one of our resource lists. All are welcome! However,
each club has a suggested audience to indicate roles to which the content is tailored.
Create space to practice strategies for achieving high performance
Coaching conversations are fluid, dynamic acts of co-creation where the coach and the coachee are equal partners. People leaders and individual contributions alike use coaching at GitLab during our 360 review process, giving and receiving feedback, throughout stages of career development, and more.
Conversations with regards to compensation are an important part of being a people manager. This page will take you through information and recommendations to effectively manage and guide these conversations. If you’re ever in doubt or have a question, don’t hesitate to reach out to your aligned People Business Partner.
For more information for managers on the FY25 Annual Compensation Review Cycle, please refer to the Manager Information Guide
The purpose of this section is to give you the following:
An appreciation for the importance of delegation to others as a way to manage workload and prioritize action items.
Face any fears that you may have regarding delegating to others.
Help you adopt an appropriate strategy to delegate the right tasks to the right people at the right time and in the right way.
Help you develop a systematic step-by-step approach to brief team members on what you want to delegate to others.
What is delegation?
Delegation is the assignment of responsibilities to another person for the purpose of carrying out specific job-related activities. Delegation is a shift of decision-making authority from one team member to another.
At GitLab, we place a high level of importance on interpersonal skills for workplace effectiveness. Employee interpersonal skills have an impact on productivity, morale, engagement, performance, and help us live up to our values. Whether you are a People Manager or an Individual Contributor, being skilled in “emotional intelligence” (also referred to as EQ) is a key attribute to interpersonal effectiveness.
One of the most important factors in people’s decisions to stay or leave a job is the quality of the relationship they have with their immediate boss and their coworkers. There are practical ways to learn and apply interpersonal skills in a remote environment. In this section of the handbook we review the key characteristics of emotional intelligence (EQ) and how to improve your interpersonal skills professionally and personally. You’ll learn how to work more effectively with others.
Dedicated time for all-remote teams to come together in person to build trust
As a leader in all-remote work, it’s important that we recognize the value and impact of time spent in the same location. Meaningful time spent together influences the trust and results our teams build. Co-located companies often gather for offsites to connect in a new location. In our all-remote environment, we call in-person team meetings onsites.
At GitLab, one of our favorite books is, “High Output Management” by Andrew Grove. The book provides a comprehensive overview of a manager’s role and purpose. Our CEO, Sid, applied many of the concepts covered when partnering with the People team to design management and people practices for GitLab. On this page, we will cover some of the key topics covered in the book and what they mean for people leaders.
With GitLab’s results-driven culture, the demands of product innovation around AI, the fast-paced and ever-evolving business environment, our organization recognizes the crucial balance between achieving ambitious goalsandmaintaining the well-being of our team members.
Defining Burnout
The World Health Organization defines Burnout as “a syndrome conceptualized as resulting from chronic workplace stress that has not been successfully managed. It is characterized by three dimensions: feelings of energy depletion or exhaustion; increased mental distance from one’s job, or feelings of negativism or cynicism related to one’s job”
On this page, we have outlined how we make decisions at GitLab.
Making decisions
GitLab’s values are the guiding principles for our business. They inform hiring, performance management, and promotion assessments. They also guide other decisions that we make. At times, values may be in conflict. To address this, GitLab has a values hierarchy. At the top of this hierarchy is “results”. While items higher in the hierarchy don’t always override items lower in the hierarchy, this structure guides team members as they weigh decision making alternatives.
In this section, we will review the definition of conflict, the different causes of conflict, different methods for addressing conflict, steps in the conflict process, and some do’s and don’ts of workplace conflict. Conflict in the workplace is inevitable when you have team members of various backgrounds and different work styles all working towards the same goals and OKRs (Objectives and Key Results). Conflict should never just be avoided, conflict should be managed and resolved. The first step is for the team members who experience conflict to work to address the situation to work towards a resolution. If a resolution is not possible, the manager should work with the team members and their assigned People Business Partner to help foster a resolution.
On this page, we will give an overview of how GitLab operates as a no matrix
organization.
“No matrix organization” means that everyone reports to exactly one person. At
GitLab we have a simple functional management hierarchy. Technical leadership at
GitLab is leadership without a formal reporting line, based on project roles and
experience.
The advantage of a functional structure is that you get better feedback and training since your manager understands your work better than a general manager.
For the organization, forgoing a separate class of managers ensures a simple structure with clear responsibilities.
A functional organization structure mimics the top structure of our organizations (Finance, Sales, Engineering, etc.).
It reduces compensation costs, coordination costs, and office politics.
The disadvantage is that your manager has a limited amount of time for you and probably has less experience managing people.
To mitigate these disadvantages we should offer ample training, coaching, support structures, and processes to ensure our managers can handle these tasks correctly and in a limited amount of time. “It’s easier to train an expert to manage well than to train a manager to be an expert” from How Apple is organized for Innovation.
Everyone deserves a great manager that helps them with their career. A manager should hire a great team, should let you know when to improve, motivate and coach you to get the best out of you.
“Nuke all matrices. Nuke all dual reporting structures. And nuke as many shared services functions as you possibly can.” from the great guide to big companies from Marc Andreessen (the other guides are awesome too).
We recommend reading High Output Management, and its author coined Grove’s law: All large organizations with a common business purpose end up in a hybrid organizational form. We believe a dual reporting structure is inevitable, we just want to delay it as long as possible.
Whenever there is need to work on a specific, high-level, cross functional business problem, we can assemble a working group.
Functional companies are easier when you focus on one product. Apple focuses on the iPhone and can have a unitary/functional/integrated organizational form. The advantage is that you can make one strong integrated product. We can also maintain a functional organization as long as we keep offering new functionality as features of GitLab instead of different products. The fact that we’re in touch with the market because we use our own product helps as well.
Leaders should know the details of their organization three levels down for efficient and effective cross-functional decision-making.
Having functional managers means that they are rarely spending 100% of their time managing. They always get their hands dirty. Apart from giving them relevant experience, it also focuses them on the output function more than the process. Hopefully both the focus and not having a lot of time for process reduces the amount of politics.
Functional managers spend their time between owning, learning, delegating or teaching styles. Managers will decide what activities demand their full attention and fall within their core area of expertise which they will own and what activities require them to learn new areas of expertise. Some activities require less attention from the leader and can be pushed down to others by either delegating or teaching someone on the team.
E-Group Conversation on No-Matrix Organization
Who better to learn how GitLab enables a functional organization structure than our leadership. As part of the CEO Handbook Learning Sessions, the L&D team facilitated a discussion with executives during a E-Group offsite, to discuss no-matrix organization and GitLab organization design.
A skip-level meeting is a meeting during which a manager’s manager meets directly with team members without the direct manager present. While 1-1s facilitate communication between a team
member and their manager, skip levels should facilitate communication between the leader’s whole team, not just their direct
reports.
The CEO conducts quarterly skip-level meetings with all indirect reports. The goal of this meeting is to help the CEO be a better manager of him/herself, of the report of their function, and the rest of the executive team. What is going well, what needs improvement, how can the CEO help, and what should the CEO focus on when coaching the report?
