--- title: "What does Staff level mean at GitLab?" author: Charlie Ablett author_gitlab: cablett author_twitter: gitlab categories: unfiltered image_title: "/images/blogimages/staff-engineering.jpg" description: "Get a multifaceted view of Staff level Engineering at GitLab" tags: engineering career development ee_cta: false # install_cta: false # --- {::options parse_block_html="true" /}    This blog post is [Unfiltered](/handbook/marketing/blog/unfiltered/#legal-disclaimer)    {: .alert .alert-webcast} # What does Staff level mean at GitLab? At GitLab, [Backend Engineers](/job-families/engineering/backend-engineer) and [Frontend Engineers](/job-families/engineering/frontend-engineer) work together with Product, Design, Quality, and Security to improve the product and address technical challenges. At the [Senior](/job-families/engineering/backend-engineer/#senior-backend-engineer) level, they are expected to address the most complex challenges within their team, as well as help their team members with technical blockers and process improvements. When considering a [career direction](/handbook/engineering/career-development/#roles) within GitLab, Senior Backend and Frontend Engineers can choose either to advance on the managerial track to become an [Engineering Manager](/job-families/engineering/engineering-management/), or on the Individual Contributor (technical) track to become a [Staff Backend Engineer](/job-families/engineering/backend-engineer/#staff-backend-engineer) or [Staff Frontend Engineer](/job-families/engineering/frontend-engineer/#staff-frontend-engineer). Each job description gives some idea of the responsibilities a Staff Engineer is expected to have, but how does that look in practice? Current and previous Staff Backend Engineers and Engineering Managers kindly agreed to talk to me in a series of one-on-one interviews. As someone considering the technical track to become a Staff Backend Engineer, I wanted to find out what exactly it entails. 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. **note**: The following is based on the experience of Staff backend engineers at GitLab, but there will be future explorations into the world of Staff level of Design, Technical Writing, and other positions that can be Staff. The following sums up the perspective of each of the engineers, with my takeaway _in italics_. ## What Staff Backend Engineers said [**Jacob Vosmaer**, @jacobvosmaer-gitlab](https://gitlab.com/jacobvosmaer-gitlab) (Amsterdam, the Netherlands), leverages his chronological knowledge of GitLab from when it was small enough to be understood by one person. This gives him the foundation to understand the product from a systemic perspective. GitLab is now an enterprise-scale complex project, and uses many third-party open-source libraries as part of its product.
_A Staff Engineer can recognize a good solution when they see one, and able to clearly explain its merits to other engineers, community members, managers or customers._ [**Sean McGivern**, @smcgivern](https://gitlab.com/smcgivern) (Edinburgh, Scotland) provided some historical context - Staff used to mean a role specifically on a team, but now it's more of a multidisciplinary role. The impact of Staff Engineers is predicated not purely on advanced technical skill, but their ability to collaborate across teams. As a former Engineering Manager, he identified an overlap between the leadership and time management skills required by Staff Engineers and Engineering Managers.
_A Staff Engineer has a broad skill-set with in-depth expertise in several areas (see ['Paint Drip' people](https://www.facebook.com/notes/kent-beck/paint-drip-people/1226700000696195/)*)._ [**Ash McKenzie**, @ashmckenzie](https://gitlab.com/ashmckenzie) (Geelong, Australia) noted that reaching beyond his team can mean finding and identifying a niche that needs a champion, and working to improve it without oversight. In Ash's case, his high-leverage work on the GitLab Development Kit (GDK) means he can help every person working on the GitLab codebase to become more efficient by removing technical blockers in the GDK itself.
_A Staff Engineer leverages their increasingly on-demand time to help others, efficiently unblock them and enable them to move forward._ [**Nick Thomas**, @nick.thomas](https://gitlab.com/nick.thomas) (Shetland, Scotland) identified that one way to thrive at the Staff level was to identify systemic improvements. This may involve slow, steady identification of system-level challenges, rather than solving immediate time-sensitive issues.
_A Staff Engineer is asked for technical opinions more often than at Senior level, and it allows them to have a greater technical and cultural impact._ [**Andreas Brandl**, @abrandl](https://gitlab.com/abrandl) (Hamburg, Germany) noted that levels above Senior require increasing familiarity with the company, processes and culture in order to thrive. Because GitLab encourages anyone in the company to [question anything](/handbook/values/#anyone-and-anything-can-be-questioned), it allows dynamic, iterative improvements to processes. Staff level engineers can demonstrate this publicly and encourage, enable and support others to do the same.
_A Staff Engineer questions anything, looks for process improvements and encourages the documentation of processes for clarity and transparency._ [**Dylan Griffith**, @DylanGriffith](https://gitlab.com/DylanGriffith) (Sydney, Australia) emphasized the role of reaching out beyond your team and collaborating with others across GitLab and in the wider community. By familiarising themselves, with the vision of the product itself as well as its business value, this allows Staff Engineers the ability to better identify cross-team issues that may have escaped notice. By familiarising themselves, with the vision of the product itself as well as its business value, this allows Staff Engineers the ability to better identify cross-team issues that may have escaped notice.
_A Staff Engineer identifies and addresses cross-team problems that may otherwise fall through the cracks and liaises with management, Product and customers to steward delivery to completion._ [**Fabien Catteau**, @fcatteau](https://gitlab.com/fcatteau) (Compiègne, France) focused on knowledge management and transfer within the context of a broader technological vision, which complements the Product vision. Since GitLab is an enterprise-scale product, nobody can know everything - so Staff level engineers balance sharing what they know and being comfortable with asking for help. It's important to understand what skills and knowledge are missing from a discussion, reaching out to who knows the missing piece, and bringing them into the conversation.
_A Staff level engineer not only focuses on constantly improving their own knowledge of the product, but enthusiastically empowers other developers to do the same._ [**Rémy Coutable**, @rymai](https://gitlab.com/rymai) (Cannes, France) spoke particularly on having the courage to address problems outside your team or area of expertise. As a Staff level engineer, your ability to show the values by example is amplified. Visibly asking for help and bringing in experts from other area of the product encourages others to do the same.
_A Staff Engineer reaches beyond immediate technical needs, independently considering the longer-term, and is always looking beyond for ways to have a broad impact._ [**Grzegorz Bizon**, @grzesiek](https://gitlab.com/grzesiek) (Olsztyn, Poland) explained the difference between Senior and Staff as not much different technically, but a Staff level engineer collaborates more with other team members and leverages their understanding of human nature to broaden their impact across the product. He emphasised kindness as one of the most important values, and at Staff level there is greater opportunity, and responsibility, to help others.
_A Staff Engineer is kind, supporting others and helping them grow and succeed in a holistic way, not just limited to technical help._ [**Rachel Nienaber**, @rnienaber](https://gitlab.com/rnienaber) (London, UK) has a unique perspective as an Engineering Manager who has helped multiple Engineers attain promotions, including one to Staff level. She emphasised leveraging leadership competencies to facilitate technological discussions and either owning or delegating projects to completion. Using your voice in technical discussion is like a muscle - the more you use it, the more natural the activity feels and the more confident you will become to contribute more often. So she encourages all engineers to contribute in discussions, even if they aren't always 100% certain.
_A Staff Engineer dovetails technical strategy to product strategy, helping the team to be more productive while interfacing with other teams._ [**Yorick Peterse**, @yorickpeterse](https://gitlab.com/yorickpeterse) (Hilversum, the Netherlands) described Staff level Engineering in terms of anticipating future needs and understanding the broader technical vision of the product. To him, Staff level engineers proactively identify problems, define scope and work with stakeholders, Product and team management. The expectations of quality, technical acumen and communication are higher once an engineer hits Staff level, as well as ongoing collaboration outside the team.
_A Staff Engineer bridges the gap between Management focusing on capacity planning and timing for the future, and individual contributors carrying out the work._ ---- ## The common threads Each of the Staff Engineers interviewed above shared valuable insights. Although they had slightly different perspectives based on their team and history with the company, they all independently mentioned the following: - Proactive problem identification - Cultural stewardship - Knowledge sharing - Technical empowerment - Broader impact beyond the team - Working on [Staff level problems](https://lethain.com/mailbag-beyond-career-level/) ## Knowledge and vulnerability It's impossible to know everything, yet it's very common for software developers to think that not knowing something is a sign of weakness or failure. This puts Staff Engineers in a unique position - despite being a position where they are expected to have advanced technical acumen, it requires that they become comfortable with admitting 'not knowing'. They can then help others to understand that achievement in software development is not solely about knowing things especially in an enterprise-scale product such as GitLab. Presented here are some ways in which all engineers (and not just at the Staff level and beyond) can actively encourage others to be their best selves. - Admitting "I don't know" - Enthusiastically giving credit and thanks - Always be encouraging and recognise effort - Sharing knowledge efficiently - Asking questions without shame - Not shaming others for not knowing - Being direct and kind when giving feedback ## Technical impact There are many ways in which a Staff Engineer can leverage their skill-set for impact outside their team. Even one or two of the following can help others be more effective and efficient. - Facilitating fixes of [broken master](/handbook/engineering/workflow/#broken-master) and helping others to do so - Assisting support, the security team and site reliability engineers with investigating customer issues - Providing technical assistance with customers and stakeholders, including voice calls - Performing system architecture analysis and design - Being responsible for a feature, project or framework and becoming an expert so others can ask - Identify system-level improvements and deficiencies, and bring them to light - Identifying and developing a technical vision complementing the Product vision ## Know your impact It's easy to feel that in order to become a Staff Engineer, you must do all the above flawlessly. While it's good to have experience with the challenges that come with an enterprise-level product, it's not mandatory to handle them all. It's about how you can leverage _your personal skill set_ for maximum impact. To get an idea of where your strengths lie in context, it is important to write down everything you do, as you know your work best. (This applies even if you're not interested in a promotion - it's good practice for your CV too!) Write down everything you've done, even if they are minor things. You may be surprised at looking back and seeing how much you've accomplished, and how you've made the product better. ## What this means for career development This information is helpful for GitLab team members looking to advance their careers. [GitLab encourages team members to champion their own promotions](/handbook/people-group/promotions-transfers/#introduction), supported by their managers, and to demonstrate performance rather than potential. Once you understand your impact, you can apply evidence-based arguments to present [a solid case for promotion](/handbook/people-group/promotions-transfers/#creating-a-promotion-or-compensation-change-document). GitLab prefers to hire Backend Engineers at Senior level because at the Staff level, engineers are expected to have a wider context of the entire product and the organisation itself. This allows them to independently identify and solve problems that are cross-team and cross-discipline, as well as know who would be able to provide context and support for particular challenges. Engineers at the Staff level also have an amplified cultural stewardship role, as they demonstrate the [GitLab values](/handbook/values) by example. By gathering the perspectives of our Staff Backend Engineers, I hope that other folks at GitLab, whether or not they are in Engineering, can gain a broader perspective of what being Staff means. 🌟️ Sean McGivern asked me to add that he got this phrase from [Andrew Newdigate](https://gitlab.com/andrewn), a Distinguished Engineer. 🌟 Photo by Philip Swinburn on Unsplash unsplash-logoPhilip Swinburn