liked hmemcpy's tweet
Il sapere umano appartiene al mondo.
liked hmemcpy's tweet
liked FiloSottile's tweet
in reply to
@searls I’m a staff engineer at GitLab, here it’s an IC role alternative to management but still based on leadership and communication skills
What is a staff-level engineer? We recently started talking about title inflation at work, and I’ve found myself involved into that conversation.
This forced me to think about my role from my own point of view, as well as from the company point of view.
So I came out with the following write-up.
What follows, unless it got merged in the handbook, are only my opinions. 😀
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 Leadership is an alternative career path to Engineering Management.
Just like moving into management, also moving from Senior to Staff changes your day-to-day work and expectations placed on you.
IC Leaders exert technical leverage in their scope of influence. Like any other leadership role, the focus should be on helping others to improve. Your impact multiplies with every person you help grow, and the company gets more value when you’re not investing time in doing things yourself.
Your technical skills developed in your career up until now are still very important, and the role is still hands-on technical. Your technical skills are vast and are developing at a lower rate of change now, but you also get new skills that will drive your career from now on: Communication, Collaboration, and Leadership.
If you ask Staff+ engineers what does Staff level mean at GitLab, you will get very different opinions.
There are four common archetypes of Staff-plus roles in the industry that could explain this variability in opinions:
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+ IC 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 level engineer partners with the Engineering Manager and the Product Manager for milestone planning and helping teammates addressing complexity with their deliverables.
This still 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 engrained 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, as a Solver not only you deal with the problem at hand, but also make sure the team is empowered to take care of your work once the complexity level is manageable by the team.
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 Engineering Leaders, that are decision-makers in such cases. 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. Engineering Leaders 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.
This article is extracted from this merge request .
There are challenges in being both a SaaS and an on-premise product.
Yesterday Atlassian announced the stop on new licenses for on premise installations.
On February 2, 2021 PT, we will stop selling new licenses for our server products and cease new feature development in our server product line.
As a Delivery engineer at GitLab I can definitely understand that choice.
Delivering a product that is both SaaS, with multiple no-downtime deployment each day, and making sure that the same product can be installed on-premise, without downtime, with a monthly package takes a lot of effort.