The Staff Engineer - A Staff Engineer's perspective

The software development world is quite diverse and when I started out as a developer I would have loved to have someone telling me what the real expectations are for professionals. Sometimes those are very different from what is written in a job description.

In this article series I already covered the Junior Software Engineer, the Professional Software Engineer as well as the Senior Software Engineer. In this article I want to end the series with the Staff Engineer. I will explain my point of view as a Staff Engineer of what is expected of people in this role and what you should do to be good!

What is expected of you

First of all, the Staff Engineer is a leadership position. You lead the team and by doing so you are a role model for everyone else (that might add some pressure ;-)). You are a hub of information for the team. This means that you soak in information, filter it and pass what is relevant on to the team. You ensure that everyone else in the team can focus on getting things done. In that sense, you are also a person who fosters cross-team collaboration.

Furthermore, you are the second pair of eyes for your manager. You try to keep the team healthy (e.g., help resolve blockers, jump in where help is needed, resolve conflicts locally first if possible). You help the team to move forward and to keep focus in discussions on making decisions. This aspect will also be important when your team needs to decide on what to work on next. Engineers tend to loose the big picture while being in the details all day. Having you with as a birds eye on the team is very helpful in that regard.

Finally, you drive the technical roadmap and by doing that the technical direction of the team (alone or with the help of others). You are accountable for the pace and quality of the output of the team.

All that is expected of a Staff Engineer - of course you should be an awesome software engineer as well. This gets harder over time cause you might be in a situation where you spend much more time on "ensuring" and "driving" than coding. That depends heavily on the team maturity.

What you should aim for to be good

Even if you are not a manager, I can advise you to have (not too frequent) 1on1s/coffee chats with your team members. In those you can ask them what challenges they see currently (team- and system-wise), get to know them, ask what motivates them / what they like to work on, ask what you can do differently, what they need support with, even how you can help them to grow and reach their development goals.

The focus of the other engineers is to go into a lot of details most of their time. You should make sure that they can do that. To be able to do that you should consider the following points:

• delegate as much as you can,
• your focus should be on:
  • having a good overview,
  • being an information hub,
  • having a good idea about the relevant bits that happen outside your team (those can influence the inside work),
  • giving the team direction,
  • being a tie breaker when the team is stuck during a decision making process, for example, by asking questions to make the team find a way back to make a decision, suggesting an investigation task prior to the work to get more information or taking the decision yourself when you have better knowledge or during times of high urgency,
  • reminding team members of the important things to work on,
  • in general, making sure the team has what it needs to work and focus on this work.

Also keep in mind, that from now on you cannot make it right for everyone anymore.

How you can learn

You will have less time coding yourself. Still there are other ways you can make sure to not loose too much connection to the code. You can try and ensure you know what is going on by doing more code reviews. I learned the hard way that I should only work on smaller tasks that will not block my team in the current delivery (which might have a deadline attached). You can help others out and pair program or be the rubber duck if someone is stuck. Other than that there is a whole lot to learn about conflict management, team forming and building, the different characters in your team and how to support them.

Do you have other input about what to look out for when you start a career in Software Engineering? Let me know! I would be glad to listen to it and learn from your experiences. Let's get in touch via Twitter, LinkedIn or good old Email.

Post image taken by Becky Matsubara published under CC BY 2.0.