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.
A group is any arrangement of people that is not reflected directly in our org structure.
Members of the management group are expected to demonstrate leadership in the way all GitLab team members are, plus:
#team-member-updateschat channel (but only after the Google/Slack accounts are revoked, see the offboarding page and the offboarding checklist for details). We must respect the privacy of the individual concerned. If you are asked why someone has left or is leaving, please refer that person to the general guidelines section of the handbook where we describe what can and cannot be shared.
Members of the director group are expected to demonstrate leadership in the way all members of the management group are, plus:
This is an uncommon title and a small group that is nominated by the E-group. Please don't set expectations with internal/external candidates without initiating the discussion with the CEO first. The CEO has approval on addition of all these titles.
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.
You may occassionally hear of the E-Group hosting an "All-Directs" call or meeting. The All-Directs group is made up of anyone who reports directly to the e-group. It is made up of some ICs, some managers, some directors, and some senior leaders. This group is called on to help provide input and communicate messaging when appropriate. As an example, the all-directs meets after every e-group offsite.
Elon Musk sent out this email with the subject line "Communication Within Tesla":
There are two schools of thought about how information should flow within companies. By far the most common way is chain of command, which means that you always flow communication through your manager. The problem with this approach is that, while it serves to enhance the power of the manager, it fails to serve the company.
Instead of a problem getting solved quickly, where a person in one dept talks to a person in another dept and makes the right thing happen, people are forced to talk to their manager who talks to their manager who talks to the manager in the other dept who talks to someone on his team. Then the info has to flow back the other way again. This is incredibly dumb. Any manager who allows this to happen, let alone encourages it, will soon find themselves working at another company. No kidding.
Anyone at Tesla can and should email/talk to anyone else according to what they think is the fastest way to solve a problem for the benefit of the whole company. You can talk to your manager's manager without his permission, you can talk directly to a VP in another dept, you can talk to me, you can talk to anyone without anyone else's permission. Moreover, you should consider yourself obligated to do so until the right thing happens. The point here is not random chitchat, but rather ensuring that we execute ultra-fast and well.
These principles also apply to GitLab. 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 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:
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.
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:
Please see /handbook/leadership/1-1.
Please see /handbook/leadership/skip-levels.
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:
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.
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 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.
Managers have an tremendous responsibility around recruiting and retention of team members.
Note: Books in this section can be expensed.
We sometimes self-organize book clubs to read through these books as a group.
When you give leadership training please screenshare the handbook instead of creating a presentation.
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, search for
People Operations. The team may also be reached in the
#peopleops chat channel.
Learn more on GitLab's view of being a public company.