Leadership

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.

  1. At GitLab, leadership is requested from everyone, whether an individual contributor or member of the leadership team.
  2. As a leader, GitLab team members will follow your behavior, so always do the right thing. Lead by example with effort.
  3. Everyone who joins GitLab should consider themselves ambassadors of our values and protectors of our culture.
  4. Behavior should be consistent inside and outside the company. We do the right thing outside the company, too.
  5. 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.
  6. In tough times people will put in their best effort when they are doing it for each other.
  7. We work asynchronously. Lead by example and make sure people understand that things need to be written down in issues as they happen. Hold your team accountable with documentation.
  8. 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.
  9. It is encouraged to disagree and have constructive debates but please argue intelligently.
  10. We value truth seeking over cohesion.
  11. We avoid meetings, when possible, because they don’t support the asynchronous work flow and are hard to conduct due to timezone differences.
  12. 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?
  13. Be intentional in how you prepare for and participate in meetings. Async communication works best when folks review their calendars and prepare in advance of meetings.
  14. We give feedback, lots of it. Don’t hold back on suggestions for improvements, this helps us grow. Take pride in helping others through feedback.
  15. Focus on improvement. If you meet external people, always ask what they think we should improve.
  16. Following from Paul Graham’s advice: Strive to make the organization simpler.
  17. 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.
  18. Don’t use someone else’s name, remind people of your title, or otherwise “pull rank” to get things done.
  19. 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.
  20. 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

  1. When asked to attend a synchronous brainstorming call, a team member instead opens an issue and requests for their team’s ideas asynchronously.
  2. A people leader champions our value of Diversity, Inclusion and Belonging by becoming a mentor.
  3. A team member blocks out dedicated time for learning and development to implement a regular practice of self-serving and self-learning.
  4. 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.
  5. When a scheduled meeting agenda is complete 10 minutes before the call is set to end, an attendee ends the call early.
  6. A people leader hires a new team member that demonstrates our CREDIT values.
  7. Before asking for others’ time to discuss a topic, they dedicate time to process their thoughts and make a proposal.
  8. A manager of one prioritizes wellbeing by blocking their calendars for fitness, meals, paid time off, and personal appointments.
  9. 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.

Interim and Acting Leadership

In some cases, a individual in the Management group, Director group, S-group, or even E-group may have an “Interim” or “Acting” title.

  1. 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.
  2. 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.

Making decisions

Please see the Making Decisions Leadership page.

Communication should be direct, not hierarchical

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:

  1. Provide context.
  2. Use a framework for your feedback. Our recommended framework is Crucial Conversations – we offer a training course, and the book is part of our recommended reading for leaders.
  3. Ask yourself, is this:
    • Actionable
    • Specific
    • Kind (Does the feedback help the person? Note: Being kind is not the same as being nice.)
    • Objective (similar to Fair)
    • Relevant to the job role and compa ratio

Identifying root causes

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.
  • The Right Way to Respond to Negative Feedback
  • 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.

1-to-1

Please see /handbook/leadership/1-1/.

Skip level interactions

Please see /handbook/leadership/skip-levels/.

Your Individual README

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.

Creating Your README

  1. Copy the README-template and paste into your favorite Markdown editor. If you do not have a Markdown editor, Typora and Bear are recommended.
  2. 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.
  3. Once complete, you’ll need to create a new page and a subsequent merge request to add the page to GitLab’s website.
    1. If your division already 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)
    2. 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.
  4. 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.

No matrix organization

Please see /handbook/leadership/no-matrix-organization/

Stable counterparts

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:

  1. Why is this important to the person/team I’m escalating to?
  2. What are the relevant details of the challenge?
  3. What have you tried?
  4. 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.
  • Build a global team. Unless shown with a business case, “we can’t find the talent out of the bay” goes against our diversity, inclusion and belonging mission and the Location Factor KPI.

High Output Management

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 High Performing Teams

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
  • Make unanimous decisions as a team

Watch the replay of our conversation with Jeb Hurley, Co-founder and Managing Partner Brainware Partners where we discussed:

  1. Managing trust, productivity, and wellbeing on remote teams
  2. Behavior, biochemistry, and dynamics of trust
  3. The value of measuring and reporting on impacts of building trust

Skills and behavior of building high performing teams competency for Managers:

  • 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:

  1. Orientation - Why are we here? Team members need to see a sense of team identity and how individual team members fit in.
  2. Trust Building - Who are you? Team members share mutual regard for each other and are open and supportive of trust-based relationships.
  3. Goal Clarification - What are we doing? Assumptions are made clear; individual assumptions are made known with a clear vision of the end state.
  4. Commitment - How will we do it? Team members understand how it will make decisions and do the work.
  5. Implementation - Who does what, when, where? Team members have a sense of clarity and can operate effectively due to the alignment of shared goals.
  6. High Performance - Wow! The team is accomplishing more than it expected. The team has taken off, creativity is fostered and goals are surpassed.
  7. 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 Resource: Identifying & Addressing Burnout

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.

Articles

  1. Carta’s Manager’s FAQ
  2. Carta’s How to hire
  3. How Facebook Tries to Prevent Office Politics
  4. The Management Myth
  5. Later Stage Advice for Startups
  6. Mental Models I Find Repeatedly Useful
  7. This Is The Most Difficult Skill For CEOs To Learn
  8. Great article about how to think about PIPs, although our time scales are shorter.
  9. Impraise Blog: 1-on-1s for Engaged Employees
  10. Mind Tools: Giving Feedback: Keeping Team Member Performance High, and Well Integrated
  11. Remote.Co: 5 Tips for Providing Feedback to Remote Workers
  12. Really interesting blog post from Hanno on remote team feedback
  13. 51 questions to ask in one-on-ones with a manager
  14. HBR: The rise of data driven decision making is real but uneven
  15. Forbes: 6 Tips for Making Better Decisions

Books

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.

  1. High Output Management - Andrew Grove
  2. The Hard Thing About Hard Things: Building a Business When There Are No Easy Answers - Ben Horowitz
  3. Crucial Conversations: Tools for Talking When Stakes Are High - Kerry Patterson
    • Notes from the E-group reading:
    • Virtual teams are much more likely to fail on crucial conversations than colocated teams
    • We need to develop the skill of sensing the tone of a-sync conversations to uncover potential issues
    • We need to find a way to create psychological safety for people in official channels
    • Starting with empathy is a great way to gather the context needed in a tense situation - this is hard a-sync, but more important
    • Consider getting context 1-on-1 (through Slack) before posting a comment in an issue that you might regret later
    • As leaders, we need to give context as well. A good question is: “What would have to change for us to get X prioritized…”
    • Documenting something is not a replacement for having the hard conversation
    • Book club
    • Crucial Conversations Handbook Page

Email Lists

  1. Software Lead Weekly

Training

When you give leadership training please screenshare the handbook instead of creating a presentation.

Leadership Development Opportunities

  1. Managers can participate in our Elevate program, focused on developing management skills to lead all-remote teams.
  2. Leadership development coaching with the growth & development benefit. More details about a formal GitLab coaching program to come.
  3. Self-led opportunities to be a mentor - keep an eye out for a company-wide mentorship program with applications opening at the end of January 2022.
  4. Join the women’s TMRG mentorship group to either be a mentor to practice leadership or get paired with a leader to learn from.
  5. Sign up for Crucial Conversations training
  6. Explore opportunities to join the CEO Shadow program or other division specific shadow programs with the Chief of Staff, People Connect Shadow Program, Security, and Development Director Shadow Program.
  7. Explore the skills needed to successfully transistion from IC to Manager in GitLab Learn.
  8. Explore leadership and management courses on LinkedIn Learning
  9. Watch or listen to one of the many CEO Handbook Learning sessions with Sid on various leadership topics
  10. Join a monthly Leadership Chats talk to learn from people leaders across the organization.
  11. Learning and Development is developing several programs in FY23 to include a Managing at GitLab Course, New Manager Bootcamp, LifeLabs Learning Pilot and Launch, coaching program, and much more!

People Group

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.

Being a public company

Learn more on GitLab’s view of being a public company.

Mitigating Concerns

We have a page which documents our Mitigating Concerns. Many of our values help to mitigate some of these concerns.


1-1
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.
Biggest Tailwinds
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
Book clubs
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.
Building Trust at GitLab
On this page, GitLab details considerations for building trust in remote teams. Learn more!
Coaching
Coaching at GitLab At GitLab, we use coaching to: Building meaningful, inclusive connections Equip team members with skills they need to deliver results for customers 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.
Compensation Review Conversations
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. For more information for managers on the FY25 Annual Compensation Review Cycle, please refer to the Manager Information Guide
Crucial Conversations
“GitLab’s strategies for being an effective leader during crucial conversations with team members”
Effective Delegation
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.
Emotional Intelligence
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 - Getting your team together in person
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.
High Output Management
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.
Identifying & Addressing Burnout
Manager Guide: Identifying & Addressing 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. 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”
Making Decisions
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
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
No matrix organization introduction 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. No matrix organization overview We believe everyone deserves to report to exactly one person that knows and understands what you do day to day.
Skip Level Meetings - Overview
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.
Underperformance
We want team members to be successful and should offer every opportunity for them to work effectively.
Workforce Planning
Workforce planning and SWOT analysis