Engineering IC Leadership

Engineering IC Leadership at GitLab: going beyond Senior level

At GitLab, it is expected that everyone is a manager of one. For Individual Contributors (IC) a new type of challenge begins with the Staff Engineer role. Engineering IC Leadership is an alternative career path to Engineering Management.

Just like moving into management, also moving from Senior to Staff changes the day-to-day work and expectations placed on ICs.

Engineering IC Leaders exert technical leverage in their scope of influence. Like any other leadership role, the focus should be on helping others to improve. Their impact multiplies with every person they help grow, and the company gets more value when they’re not investing time in doing things themselves.

Technical skills developed in their career up until now are still very important, and the role is still hands-on technical. Their technical skills are vast and are developing at a lower rate of change now, but they also get new skills that will drive their career from now on: Communication, Collaboration, and Leadership.

What GitLab Engineers Have to Say About IC Leadership

During a Handbook Learning discussion, Eric (former Chief Technology Officer), Engineering IC Leaders, and the Learning and Development team discuss Engineering IC Leadership. We discuss topics during an interactive handbook discussion about what it means to be an IC leader.

Start with a level set. You have an intermediate Engineer, then they become a Senior Engineer, and there’s a fork in the road. There is a dual career track where you can choose the “manager track” or the “IC Leadership track.” - Eric Johnson (former Chief Technology Officer)

Additional topics covered in the discussion include:

  1. What does it mean to be an Engineering IC Leader
  2. What are the skills needed to do the job
  3. How the role differs from other Engineering management roles
  4. Difference between technical credibility and technical leverage
  5. Applying iteration to everything you do
  6. The four archetypes and how they define the work of IC Leadership

Technical Leverage

Technical leverage could be described as doing technical work that has a multiplicative impact. It frequently involves activities that are not writing code.

In other words, the impact of the work has a positive effect on more than your personal scope and the immediate or near-term time frame. It should help those around you and in your team, group, or department operate and iterate more efficiently.

Examples of this are:

  • Taking part in our architecture process
  • Implementing generic solutions to problems that can be easily reused in the future
  • Identifying commonalities to multiple problems and solving several at once
  • Sharing knowledge via trainings or presentations to boost efficiency
  • Identifying and removing roadblocks to the development process

The four archetypes

Staff Engineers and Engineering Managers shared their perspective on what does Staff level mean at GitLab in an Unfiltered blogpost. Much of what each engineer said overlapped, but each had a unique perspective based on their team and their particular experience within GitLab as an entity.

There are four common archetypes of Staff-plus roles in the industry that could explain this variability their perspective:

  • The Tech Lead guides the approach and execution of a particular project. Most frequently they partner closely with a single manager, but sometimes they partner with two or three managers within a focused area. At GitLab, Tech Lead is not only an archetype, but it is also a role
  • The Architect is responsible for the direction, quality and approach within a critical area, both today and stretching into the multi-year future horizon. They combine a deep knowledge of technical constraints, user needs, and organization level leadership.
  • The Solver digs deep into arbitrarily complex problems and finds an appropriate path forward. Some focus on a given area for long periods, others bounce from hotspot to hotspot as guided by organizational leadership.
  • The Right Hand is a partner and an extension of an executive-level manager, borrowing their scope and authority to operate particularly complex organizations. They provide additional leadership bandwidth to leaders of large-scale organizations.

The four archetypes at GitLab

The four archetypes are patterns of behavior. We expect our Staff+ ICs to exhibit behavior from all the archetypes. The individual inclination will usually make one (or more) of them more prominent, but they all define Engineering IC Leaders.

Tech Lead

The most common archetype for a new Staff Engineer is the Tech Lead, as a Senior Engineer may start showing Staff level behaviors emerging from their team. At GitLab, this is not only an archetype but also a role assigned to engineers on per-project basis. Read more about this on a dedicated Tech Lead Handbook page.

A Staff Engineer partners with the Engineering Manager and the Product Manager for milestone planning and helps teammates address complexity with their deliverables. This also applies on levels above Staff+, partnering with their peers in Management and Product.

Architect

At GitLab Architecture is a practice where everyone can contribute but Staff+ Engineers play a fundamental role in that.

Architecture as a practice is everyone’s responsibility, but it is notably ingrained in senior technical leadership roles, where the roles’ levels and their sphere of influence determine DRI responsibilities within the practice.

Solver

Complex problems often require a Staff+ Engineer to handle the first iterations in order to reduce the level of complexity to a manageable state. Routinely being handed the hardest, least-specified, or most-uncertain work is part of this archetype. As well as guiding other ICs in the team when they’re struggling to find a solution.

Other teams may need a Staff+ Engineer on loan. The receiving team may or may not already have a Staff+ Engineer, a Solver deals with the problem at hand, and makes sure the team is empowered to take care of the work once the complexity level is manageable.

Right Hand

One of the conclusions from our work on Architecture Practice at GitLab is that introducing complex architectural changes can not happen without Staff+ ICs working closely with the decision-makers. This conclusion highlights the need for a close collaboration between Engineering Manager+ and Staff+ Engineers, and it fits very well into the Right Hand archetype definition.

Staff+ Engineers are supposed to broaden the perspectives of their managers. Decision-makers often need the additional context and perspective to make well-informed decisions about investments in the product architecture, understanding expected ROI, and a core technical vision behind such changes.

Building meaningful relationships based on trust will make this whole process smoother and will distribute leadership, both technical and managerial, at every level, from single teams up to department level.


Tech Lead at GitLab
Tech Lead at GitLab At GitLab, Tech Lead is an archetype and a role. When we think about “Tech Lead” as an archetype we mean that Staff+ Engineers at GitLab are supposed to exhibit patterns of behavior that make them act as technical leaders, who partner with Engineering Managers and Product Managers to support milestone planning, coordination, sequencing and then help teammates address complexities with their deliverables. “Tech Lead as an archetype” is an expectation, especially for Staff+ Engineers, but “Tech Lead as a role” can be assigned to any Engineer, regardless of their seniority.