Staff+ Engineer is a leader! What does it mean?
Staff+ Engineer is a leader! What does it mean?
Before we answer the question in the header, one simple definition to make an ubiquitous language sure that we know about who we are talking about.
Staff+ Engineer in an IT organization usually refers to “uber”-senior individual contributor, who operates beyond writing code and handling simple tasks. There are many titles for such positions starting from simple Staff, including Principal or Distinguished, ending with Ninja or Master or just Architect.
When we search the internet or just use Chat-GPT as a source of knowledge we can get a list of responsibilities that typically includes:
Technical leadership
Strategic thinking
Providing engineering perspective
Problem solving at scale
Mentoring & coaching
Cross-teams collaboration
While the first few traits might seem like what comes with being "the best," if you think about it, a leader is someone with strong character and clear ideas on how tech processes should run. The focus shifts a bit from just deep knowledge to things like teamwork, mentoring, and setting up processes.
Moreover, unless they are not a company owner, they need to align the vision, current goals and challenges of the organization. If we add the requirement that most staff+ engineers should work as servant leaders to help teams on one hand side, and higher management on the other, the whole problem starts to look really complex and for sure it is not a role for everyone.
Diagnose yourself
In IT a promotion scheme is usually based on the Peter Principle. It was formulated by Dr. Laurence J. Peter, and it states that in a hierarchical organization, employees tend to be promoted based on their performance in their current role, rather than on their abilities relevant to the intended role. As a result, they eventually reach a level at which they are incompetent, as they no longer possess the skills required for their new responsibilities. The principle is often summarized as: You have been promoted to the level of your incompetence.
So before choosing a path of staff+ engineer it may be useful to diagnose yourself to avoid disappointment in such a position and avoid problems while working with others. A (not) funny example: according to Programmer Humor 4 out of 5 developers enjoy code review, so make sure that you are in this 80% 🙂
How to start then? There are a lot of different tools to find your strengths and weaknesses. In my case I used two: Clifton Strengths from Gallup and Extended DISC, but a lot of others exist including: Big Five Personality Traits, Myers-Briggs Type Indicator, and The 16 personality
The first one mostly focuses on individual strengths and in my case it confirms that I don’t have a good level of empathy. To be honest it is in 32th position out of 34. For sure it can be better 😅. But having such knowledge allows me to react or stop myself before “enjoying code review” 🙂 In my case it is not pressing <enter> too fast and asking fellow staff+ engineers to review my texts.
The same goes with Extended DISC, for example I know that I say what I think. Of course it is a good personality trait, but again if I as a junior would hear: “you totally f..ked up”, it won’t motivate me or make me a better engineer. Sometimes it doesn’t help with the conflicts too, especially when I had a third opinion.
Possessing knowledge about yourself and the others around you is helpful, especially that as a staff+ you work much more with stakeholders and teams than with code itself. Skills like communication, analysis or extracting the essence from knowledge become much more crucial. If you don’t have certain skills naturally, you just need to find a way to work with your weaknesses.
Knowledge
Staff+ are top performers who thrive on being the best in every topic. The A++ player, the best of the best, just like in Men in Black. To be honest when I was a young developer that was exactly how I imagined what staff+ should be.
But to be honest it is rather like in the joke about academic knowledge (aligned to the IT industry)
What should a junior developer know?
A junior developer should know how to code everything.
What should a mid-level developer know?
Almost everything the junior developer knows.
What should a senior developer know?
In which documentation is what the student should know.
What should a staff engineer know?
A staff engineer should know how to find documentation.
What should a principal engineer know?
Where the staff engineers are ;)
In the end of the day unfortunately as a staff+ you need stop being the best specialist in the room. Instead you need to have switch yourself into “m-shaped” or “comb-shaped” specialist
Why? Because you are hired to solve problems, not to be the best developer in the room. Moreover your authority is rather informal. Usually you don’t have a team which you are leading. On a typical day you are touching many areas. Just a hardcore example. Last Thursday I was involved in creating frontend app templates, I was verifying sizes of subnets for private networks, I was involved in discussion about metrics of services, I was explaining problems to business owners of AI services and I was checking the impact to the mobile application. You can summarize it as: I don’t know much about it, but I’ll still give my opinion. But to be honest that’s what’s expected from “above”, you need to have enough expertise and knowledge to help the organization to complete the task. But you don’t have to be “the best of the best”. On the other hand you need to build authority downward and that can be created only by your knowledge and your experience.
Adding value
At the end of the day, as a staff+ engineer, you are the one whose main task is to solve problems in the organization. Moreover, all eyes are looking at you in the technical tasks. While managers or scrum masters can always ask a universal question: “How would you solve that?”, as a technical guy usually you don’t have such an option. Your opinion matters. But don’t get me wrong. It isn’t a simple opinion without responsibility. It needs proof such as experience, possible options, or numbers. On the other hand, it needs to be presented in such a way that people will treat it with respect and will believe in it. That needs to be done in a magic way that combines soft and hard skills, because your leadership is leading by example, not by authority.
I'm an old fart now, and most of my college friends are no longer involved in technical topics, and I still do.
Intuitively I always wanted to avoid breaking with technology, as a result, I jumped from one technology to other, and such a feeling that I am not superb at anything.