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 well-being 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.

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

Skip level interactions

Please see 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.

• Engineering READMEs
• Marketing Team READMEs
• Product READMEs
  • UX Department READMEs
• Sales Team READMEs
• People Group READMEs
• Finance Team READMEs
• Legal Team READMEs
• Office of the CEO READMEs

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 an issue with the Digital Experience team to add a 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 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 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.
• 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 well-being 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
   • Top 10 quotes
   • Book club
2. The Hard Thing About Hard Things: Building a Business When There Are No Easy Answers - Ben Horowitz
   • Chase Wright’s notes
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 screen share 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, and Security.
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. 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 via HelpLab.

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.

View page source - Edit this page - please contribute.