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 wellbeing 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 a new page and a subsequent merge request to add the 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 disagree 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.
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 in the #people-connect chat channel.
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.
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.
1. Digital Transformation Digital Transformation
Customer Experience
Software is Eating the World
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.
Leadership Development To propose a new book club, create an issue in the book clubs project. Individual book clubs which need a dedicated project can create on in the book-clubs group (example).
Better Onboarding Dates: 2021-07-08 and 2021-07-15 Time: 02:00 PM UTC Zoom (password is in the calendar event info) Meeting agenda Discussion issue Recording Session 1 Recording Session 2 Suggested audience: Growth, Product, Product Design and Development Trustworthy Online Controlled Experiments (A Practical Guide to A/B Testing) Dates: 2021-03-11 to 2021-06-10 (every week) Time: 08:00 PT / 15:00 UTC Zoom (password is in the calendar event info) Meeting agenda Discussion issue Suggested audience: growth, product & engineering Ruby under a Microscope Dates: 2020-11-24 to 2021-03-03 (every week) Time: EMEA 14:00 UTC, AMER/APAC 23:00 UTC Zoom EMEA, Zoom AMER/APAC (password is in the calendar event info) Meeting agenda Discussion issue Suggested audience: engineering Software Engineering at Google Dates: 2020-05-20 to 2020-07-29 (every 2 weeks) Time: 21:30 UTC Zoom Meeting agenda Discussion issue Suggested audience: engineering management The Principles of Product Development Flow Dates: 2019-09-05 to 2019-10-31 (every week) Time: 11:30 Pacific Time Zoom Meeting agenda Discussion issue Suggested audience: engineering management High Output Management Dates: 2019-06-03 to 2019-07-15 (every two weeks) Time: 7:30 Pacific Time (one hour before the company call) Zoom Meeting agenda Discussion issue Recordings Suggested audience: people managers Crucial Conversations This book club was internal-only.
Introduction One of the greatest challenges for leaders is to build and develop high performing teams. This page explores what it means to have a high performing team at GitLab. It will also explore a tactical roadmap called the Drexler-Sibbet Team Performance Model that managers can reference to build high performing teams.
What Makes a High Performing Team at GitLab Through various interviews with executive leadership and managers at GitLab, we have identified a series of skills, behaviors, and attributes of high performing teams at GitLab.
Coaching at GitLab Coaching conversations are fluid, dynamic acts of co-creation where the coach and the coachee are equal partners. Coaching is an important component of our 360 review process and for guidance on feedback. Coaching can occur during one-on-one meetings or at any time. It is an important component of career development, leading teams, building an inclusive culture, mentoring, and much more.
Selecting a coach There are various ways to find a coach at GitLab:
Compensation Review Conversations 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.
Content to Review Prior to Compensation Conversations Please make sure to review and understand the following content with regards to Compensation at GitLab:
Effective Delegation 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.
Introduction 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.
GitLab Onsites GitLab Onsites
noun
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.
Introduction 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.
Intro to making decisions 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.
Managing conflict In this section we will review the definition of conflict, the different causes of conflict, review different methods for addressing conflict, steps in the conflict process and some do’s and dont’s 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.
No matrix organization introduction On this page, we will give an overview of how GitLab operates as a no matrix organization.
No matrix organization overview We believe everyone deserves to report to exactly one person that knows and understands what you do day to day. The benefit of having a technically competent manager is easily the largest positive influence on a typical worker’s level of job satisfaction. We have a simple functional hierarchy, everyone has one manager that is experienced in their subject matter that allows them to meaningfully engage with the work being done within their individual function.
Purpose and Benefits of Skip-Levels 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.