At GitLab, we promote two paths for leadership in Engineering. While there is a healthy degree of overlap between these two ideas, it is helpful and efficient for us to specialize training and responsibility for each of:
While technical leadership tends to come naturally to software engineers, professional leadership can be more difficult to master. This page will serve as a training resource and operational guide for current and future managers.
All Engineering Managers should follow the general leadership principles set out in the handbook. In particular, it is not uncommon for Engineering Managers to struggle with one or more of the following areas, so we recommend you review them carefully and discuss your confidence with your manager:
Hiring is a priority. GitLab is a fast-growing company, and paying attention to hiring is one of the highest-leverage activities a manager can perform. As long as there are vacancies on your team, hiring should be your top priority.
Hiring is your responsibility. You may rely on other members of your team to help you evaluate potential candidates. We also have many people at GitLab, most notably in Recruiting, who will help you through the process. But it is always your responsibility to make timely, high-quality hires - speak up if you feel like anything is preventing you from accomplishing this goal.
Hiring is about making the team better. It is easy to try to find candidates who can merely perform the functions of the role, and more difficult to find people who make the team better while they do it.
Hiring is hard. It often involves making difficult decisions, and learning to do it well can take years. In times of rapid growth, it may consume 50% or more of your time. Please use every resource available to you, from more experienced hiring managers in the company to the many resources available in our handbook.
Technical Credibility
We expect all managers at GitLab to be technically credible with their teams. Fluency in our core technologies and architectures is essential because it enables managers to participate effectively on technical conversations. In order to maintain this fluency, we encourage managers to participate in coding-related work to an extent. However, please keep the following advice in mind:
Avoid critical path work. If work has been scheduled for a release or is otherwise blocking other members of the team, it's best left to a developer who can focus on it more holistically. As a manager you should expect regular interruptions to your day that will make you less effective on this kind of task.
Focus on where you can add the most value. As mentioned above, you won't add value on critical path work, but that doesn't mean you can't add value in other ways. For a great discussion on this, see this article on How (and why) Should Managers Code.
Plan to review more than you write. Following from all of this, most of your "coding-related work" should be in code review - you add more value reviewing code to stay up to date with your team and provide them feedback and guidance. If you find yourself spending more time writing code than you do reviewing it, this may be an indicator that you need to revisit your priorities as a leader.
Career Coaching for Developers
Outside of hiring, the best way to improve the strengths of your team is to practice career development coaching with your developers. While they will not all become Staff Developers or Engineering Managers at GitLab, identifying their career goals and proactively working towards them is the most effective way to help everyone improve. In addition to the company-wide notes on career mapping and development, here are some important considerations for the Engineering team:
Technical or Professional Leadership? This is the first section on our career development page for a reason. For Senior Developers, this is the most important question to ask about their career goals, as it will determine where they go next. For anyone who hasn't yet made Senior, this is less important - they need to make Senior first - but it's always a good idea to start talking about this fork in our career paths.
Assess together. Once you know where your Developer wants to go with their careers, it's time to assess their strengths and weaknesses for the position. This is best done by reviewing the responsibilities and requirements of the job they're interested in. If you both assess it separately, you can compare and contrast your results.
Create a behavior-based plan. Once you understand the Developer's strengths and weaknesses, help them understand how they can improve by focusing on behaviors they can change. Be careful to avoid tasks like "run this meeting" or "complete this project," and be careful to avoid personality traits like "be less angry" or "be more assertive." "When you realize you're in an argument, take a breath and figure out how to move forward constructively" is an example of a good behavioral action.
Delegate and give feedback. When you are in agreement about the behavioral action plan, start looking for opportunities to delegate appropriate tasks to the Developer. A Senior looking to move to Staff may benefit from taking some architectural conversations off of your plate, while one looking for a Manager job will learn a lot from tackling some project management initiatives.
Keep the plan updated. It's important to remember that this is a coaching plan, not a promotion plan. There is never any guarantee that the plan you created will result in a promotion if the Developer "checks all the boxes," and you should feel free to add to or remove from the plan as they grow and you learn more about them. If and when you feel that they are ready for promotion, please follow the normal promotion process.
Project Management
Product is responsible for guiding the direction of our product, and technical leaders are responsible for guiding the technical architecture to meet those requirements. While Engineering Managers can and should participate in both of those conversations, their primary responsibility lies in project management: making sure their team is best positioned to meet both goals as effectively and efficiently as possible.
Capacity tracking/planning - while heavy methods of estimation don't fit well with our approach to work, it's your responsibility to keep an eye on the capacity of your team. This allows you to predict capacity, which helps with product planning, and also detect problems earlier if an important schedule is likely to slip.
Collaboration with stakeholders - in addition to Product Managers and members of your team, you are the primary point of contact for any other stakeholders for the work your team is doing. You should expect to spend time communicating clearly and thoroughly about the state of your ongoing projects.
Be aware of your team's status. Change can happen quickly - the more you know about what your team is working on and how it's going, the better you'll be able to make the best decisions.
Balance engineering initiatives - make time for engineering-led initiatives balanced against product's needs for your team.
There are many ways to develop engineering metrics, ideally you need a representation of different aspects of the operational data such as throughput, quality and cycle time to name a few. The goal of gathering this data is to foster a healthy dialogue amongst the engineering team and with stakeholders. These metrics are helpful for conversations around planning, addressing technical debt, capacity to work on bugs, identifying bottlenecks and improving engineering efficiency. It is important to note that if metrics are used punitively, these goals are hampered and the team psychological safety could be at risk.
Engineering metrics are project or team based and are not intended to track an individual's capacity or performance.
To access our current dashboard, please visit the GitLab Insight Quality Page. We are currently working to implement these graphs into the GitLab product.
To read more about each metric, please visit their dedicated pages.
List of Metrics
Throughput: This is our measure for number of MRs merged in a defined time frame (week and months). The current calculations includes merges in all branches and not just master.
Data for throughput is available at the weekly and monthly level. We show 12 weeks for weekly and 24 months for monthly views.
Average MRs merged per author per Month: This is our measure calculated by the total number of MRs merged in a given month divided by the total unique authors who created those MRs. We currently get all the unique authors from that period and not just filtered to engineering.
DeprecatedAverage MRs merged per engineer per Milestone: This is our measure calculated by the total number of MRs merged in a given milestone divided by the total unique engineers who created those MRs.
Known issues This chart is deprecated. Data at the milestone level has proven to be less accurate. The reason is because of a lack of milestone hygiene due to missing or wrong milestones assigned to the MR. As a result we have moved to track data on a Time-Period basis via weeks/months. Please refer to the chart above instead.
Known issues Data here is dependent on the regression:x.y label. It is possible that some regressions are not captured due to it not having a regression label.
Data included in calculation
Engineering wide projects
We are currently working on including all of engineering's projects. The following projects included can be seen in this list.
Security fixes on dev instance
We also capture data from our https://dev.gitlab.org/ instance which currently includes the projects below.
gitlabhq (CE)
gitlab-ee
gitaly
gitlab-shell
gitlab-pages
GitLab runner
The data from dev instance is only reflected in a few group level charts, see list of known issues below.
Known issues
Due to the lack of team labels on https://dev.gitlab.org/, only the 3 group-level charts below are reflected with data from this source.
