Leadership

Leadership

  1. Leadership at GitLab applies to everyone, whether an individual contributor or a manager.
  2. Everyone that joins GitLab should consider themselves to be an ambassador of our values and a protector of our culture.
  3. As a leader, team members will follow your behavior, always do the right thing.
  4. Behavior should be consistent inside and outside the company, don't fake it outside, just do the right thing inside the company as well.
  5. In tough times people will put in their best efforts when they do it for each other.
  6. We work async, lead by example and make sure people understand that things need to be written down in issues as they happen.
  7. 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.
  8. It is encouraged to disagree and have a constructive confrontation but please argue intelligently.
  9. We avoid meetings because those don't support the asynchronous work flow, are hard to conduct due to timezone differences and are limited only to those attending them, making it harder to share.
  10. 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 anyone or repeating things for people that come late.
  11. We give feedback, lots of it, don't hold back on suggestions to improve.
  12. If you meet external people always ask what they think we should improve.
  13. As Paul graham said: strive to make the organization simpler.
  14. We don't have project managers. Individual contributors need to manage themselves. Not everyone will be able to do this effectively and be fit for our organization. Making someone responsible for managing others will make the job of the people that can manage themselves worse. 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.

Management

  1. When times are great be a voice of moderation, when times are bad be a voice of hope.
  2. A span of control should be around 7, from 4 to 10. Lower means too many generals and too few soldiers. Higher means you don't have time for 1:1's anymore.
  3. If you praise someone try to do it in front of an audience, if you give suggestions to improve do it 1 on 1.
  4. As soon as you know you'll have to let someone go, do it immediately. The team member is entitled to know where they stand. Delaying it for days or weeks causes problems with confidentiality (find out that they will be let go), causation (attributing it to another reason), and escalation (the working relationship is probably going downhill).
  5. When performance is below par we normally put someone on a performance improvement plan (PIP). Use a PIP when you are convinced that the team member will be great for year to come after completing the plan. If you would not hire a team member if they applied for this role today offboarding is a better step.
  6. When someone says they are considering quitting drop everything and listen to them by asking questions to find out what their concerns are. If you delay the person will not feel valued and the decision will be irreversible.
  7. People should not be given a raise or a title because they ask for it or threaten to quit. We should pro-actively give raises and promote people without people asking. If you do it when people ask you are disadvantaging people that don't ask and you'll end up with many more people asking.
  8. Don't refer to team members as family. It is great that our team feels like a close-knit group and we should encourage that, this builds a stronger team. But families and teams are different. Families come together for the relationship and do what is critical to retain it. Teams are assembled for the task and do what is required to complete it. Don't put the relationship above the task. Besides, families don't have an an offboarding process.
  9. Praise and credit the work of your reports to the rest of the company, never present it as your own. This and many other great lessons in an ask metafilter thread worth reading.
  10. Try to be aware of your cognitive biases.
  11. Great article about how to think about PIPs, although our time scales are shorter.
  12. Do everything to unblock people. For example, if someone has a question that is keeping them from being productive, try to answer the question or find someone who can.
  13. Communicate in a professional manner as though your words will be shared widely (e.g. published in a newspaper).
  14. You are expected to respond on social media.
  15. Make sure your reports experience a sense of progress in their work.
  16. A tweet by Sam Altman combined the reply by Paul Graham says it best: "People either get shit done or they don't. And it's easy to be tricked because they can be smart but never actually do anything.". Watch for results instead of articulate answers to questions, otherwise you'll take too much time to identify under-performers.
  17. Our summits are meant for informal communication and bonding across the company. There is a limited time for business activities during the summit so all our regular meetings should happen outside of the summit. We want informal, cross team, open-ended meetings, that includes individual contributors, for example inviting everyone including sales to suggest currently missing functionality in GitLab. Formal, team restricted, structured meetings, where not everyone is welcome shouldn't happen, for example an executive team meeting to set the yearly budget. Never delay a decision until the summit, if anything use the summit as a deadline to get things done earlier.
  18. 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.

Grovo

Grovo is a Learning Management System (LMS) that delivers, short, engaging learning tracks which are groups of video lessons and quizzes focused on a skill. Finishing the lessons and quizzes in a learning track earns you points and certifications. Whether you're on your desktop, laptop, tablet, or phone, you can pick up where you left off at any time. A big part of how this learning is delivered is by using a method called Microlearning.

What is Microlearning?

Microlearning provides short bursts of information that can be applied right away, helping people build the skills they need to be successful at their jobs. Think of these bite-size pieces of learning like sentences: each conveys just one complete thought, but when you put a few of them together, you build a more complex idea. Each microlearning moment is made of a digestible morsel of information combined with a short practice exercise. It's hyper specific, so you can get the right help, right when you need it: like when composing an email, working with new spreadsheet software, or practicing a big speech. Bit by bit, these microlearning moments add up to better job performance today and continual improvement going forward. Microlearning isn't just breaking up content into smaller pieces. It's a way to make learning digestible and effective, transforming not just what you know, but what you actually do, every day.

Grovo at GitLab

We're a remote and globally distributed team that requires something more than the traditional learning approaches and courses that currently exist. We want to foster a new way of learning that mirrors GitLab's culture.

Take a coffee break with Grovo and see how much you can learn. It can take just under 60 seconds to sharpen your skills!

The initial phase of rolling out Grovo will take place in December 2016 and as part of that first step we will be offering learning tracks on professional development & compliance.

No matrix organization

  1. We believe everyone deserves to report to exactly one person that knows and understands what you do day to day. We have a simple hierarchy, everyone has one boss that is experienced in their subject matter. Matrix organizations 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 boss 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 and many other 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 limited amount of time.
  9. Everyone deserves a great boss that helps you with your career, lets you know when you should improve, hires a great team, and motivates and coaches 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." in the great guide to big companies from Marc Andreessen (the other guides are awesome too).
  11. On this page we recommend to read 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 want to promote organic cross-functional collaboration by giving people stable natural counterparts. A sales region will consist of a Sales Development Represenative, Account Executive (AE), and Success Engineer (SE). A strategic customer has an AE, Account Manager (AM), and SE assigned. Every backend team of developers maps to a Product Manager (PM) and eventually a mapping frontend team.
  13. Functional companies are easier when you focus on one product. Apple focusses on the iPhone and can have a unitary/functional/integrated organizational form. The advantage is that you can make one strong integrated product. But we can 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 by using our own product also helps.

Articles

  1. eShares Manager’s FAQ
  2. eShares 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.

Books

Note: Books in this section can be expensed.

  1. High Output Management 1. Andrew Grove (top 10)
  2. The Hard Thing About Hard Things: Building a Business When There Are No Easy Answers 1. Ben Horowitz
  3. The score takes care of itself 1. Bill Walsh
  4. Crucial Conversations: Tools for Talking When Stakes Are High 1. Kerry Patterson

People Operations

Feel free to reach out to any of the People Operations Team for further support on leadership development topics. You can find us on the team page Joan Parrow, Abby Matthews, Brittany Rohde, Nadia Vatalidis and Sasha Bannister.