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:
What does it mean to be an Engineering IC Leader
What are the skills needed to do the job
How the role differs from other Engineering management roles
Difference between technical credibility and technical leverage
Applying iteration to everything you do
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.
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.
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.
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.
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. The primary factor taken into the account when assigning a Tech Lead
role is efficiency, and optionally domain knowledge and/or expertise that might stem from
assigning this role to a given individual contributor.
