The Principal/Staff engineer role has gained quite some traction as of 2023 and it is quite common for companies to invest in this role. Given the ambiguous nature of this role, many individuals still struggle to find their feet on how to be successful in this role. The variety of tasks in this role depends a lot on what is the area of scope of an individual. It has been observed that there are quite a lot of tasks which might not come out to be that technical. I am not talking about certain “glue like” tasks where a Principal/Staff engineer fills in the gaps in existing processes in place.

Note: Throughout this post I am using the term “staff engineer” to refer to the role of a senior individual contributor which is the next level of a Senior Engineer. In most of the companies the title for this role is “staff engineer”, “principal engineer” or a “tech lead”.

As a staff engineer, you spend quite a lot of time in solving problems within your area of scope, and sometimes you go beyond this and even discover and define those problems. It has been observed that some of these tasks are not overly technical and the benefits for such tasks are not that obvious. In this post I have collected some examples of such non-tech tasks which a staff engineer might be taking part in. The benefits of such tasks would be more indirect. Also as a staff engineer, it is highly likely that you will have a much more larger network than some of the other leaders in your peer group, so some of that influence can be leveraged for such non-tech tasks. This collection is not a conclusive list, but rather is built based on my own experience and also some peers with who also had a similar role. This post is targetted towards individuals who are in a Staff Engineer role but also might be useful for Senior Engineers who are looking to understand the next level they can get promoted to. I do not consider any particular kind of company where such tasks can be applied. Hence, I would encourage the readers to pick the ones which makes sense to them. The main idea would be to bring awareness to certain kind of tasks. While I do give some examples and archetypes of tasks in this post, I do NOT talk about skills needed to conduct such tasks here. I also have left out some of the micro-tasks which can be non-tech like adhoc moderation, decision making skills, conflict resolution and I plan to write another post covering such topics.

1. The Guardian#

It is important to understand that being a staff engineer is a recognition of your skillsets as a good software engineer. This means in the past you have displayed strong skills as a software engineer and it is important for your employer to leverage that skill for training and development of other individuals. This means you can act like a guardian for all software engineers so that there is a good understanding and quality to be successful in this role. There are different areas where this could be tried out, like

  • Interviewing actively. This helps you speak directly to candidates and you help in ensuring within your interview round that the candidate lives up to the expectations for that particular role and level.
  • Promotion panels. Some of the larger companies have formalized promotion panels where experts assess the performance of an individual who would be put for promotion in an unbiased and fact based approach. These are great areas to lend your software engineering expertise.
  • Interviewing content. You can work actively within your area of expertise (depending on the size of your company, this could be a small hiring group, or the complete organization) and contribute to scaling the interviewing out by providing standardized content like a question bank; assessment techniques.

2. Weekly Operational Tasks#

Most of the Staff engineers look at some of the overarching technical operational areas within their team(s). These kind of tasks take up some of your capacity and at times might not be overly technical especially if you spend a lot of time in preparing the content and are moderating the events. While it would be a case-by-case manner in which you can think of scaling this out, but some common examples of such operational tasks are

  • Reviewing technical health. Reviewing the health of your systems with the team in a weekly format is quite useful. Some examples are you can dig deeper into any past incidents, erroneous behaviour of systems by going through your monitoring, SLO breaches.
  • Architecture reviews. Since as a staff engineer you would be putting on your architect hat quite often, you would be lending expertise by participating in common forums where such skills can be leveraged by team(s) more publicly. While the participation here is not a non-technical task but sometimes there are added overheads in formulating such forums and its ways of working.
  • Team ceremonies. This one is hard to keep track of as it is quite likely that as a staff engineer you would have multiple teams within your scope. Some common examples which fit into this category involve refinement sessions for new sprint; sprint reviews; standups. Most of your contributions would not be technical but rather around information gathering.

3. Networking#

Not a lot of individuals like the networking aspect which comes with a leadership role. Networking with people is heavily biased towards individuals who are extroverts and outgoing, not to mention males. Since the staff engineer role does not come with any power you would have to lead people with influence. Hence it is important to leverage and work on this particular skillset. As an introvert, I had a lot of struggles in the beginning accepting that this is important to be successful for my role as a new staff engineer. Here are some of my patterns which I tried and has helped me in my role:

  • First time networks. Networking in the early stages of my staff engineer was difficult as I would be intimidated by the seniority of some individuals. I would ask questions like “Will that individual have time for me?”, “What will I talk about?”. What helped me was a bit of a sponsorship to give me a nudge towards such individuals. I would have good early “sponsors” for my role who would support me and introduce me to some potential individuals. This helped break the ice and start having a normal conversation with the individual.
  • No-agenda check-ins. I picked this style from one of my mentors who would check-in with quite a few of their peers without any agenda on why. It would be mainly a social call and both of the individuals ended up talking about some of the tasks they are doing. The idea behind such kind of a check-in that you establish the equivalent of an IOU (yeah, does not sound quite nice on paper but is quite practical and I have seen it work!). Your network would prioritise some of your tasks when you need support from them.
  • Low frequency catchups. I picked this up from one of my leads. As the title suggests, you can have a low frequency catchup with some of your network to pick up some important updates within their area of scope and vice versa.
  • Working sessions. This one is interesting and can be applied with peers with whom you would be working regularly. Instead of a session to catchup, you can have a longer session where you can work together. This guarantees a common working time and you do not need to worry about finding a time in someone’s busy schedule adhoc. An example of a task of this session is, you might be working on a particular document and you wanted some early feedback on that. You can use your working session to get this detailed feedback where the individual would read and provide feedback.
  • Venting sessions. Does not sound too obvious but being a staff engineer slowly becomes a lonely place as you most likely will not be part of a team. You would need some individuals who can relate to what you are going through. You need to be yourself and not be judged on every single technical aspect of your job. It is hence important to socialize with some individuals who can understand this and you get to share some unfiltered information. I used actual psychotherapy for this but now I have some colleagues and ex-colleagues with whom I socialize in a very low frequency and I also extend a similar support to some of my peers.

4. Onboarding#

As a staff engineer, it is quite likely that you might be having a good overarching knowledge about the domain you are responsible for. Some examples of content would be systems knowledge, ways of working, product knowledge, team structures. You can make the life of newbies easier by providing regular high-level onboarding for them. Remember, as a staff engineer you operate by influence and not power. This also helps establish an early network for you with the new joiners.

5. Costs and Budget#

This one is a bit in-line with the staff engineer who acts like a “right hand” as described in “Staff Engineer by Will Larson”. There are times where you would extend the role of your lead by handling some of their tasks as a proxy. One example is budget planning. While it is very rare that you would be doing all of the budget planning for the organization but you can contribute to parts of it. I would recommend to start small. Cloud infrastructure costs is a good tangible area to start with where you can help predict what could be the future costs for your cost center’s area of scope. You can also regularly review infrastructure costs on a weekly/monthly cadence. Another example which is a bit complicated to achieve is, you can support providing information on how some of the staffing would look like in the future by filling in information on how the organization would grow. As an individual who has a good overview on the current technical state of the software, you would have a good understanding and point of view on how things can evolve in the future. I found the book “Team Topologies” as a good example to help forming some patterns on different kind of teams which is useful to help with your task.

6. Training and Development#

You can find some great opportunities spent on training and growing others. This is an excellent area to still be in touch with some of the topics you are passionate about. Some styles are:

  • One-on-one coaching: This is the mentorship you would do to grow and coach some of the individuals you are working with. I found out it is also a great forum to also gain knowledge especially if this is practised outside of your scope of team(s) and even your company. The Mentoring Club is a good platform to mentor individuals from outside of your company. I personally got to know quite a lot about other companies and their ways of working through some of my mentees.
  • Knowledge sharing sessions. A bit obvious but you can host some training and knowledge sharing sessions. Depending on the audience, you would have some prep-work so that the audience get a good return of investment. Don’t be afraid to have very basic sessions. I once knew a staff engineer who would provide training sessions to women in tech on how to code. They would feel very rewarded with the experience and notebooked themselves by falling in love with programming with every time they conducted the session.
  • Cohort based sessions. This one is a bit rare and have seen only a few formats of this. The idea is instead of a content there would be a group who would work and collaborate together in a one-off session dedicated to one particular topic. This one requires quite some difficult moderation skills and formulating enough guardrails to keep the group engaged and the discussions on track.

7. Communities#

I enjoyed working and helping form tech communities in my career. The experience is quite rewarding as you get to network with a lot of colleagues whom you might have not met otherwise. This becomes even more important as remote and hybrid work does not make meeting colleagues at work that obvious. When it comes to communities, consider them like the ecosystem of a continent. A continent can have different climates, like tundra, grasslands, tropical rainforests, deserts. Now a Polar bear does not need to survive in the deserts and can happily live along in the tundra. This is key for communities, as in any company there needs to be a variety of them so that most of the employees can find a safe climate where they feel comfortable and can socialize. The communities does not have to be super tech. You will be able to achieve some hidden benefits, as it helps attract talent (both via externally or through internal mobility). In the past I found space in book clubs, non-work related talks, hack communities, etc. You can find which one fits you in your company or create your own.

8. Mental Health Advocate#

This one is a bit personal and many might not be able to associate with it. I do not associate myself with being an overly confident individual and carry a lot of emotional baggage, imposter syndrome, and requiring constant affirmations on my task. Given the complicated nature of the tasks of a staff engineer it became more challenging to keep my sanity as there were quite a lot of context switches, conflicts with new stakeholders, sharp deadlines which would keep me on the edge. I had a great set of leads who acknowledged and helped me cope with my challenges. Additionally, I gained a lot from regular counselling/therapy and also later signed up and trained to be a Mental Health First Aider. The knowledge there helped me have a good grasp of situational awareness which assisted me to deal with individuals with whom I had to work with as it helped develop a lot of empathy. Remember, a software does not follow the laws of physics, chemistry or biology but is rather a set of rules cropping up from the figment of our imagination. This is art, and it is important to help protect the creators of this art! I leave it up to you on how you can be an advocate on this topic. The first step is awareness and in case this topic is new for you, I would recommend reading “The Fearless Organization: Creating Psychological Safety in the Workplace for Learning, Innovation, and Growth” and “Big Feelings: How to be Okay When Things are Not Okay”.

9. Inclusion Role Model#

Some of the aspects of the staff engineer role requires to have a lot of conflicts, spend time getting deeper into particular topics, gaining technical expertise to establish credibility and context switches. They all come with some level of stress and is biased towards individuals who are more confident. As a male who does not have any caregiver responsibilities, I had quite a lot of privilege. I was able to be quite successful in my early career as I had quite a few sponsors who would support me in my early journey. I climbed the growth ladder quite quickly because of this. Irrespective of your gender and which group you associate yourself with, you can be a role model for the others in the company.

  • Break knowledge islands. It is quite common to have employees who have gained a lot of knowledge in their tenure and might become knowledge islands. This does not benefit individuals who would be new and they would need to work around this bottleneck. You can figure out mechanisms to spread this knowledge and break such knowledge islands.
  • Women in tech. This one is a bit obvious and you should be a good ally for it. If this is new for you, then I would recommend reading “Invisible Women: Data Bias in a World Designed for Men” to bring awareness. I additionally found the book “Good Guys: How Men Can Be Better Allies for Women in the Workplace” quite useful which has great techniques for practicing allyship.
  • Not your toy. Some employees can become very attached to certain coding practices. This makes it quite difficult for other individuals to approach any changes as the creators of the code base would not be willing to change certain styles. As a Staff engineer, you are well placed to facilitate a good discussion and decision making here by moving away from emotional statements to find objective facts and tradeoffs.

10. Brand#

Lastly, establishing a certain credibility is important. A job title helps establish a bit of that credibility but it is not enough. You would still have to show your work. You would have to help build a brand for yourself and also for your employer as it would help attract smart individuals who would eventually want to work with you and for your employer.

I hope you have found some of the examples and archetypes useful and has brought some awareness to some tasks you have not thought about before. It is quite easy to get sucked in with day-to-day tasks and forget to contribute to such kind of overarching non-tech tasks. The reasoning behind some of the tasks should also help you prioritize some similar tasks which you had in your backlog and you might want to bring them up on your priority list. A big trap to avoid is to not fill your schedule completely with the tasks described here. Most of them are very useful and make you look good, but do not forget your primary role as a tech contributor and expert. Remember, you do not have to follow everything and each staff engineer would find some safe areas to practice and expand their skillsets beyond tech.

Originally published on Medium.