Gitlab hero border pattern left svg Gitlab hero border pattern right svg

Leadership

  1. You are here:
  2. Handbook
  3. 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.

GitLab team members

  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.
  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, just do the right thing inside the company, and don't fake it outside.
  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.
  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. We give feedback, lots of it. Don't hold back on suggestions for improvements.
  14. If you meet external people, always ask what they think we should improve.
  15. Following from Paul Graham's advice: Strive to make the organization simpler.
  16. 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.
  17. Don't use someone else's name, remind people of your title, or otherwise "pull rank" to get things done.

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

  1. We use our values, and particularly our values hierarchy, to guide the decisions we make.
  2. We combine the best of both hierarchical and consensus organizations. Hierarchical organizations have good speed but are bad at gathering data, leading to people saying yes but not doing it. Consensus organizations are good at gathering data but lack speed, leading to projects happening under the radar. We split decisions into two phases. The data gathering phase has the best of consensus organizations, where everyone can contribute. The decision phase has the best of a hierarchical organization, the person that does the work or their manager decides what to do.
  3. If you apply consensus in both the data gathering phase and the decision phase you lose speed and you get decisions that try to stay under the radar so there are fewer people to convince.
  4. If you apply hierarchy in both the data gathering phase and the decision phase you lose valuable input.
  5. Providing input but then not being part of the decision making phase is counterintuitive, you feel ignored. We'll have to accept that people listened to us but don't owe us an explanation to have fast decisions based on everyone's input.
  6. At GitLab, decision making is based on an informed and knowledgeable hierarchy, not on consensus or democracy. Voting on material decisions shows a lack of informed leadership.
  7. Make data driven decisions but consider environments that do not allow reliable data collection. According to research by the Harvard Business Review, "experience and knowledge of leaders in the subject matter still outperforms purely data-driven approaches."
  8. When analyzing trends, never show cumulative graphs because they always look up and to the right even if business is bad.
  9. Be aware of your unconscious biases and emotional triggers.
  10. We don't have project managers. Individual contributors need to manage themselves. Not everyone will be able to do this effectively and fit our organization. Making someone responsible for managing others will cause negative effects to the results of the people that can manage themselves. If you manage yourself you have a much greater freedom to make decisions, and those decisions are based on deep knowledge of the situation. We want to retain the people that can handle that responsibility and therefore we can't retain the ones that struggle. Assigning a project manager/coordinator/case manager/etc. to something is an indicator that something is wrong and we are picking the wrong solution. The notable exception to this is in the Professional Services organization. While most functions at GitLab are serving the product or the company, ProServe is a services company which collaborates closely with customers and is sometimes contractually obligated to have project managers.
  11. The person that does the work makes the decisions, they are the Directly Responsible Individual (DRI). They should listen to the data and informed opinions of others to arrive at their decision. Part of making good decisions is knowing who has good information and/or experience that informs that decision. Once a DRI has made a decision, Disagree, commit, and disagree
  12. A DRI may make a decision that results in (and is hence the cause of) negative feelings, but it is important to remember Collaboration is not consensus and People are not their work. While others are invited to contribute data and informed opinions during the decision making process, the DRI is not responsible for how they feel. When contributing supporting information to making a decision, it is the responsibility of the contributors to do so with data, use cases, historic examples, etc and not personal opinions or attacks.
  13. Short way to phrase this: We can allow others into our kitchen because we can always send them out (inviting people to give input is much easier if you retain the ability to make a decision by yourself).

If good decision-making appears complicated, that’s because it is and has been for a long time. Let me quote from Alfred Sloan, who spent a lifetime preoccupied with decision-making: “Group decisions do not always come easily. There is a strong temptation for the leading officers to make decisions themselves without the sometimes onerous process of discussion.”

  • Chapter 5: Decisions, Decisions of High Output Management by Andy Grove

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-on-1 meetings. Giving feedback is also about being prepared and, depending on the situation, you should create separate agendas and structure them as follows:

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:

1-on-1

Please see /handbook/leadership/1-1.

Skip level interactions

Please see /handbook/leadership/skip-levels.

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

Skills and behavior of being a manager of one as a Team Member:

Skills and behaviors of being a manager of one as a People Leader:

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

  1. 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. Matrix organizations or dotted lines are too hard to get right.
  2. We don't want a matrix organization where you work with a lead day to day but formally report to someone else.
  3. 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.
  4. For the organization, forgoing a separate class of managers ensures a simple structure with clear responsibilities.
  5. A functional organization structure mimics the top structure of our organizations (Finance, Sales, Engineering, etc.).
  6. It reduces compensation costs, coordination costs, and office politics.
  7. The disadvantage is that your manager has a limited amount of time for you and probably has less experience managing people.
  8. 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.
  9. 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.
  10. "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).
  11. 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.
  12. We do make features with a DevOps stage group that is a collection of teams and stable counterparts.
  13. Whenever there is need to work on a specific, high-level, cross functional business problem, we can assemble a working group.
  14. 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.
  15. 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.

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 Leader (SAL) 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.

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.

Recruiting and retention

Managers have an tremendous responsibility around recruiting and retention of team members.

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:

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

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:

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.

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. The score takes care of itself - Bill Walsh - PDF
  4. 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
  5. The Advantage: Why Organization Health Trumps Everything Else In Business - Patrick Lencioni
  6. The Five Dysfunctions of a Team: A Leadership Fable - Patrick Lencioni
  7. Crossing the Chasm: Marketing and Selling High-Tech Products to Mainstream Customers - Geoffrey A. Moore
  8. The First 90 Days: Proven Strategies for Getting Up to Speed Faster and Smarter - Michael D. Watkins
  9. The 21 Irrefutable Laws of Leadership: Follow Them and People Will Follow You - John C. Maxwell
  10. Thinking, Fast and Slow - Daniel Kahneman
  11. The Power of Habit - Charles Duhigg
  12. Your Brain at Work - David Rock
  13. Start with Why - Simon Sinek
  14. Leaders Eat Last - Simon Sinek
  15. How to Win Friends & Influence People - Dale Carnegie
  16. How Google Works - Eric Schmidt
  17. Good to Great - James C. Collins
  18. The Last Lecture - Randy Pausch
  19. Mastery - Robert Greene
  20. Radical Candor - Kim Malone Scott
  21. Creativity, Inc - Ed Catmull, Amy Wallace
  22. Turn the Ship Around! - L. David Marquet

Email Lists

  1. Software Lead Weekly
  2. Threatpost Security Newsletter (Subscribe at the bottom of the page)

Training

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

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 #peopleops chat channel.

Being a public company

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

Biggest risks

We have a page which documents our biggest risks. Many of our values help to mitigate some of these risks.

Git is a trademark of Software Freedom Conservancy and our use of 'GitLab' is under license
View page source — Edit in Web IDE — please contribute. Creative Commons License