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.
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:
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:
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 four archetypes are not roles, and we don't map our Staff+ ICs to them. Still, they provide a framework for matching market titles and responsibilities. They also explain the presence of multiple Staff+ in a single team.
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.
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.
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.
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.
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.
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.
