How Staff+ Engineers Frustrate Their Managers
Managing Staff/Principal engineers, or those aspiring to be so, is genuinely a joy. They autonomously solve problems, want to be given opportunities rather than instructions, up-level everyone on your team and challenge you in all sorts of interesting ways.
It can also be frustrating as get out. Given there has been lots written about what it is to be a Staff engineer, I thought a different lens would be to talk about some of the failure modes from the manager’s perspective.
Small note: Staff and Principal are semi-overloaded terms depending on the company or organisation, so I use Staff throughout for consistency. Also, if you have ever worked with me and think I’m calling you out, know that a) I’ve observed each of these behaviours in multiple people including myself, b) we would have already had a talk about it if I was concerned, and c) I list these because they are addressable, not just to have a gripe.
Not Being Accountable For Outcomes
I often refer to Staff as the “no excuses” level.
More junior engineers will usually think about success in terms of deliverables. They might care about business outcomes, they might have input into direction and they might help course-correct — but ultimately it’s probably delivery they’re on the hook for. If it turns out the thing they built doesn’t meet customer needs, or if things come up outside of their control — well, that happens.
If a Staff engineer delivers something which turns out not to meet customer needs or improve KPIs as expected, they’re accountable. I’d expect them to have made efforts to validate hypotheses, to course-correct where possible, and to be on top of understanding why and proposing a path forward. Saying that things were delivered to spec and washing your hands of it is not acceptable.
If a Staff engineer is working on the backend for a project with another team working on the frontend, and the frontend team can’t deliver on schedule, that’s the Staff engineer’s problem too — they should be leaned in to help, or escalating if it’s about prioritisation, or engaging the right manager if it’s underperformance. Saying that you did your bit and it’s the frontend team’s fault is not acceptable.
If a Staff engineer is working on something in tandem with another business function — marketing, commercial, business development, or whoever — they should put the work in to understand that function and its ways of working. They’re accountable for everyone succeeding together. Saying that’s not your job is not acceptable.
If a Staff engineer is working in an area where there are frequent outages or availability issues, it’s on them to make sure someone (possibly themself) is looking for the root causes and figuring out how to fix them— including if that involves persuading their Product Manager to dedicate time to it, the team to care about quality and the engineering manager to hold them accountable. Saying it’s not your problem or throwing others under the bus is not acceptable.
Some will phrase this as “don’t come to me with problems, come with solutions”, which I think is a touch too dogmatic — if there’s a problem I still want to know about it even if you don’t have an answer, and sometimes others’ input will be necessary. It’s on a Staff engineer to figure out whose help you need and ask for it though — ignoring problems isn’t OK. No excuses.
Ignoring Power Dynamics
Staff engineers usually got there because they’re smart, driven, have a track record of achievement and have built up deep levels of expertise. They’ve learned to take mistakes, failures and feedback in stride — and they’ve beaten their head against enough different types of problems to not be that worried about having to figure out something new. Unfortunately, they sometimes forget that others aren’t yet where they are.
For a junior engineer working with them, this can be overwhelming. This person who has an impressive job title and all that goes along with it is probably pretty intimidating. If they try to treat you like a direct peer from day 1 — without first establishing a rapport, what they’re expecting of you and how their role works — you’re probably going to be terrified. They probably think they’re empowering you while having quite the opposite effect.
It’s a hard topic to hear feedback on, in my experience. The first time a colleague and friend told me I was intimidating until they got to know me, I was gutted — I self-identify as a people person and want to be friendly, approachable and helpful. It hurt to be told people were afraid of my job title, my over-projecting confidence and my appearing to be always too busy for people (I’m deeply disorganised and default to reactive behaviours). Worse, the power dynamic makes it hard to give that feedback in the first place, and if you get defensive hearing it then people will back off very quickly. It’s a nasty self-reinforcing cycle that requires conscious effort to break.
Upwards can be almost as bad. Combine the disregard for the hierarchy with a lack of understanding of what value senior leadership actually bring and you create the risk of blowup. It only takes one senior leader who does put stock in the hierarchy and their position in it (even if only implicitly) to create a serious problem. I’m not advocating for becoming ‘political’, whatever that means — just put some work in to get to know people before you go in guns blazing, and pick your battles.
I love working with people who don’t hold hierarchical power in high regard. Dismantling power dynamics helps empower people, ensure we work on things that matter and prevents us from standing on ceremony — plus I find such people to be my best source of personal feedback. It is not free though — you can’t just pretend there’s no imbalance and expect everything to be fine. You have to put the work in.
Not Being The Adult
One day, a Staff engineer and a junior engineer disagree over a technical choice the Staff eng made. The junior engineer is wrong on the facts but belligerent and starts an argument at the team standup. The Staff engineer fights their corner; the rest of the team find the whole thing awkward and want to get out of standup as soon as possible.
The Staff engineer will say it’s not them who has the problem — that the junior engineer was wrong on the facts, is known to be a hard person to work with and was the one that started the fight anyway.
It’s still the Staff’s fault. They are meant to be the adult in this situation, and “but I’m right” or “but they started it” are not good examples of that.
As a Staff engineer, your job is about people. You’re responsible for role-modelling good behaviour, even when those around you are not. You’re responsible for ensuring healthy team dynamics, including healthy conflict. You’re responsible for supporting everyone on the team, even if they aggravate you (and everyone else for that matter). You’re responsible for dealing with difficult people and friction, even if that means defusing the immediate situation and feeding back to their manager later.
I use an argument as its most illustrative, but this also extends to lack of trust, poor communication, different learning styles or ways of working causing friction, or anything else that gets in the way of being able to work together. It’s part of the Staff engineer’s job to deal with these things, not to make them worse.
Lacking Situational Awareness
Say you have an engineer who’s known for their directness, but has found a way to be direct while still bringing others on their team along with them. The team know this person, they understand them, and they see the value brought by their blunt honesty— giving people the facts, cutting through the noise and getting to decisions faster. The people on their team probably sing their praises in feedback, and their peers in other parts of the organisation find them engaging and informative. As a manager you’re thrilled.
Then you start to get to hear about how they’re causing problems in other parts of the business. They asked a blunt question at a company Town Hall event in a way that came across as accusatory. In a design review meeting they said that another team’s project, which that team had poured their hearts and souls into, just wasn’t good enough to integrate into our stack. They shot down someone’s idea in a large meeting in front of lots of important people. They seem to be in the middle of every single contentious project decision, hard prioritisation call and technical tradeoff.
Now as a manager you have a big problem. You want the feedback addressed, but you don’t want to curtail the honesty because it’s so valuable and you’ll make your Staff engineer miserable. You don’t want them to stop challenging things in order to hold the bar high and you certainly don’t want to penalise them for being the one to lean in on the difficult stuff. You also have to figure out whether the message delivery was fine and the feedback you’re getting is actually shooting the messenger. You find yourself wondering how you can feed back “it’s not what you said, it’s how you said it” without sounding like a cliché.
This is how I came to write Message Crafting for Software Engineers. The thing you want your Staff engineers to do is to bring a bit more intentionality to their directness — to consider their audience, their venue, and how to best lay out what they have to say. And then to say it, and know that you have their back.
Not Being An Enabler
A Staff engineer should be a force multiplier; the kind of impact they’re on the hook for is rarely possible as a solo effort. There are many different ways to do this (see Will Larson’s archetypes), but importantly they don’t necessitate stepping away from technical contributions (we’ll talk more about that later on).
The Staff engineer who got there through technical brilliance will be tempted to keep indexed on building cool stuff. This could be for the joy of building and learning new things; it can also be because the feedback loop you get with coding is so rapid when compared to coaching people and teams, which is good for your sense of accomplishment and value.
None of that is a problem in and of itself, but it becomes so where that tendency starts to take away opportunity and autonomy from others. In the worst cases this manifests as the Staff hogging all the cool projects for themselves; even where it’s not that blatant, though, you can still hear things like “it took them two weeks and it would have taken me an hour” or “this is important and I don’t trust anyone else to do it properly”.
The key insight you need your Staff engineers to have is that a healthy, autonomous, growth-minded team is as much their required outcome as business objectives — and that investing in creating that will be rewarded. In the case where others’ delivery is slower, why is that and what can they do to help? In the case where there’s low trust, why aren’t there safety nets (testing, monitoring, metrics, and so on) and who’s accountable for upskilling people? Staff engineers should see those things as their responsibility to address, not work around.
It’s then on you as their manager to ensure you follow through on rewarding the right behaviours. Say a Staff engineer spends their time coaching and supporting a team, or doing a bunch of unglamorous tech debt pay-down, or other things that will help the team succeed — if that effort is met with a poor rating because they haven’t built something cool recently, you should expect them to respond either by hoarding the cool stuff next time or by quitting.
Getting Too Far From The Coalface
The flip-side of the Staff engineer who hoards all the interesting technical work is the Staff engineer who isn’t ever hands-on. There can be very many demands on a Staff engineer’s time which can cause this, including being asked to drive technical strategy or architecture across multiple teams, process governance, stakeholder management, external commitments like conferences, interviewing, and more. Some can also prefer working on more high-level direction setting, especially if they have a directive style of leadership.
The problem comes when this disconnect decreases understanding of the challenges the rest of the engineers are feeling day-to-day. This can cause bad planning, for instance where the levels of toil for a system are not taken into account when thinking about capacity. It can result in missed details when making sweeping changes — an example would be if a new platform technology they were pushing worked for everyone but could not support a couple of niche but important cases, and they tried to just push it through anyway. It can drive friction between engineering and product, where a PM and a Staff engineer have different ideas about what can and should be delivered.
Most worryingly, it can destroy empathy in both directions; the Staff engineer wondering why an engineering team hasn’t done what they told the team to do, and the engineers resenting the Staff engineer’s top-down pronouncements, lack of context and perceived unwillingness to pitch in and help.
It’s a hard balancing act — being technically involved without being overbearing or neglecting non-technical responsibilities — but it’s one that the Staff engineer must consciously manage to be successful.
Not Communicating Their Own Wants and Needs
If you’ve read this far, you probably understand that Staff engineers are on the hook for a lot. It’s a tough job. Staff engineers are also human beings, with their own ways of working, career or personal aspirations, and emotional reactions to stress or uncertainty.
One unhealthy response to finding yourself in a leadership position is to assume that you must fully flex to those you are working with even where that stresses you out; another is where you believe your own way of working is The One True Way(TM) and you try to impose it on people.
The correct way to deal with this is for both sides to communicate their preferences so you can figure out what will work together. As a Staff engineer, if you come to me and say “working with this person is really stressful, they always do <X> which I don’t like” — my first question is “have you asked them to do something different and explained why?”. If you don’t have an answer to that, you may end up feeling a bit silly.