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 and gather data to help with planning, addressing technical debt, capacity to work on bugs, identifying bottlenecks and improving engineering efficiency. The goal of establishing these metrics should never be punitive. Engineering metrics are gathered to support a healthy dialog amongst the engineering team and with stakeholders. It is important to note that engineering metrics are project or team based and are not intended to track an individual's capacity or performance.
Measuring throughput. We are currently exploring using throughput to measure and track capacity. Throughput, is a measure of the total number of issues that are completed and in production in a given period of time. Unlike velocity, throughput does not require the use of story points or weights, instead we measure the number of issues completed by a team in the span of a week or a release. Each issue is represented by 1 unit/point. This calculation happens after the time period is complete and no pre-planning is required to capture this metric. The total count should not be limited to only issues that deliver features, it's important to include engineering led issues in this count as well. This will insure that we properly reflect the team's capacity in a consistent way and focus on delivering at a predictable rate.
Why we adopted this model?
The goal for using this measure is to incentivize teams to break issues to the smallest deliverable which lead to a smaller set of changes and the many benefits that come along with that.
This practice aligns with one of our core values: Iteration, do the smallest thing possible and get it out as quickly as possible.
Instead of spending time sizing and figuring out the weight of an issue, we should put this effort toward breaking issues to the smallest deliverable.
Since throughput is a measure of actual work completed, it is far more accurate than using weights.
Throughput is a simpler model to implement for new teams since the measure is the count of small well defined issues.
Unlike weights which may be estimated differently from one team to another, throughput can be normalized across every engineering team.
A few notes to consider when using this model:
There are many activities such as code reviews, meetings, planning that we do not count as units of work independently, they are however accounted for as part of the delivery of an issue whether it be feature work or technical debt. The team's rate of delivering code to production is what we are trying to measure.
While there is no scoring required with this model, there is still value for an Engineering Manager to look through each issue they are committing to in any given release and making sure they are well defined small deliverables.
When combined with cycle time, throughput is a great metric to help you identify areas of improvement and possible bottlenecks that the team can work to address.
