When Staff Engineer is an anti-pattern
When Staff Engineer is an anti-pattern
Reflections on a failed technical leadership interview
Years ago, I & Gabbon were interviewing a candidate for an EM (engineering management) position. By that point I had carried out dozens of technical leadership interviews for Staff Engineer and EM positions but this one was noteworthy. It felt like we took a guy off the streets!
The candidate was confidently unprepared! Honestly, the thought occurred to me that the TA (talent acquisition) was trolling us! 😄
The interview was scheduled for an hour. After the first couple of questions, it was evident that we were not going anywhere.
On paper, the candidate had a MSc degree in computer science (earned 2 decades ago) and had spent a substantial chunk of their career as a software team leader, scrum master, and “engineering manager”.
We followed a script to keep the candidate's experience consistent. The interview specifically started stating that we are interested to hear about the candidate’s practical experience with technical leadership, not how it should be done theoretically.
For almost all technical leadership questions, the candidate’s answer was a variation of delegating to the tech lead, “architect”, or staff engineer.
Bottom line, the candidate was a people manager or team admin, not an engineer who leads other engineers.
As part of a larger organizational shift, we were very strict about hiring EMs who are technical, hence this technical leadership interview.
We didn’t have a dedicated Staff Engineer for each team. Most of the value of Staff Engineering comes from operating across teams and filling the gaps in between as I have elaborated in a recent article:
Solely relying on Staff Engineer for technical matters is an EM anti-pattern as we’ll get to. It’s an example of breaking one role into multiple titles (🔴title of an upcoming article).
I couldn’t just interrupt the interview abruptly —I was representing my employer after all and had every intention to make it a positive experience regardless of the outcome.
So, I did what I had never done before:
I really appreciate giving us your time. We follow a script with a set of questions to keep the experience consistent for all candidates. So, I’ll go through a few more questions, and you can ask us to skip them if you don’t have person experience in that area. —paraphrasing what I said
And so, we spent the next 10 minutes with “skip”, “skip”, and inadequate answers.
At that point, it was obvious that we could not continue this role-playing game. 20 minutes in, we went directly to the part where the candidate asks their questions:
I don’t have any questions as it’s obvious that I’m not the type of EM you are looking for, but I have an observation to share. You guys reached out to another EM-colleague of mine to recruit her, but as soon as she heard that the recruitment process has a technical leadership interview, she declined. I was the brave one and out of curiosity decided to go through the process.
Why is it so important for you to hire technical EMs?
My response on behalf of the company was of course more brief and mellow but I took note of sharing it publicly because it’s an important issue.
Non-technical EM
Not all EMs are created equal. Every person has a different background, interest, and professional life trajectory which exposes them to different environments and shapes their growth and belief system.
In his seminal article, Pat Kua identifies 5 archetypes for engineering managers:
Tech Lead EM excels at technical leadership guiding the team in making sound technical decisions, mentoring engineers, and ensuring the quality of code and architecture.
Team Lead EM focuses on team dynamics and collaboration fostering a healthy team culture, managing conflicts, and facilitating effective communication.
Delivery EM is all about execution and delivery, ensuring projects are completed on time, managing dependencies, and optimizing processes.
Product EM bridges the gap between engineering and product, collaborating with PMs, defining roadmaps, and aligning technical efforts with business goals.
Lead of Leads EM oversees multiple teams and EMs, setting the vision, aligning teams, and driving organizational change.
Tip: Regarding archetypes of other roles, I’ve written about SRE and Will Larsson about Staff Engineer.
Personally, I have had my share of non-technical managers and the frustration as an engineer:
They don’t understand engineers’ world. They act as a shepherd where no shepherd is needed! They are babysitters where there are no babies. Most engineers are clever and logical. They prefer an engineering leader who can meet them where they are and understand their technical challenges.
They default to using their “team building” and “conflict resolution” tools even when the disagreement between engineers is purely logical and can be resolved for example through creating a POC (proof of concept), writing down an RFC (request for comment), or implementing ways to gather data.
They have no way of understanding code first-hand and solely rely on their favorite developer (who is usually promoted to tech lead or unofficially acts like one). This alienates the rest of the team.
When an incident happens, they get in the way instead of meaningfully contributing to identification of the root cause or implementing a resolution.
When they get access to “the room” (where the decisions are made), they cannot do a good job defending their team or acting as their ambassador. As a result, unrealistic expectations will be set for the team, or their great work will go unnoticed. That’s because they heavily rely on someone else to act as a translator between what’s being done and why it is impactful. They cannot acquire this knowledge on their own.
When it’s time for promotion, you cannot count on them due to lack of understanding your contribution. A Life Engineered, did a video about this being one blocker for promotion to staff.
When communicating technical topics, you have to dumb down the issue often to a level that it loses context (admittedly communicating technical topics to non-technical people is a useful skill, but you can’t expect every team member to have that skill just to support an incompetent person in the position of power).
When it comes to recruiting engineers, a non-technical hiring manager has a limited toolset to assess the candidate’s hard skills. They are more likely to make a decision based on soft skills (AKA chemistry). This can lead to discrimination (e.g. against neurodivergent people) and homogeneity (e.g. hiring a team fit instead of team add).
Does this type of EM do anything useful? Of course! But in my experience the admin work and people management activities don’t qualify as a full-time jobs for the teams I have been part of.
I confidently say that my best managers were all first engineers, then leaders. Not the other way around.
Action points
My interview peer was a seasoned Engineering Manager. He asked if we could talk about this interview after we’ve submitted our candidate assessments.
When we met, he mentioned that he had met similar candidates in the past and whether there is a way to prevent wasting the applicants’ time and giving them false hope by getting them in the interview process?
Our action point was to:
Add technical literacy and technical leadership as requirements in the EM JD (job ad)
Add a few examples of the things we’ll be asking about in the technical leadership interview (e.g. tech strategy, hands-on experience, etc.)
Continue being explicit on the technical profile of the EM positions
Continue being transparent about having the tech leadership interview in the process
In this particular case, I checked with TA (talent acquisition), and it turns out the candidate’s university degree in computer science was assumed to qualify going through the technical leadership interview process.
Without sidetracking this post to be about degrees, I just want to highlight that due to fast change in technology, a degree (or certificate) quickly gets out of date. It requires deliberated effort and discipline to stay relevant and recruitable.
How technical should the EM be?
It depends. I’d turn that question to be about what the team needs. Here are some quick tests:
Do you understand what the engineers are doing on a daily basis? It’s not about micro-managing, but rather having a solid understanding that is not too high level and abstract.
If the engineers get stuck in technical tasks, how likely is it for them to come to you for ideation? Do they respect your experience as an engineer or are you considered out of date?
When there’s a technical disagreement, how early do you learn about it? Do you primarily rely on one or more favorite team members to chew technical matters and feed you or can you digest this firsthand from browsing the repo?
And when conflict comes your way, do you quickly understand the trade-offs to be made?
Where do you spend most of your time? Admin work or engineering? If it’s the former, you need an administrative assistant to help. Don’t use Staff Engineer to act as your engineering leadership assistant. That’s the core of your job.
Do you fill most of your hours with admin work (planning team activities, hiring, time report, firefighting, etc.) and spend the rest in pointless meetings that have nothing to do with empowering your team? Or do you spend some time coding or at least browsing the code? Can you draw the architecture diagram for everything your team owns? Can you explain how the testing and CI/CD are set up for your team?
Do you sponsor your team members, or coach? Mentors are generally detached from the team the engineer is working in. Between coaching and sponsorship, the latter has a higher value because sponsors open doors and are more invested in growing the engineer.
When meeting with higher level leaders, how likely is it for you to fight for your team against unrealistic technical expectations? A small technical “feature” can seriously complicate the code and add invisible costs. Can you assess those situations without having to drag the team into every meeting?
If the EM position vanishes from the planet tomorrow, would you be able to work as a developer? Or would you be jobless?
As a manager, you have more power over engineers: vacations, parental leave, performance evaluation, promotion, salary raise, etc. You may notice that your jokes are funnier, your errors are more forgivable, your asks are more respected…
That’s due to the power asymmetry that comes with your position. With great power comes great responsibility. Engineers are less likely to call out your lack of technical competence, but your power will not be used efficiently without it.
Why is Staff an Anti-Pattern?
A while back an engineering manager reached out for advice on hiring Staff Engineers. His org didn’t have any Staff Engineer and as someone who carries the Senior version of the title and actively writes about it, he thought it’d be a good idea to ping me on the matter.
After hearing about the problem, he was trying to solve and assessing his level of technical literacy, I advised against it. ❌
It was yet another case of an incompetent person being promoted to a position out of their league and trying to hire someone to cover their lack of technical competence.
It is an EM anti-pattern.
It’s the sign of a broken ownership where knowledge, mandate and responsibility are in different parties.
With all due respect for the team management skills and admin work, technical competence is part of the requirement for engineering management.
Without having a good grasp on the technical aspect, the engineering manager is limited by the technical perception of the Staff Engineers.
There’s nothing wrong with that —Staff Engineers are supposed to be more technical— but Staffs are primarily concerned with technology and don’t have the formal responsibility over people or product.
Engineering managers often find themselves making a trade-off decision considering not only technology but also product, personnel, budget, timelines, etc.
You may think that a healthy separation of responsible and accountable is at play. But this is exactly one of those cases where separation is counterproductive.
Even worse is when you have only one Staff Engineer. If you are going to hire Staff Engineers for this purpose, you need at least a couple of them to balance each other’s views. That’s an expensive solution, but far better than having one Staff Engineer gaining too much power.
Staff Engineers need to be capable of communicating complex technical concepts to non-technical audiences. But that shouldn’t be necessary when communicating with people who lead engineers. One can only dumb down a complex technical topic so much before it loses context, relevance, and nuances that are needed to make informed decisions.
Relying heavily on Staff Engineers to call all the shots on technical decisions gives them too much power while simultaneously making their cutting edge blunt! The time the Staff Engineer has to attend engineering manager meetings or read through decision docs is the time not invested in sharpening their technical skills.
How do I know this? Because I had seen it firsthand before!
A very competent senior manager got replaced with an inexperienced one with a completely different background. After a few months of struggle, the new manager hire-promoted a Staff Engineer to act as their missing technical arm.
Poor IC had to go to all meetings as the engineering manager he was supposed to support. But before you feel sorry for the Staff Engineer, I should mention that he took full advantage of his surrogate powers.
That Staff Engineer basically acted as a techno-king demanding other engineers to do stuff that sounded great on paper from the technical perspective but didn’t make too much sense when the non-technical aspects (e.g. budget, personnel, product, timelines) were added to the picture. The end result was that even a technically competent person got in the way of the engineers doing their job!
How can engineer leaders stay technical?
Update: this section was added based on the feedback from a friend of mine who is a CTO at a mid-size company (500-1000 employees).
I believe staying technical has been key to my success as a CTO and also past roles that led to this position. I feel that I have a big role to play in setting engineering culture.
It lets me:
Grasp what is the level quality
Champion a strategy to improve quality
Solve problems without needing a tech translator
Be the voice of my team in C-suit room
Understand the nuances of the decisions I take
Connect to my people—uniting us in our craft
Executives love to simplify everything into bullets. But often the bullets hide the context and complexity.
Nuances are key. Devil is in detail. As a CTO you cannot affort to abstract yourself from the technical aspects.
Without technical depth:
My understanding will be reduced to bullet points! That is a nightmare!
lose the ability to drive practical aspects of innovation.
How do I keep up with technology?
I learn directly from my team
I remain relentlessly curious, and I'm constantly reading
I am a generalist these days and know enough about enough, to know that I should not get into details
I learn by reading RFCs, ADRs, etc.
I learn by participating in architecture reviews and forums
I sometimes discuss technical challenges in 1:1s and skip-levels (when an executive talks face to face with people who aren’t in their immediate line of report)
I follow conversations on Slack
I occasionally drop by engineers’ table and have a casual conversation to understand their challenges and world while updating them
etc.
To what extent?
I know enough to about our technology to make or support decisions
To connect technical work to business objectives
Understand my team's challenges and strengths first hand without them having to dumb it down
My friend
who has a CTO background also wrote about the “Engineer-ication”:During a few days you block your calendar and agenda rejecting meeting invites and delegating certain tasks to other people, as if you were to go on vacations.
You join one of your engineering team as Individual Contributor, and work on one or more software engineering tasks. —
, Why I did my first Engineer-ication, and why I think you should do it too
He also has a follow up post for a perfect engineer-ication. Make sure to check out his work.
Sergio formulated his thoughts about this topic at Should Engineering Managers Code?
You should prioritize the well-functioning of your team over any coding work.
You should be able to drop any ongoing coding work at the first sign of stress on the system.
Your team should not make assumptions on your contributions, and […] capacity
Don't [take] tasks or features that are in the critical path for delivery.
He then suggests not to spend time on coding if your goal is to go up the career ladder. Here’s where we may disagree but it goes to show that this is a hot topic.
Another idea is to have hobby projects. Some of the engineering leaders I respect a lot have their own hobby projects to keep their knowledge in the loop. It doesn’t matter if it’s tinkering with Arduino or a Raspberry Pi cluster, as long as it allows you to live the life of an engineer, it’s good.
There’s a risk of getting too close to code due to the power asymmetry between leaders and engineers.
Another engineering leader called that our this way:
How does a developer feel when the leaders send in a PR? How about comments on a PR review? What if the feedback is actually not a good solution? Does the developer feel forced to implement the feedback due to the manager telling him/her?
What about a technical EM sending in a PR, will the developer feel forced to approve it to not get into "trouble" on performance ratings or salary reviews?
Those are two aspects i have seen that can create a worse technical solution than not having a technical EM. However, i also see your points as well.
I’ve had my share of “micro-managers” who hurt the team culture with good intentions. Getting too close to code requires a level of trust, openness, and humility that takes time to establish. So please don’t jump on code after reading this post, but rather verify that the trust is there before doing so.
A word with engineering leads who have Staff Engineer
Staff Engineer is a leadership position, but the emphasis is on the “engineer” part. They are primarily the leaders of the tech but:
Unlike engineering leaders, Staffs don’t have mandate over people
Unlike product leaders, Staffs don’t have mandate over the product
Yet their entire impact depends on both people and product. Tech doesn’t talk or listen! Staff Engineers ought to work closely with engineering and product leadership to deliver an impact larger than 1 person.
In a previous article I pointed where the word “staff” comes from:
The term “staff” is used in the military to promote great soldiers as role models without giving them extra command and control responsibilities.
Staff officers assist the commanders in planning, analysis, and information gathering. The commanders have authority and accountability over their subordinates. Staff officers don’t.
The proper way to use Staff Engineers is to improve your:
Execution bandwidth though delegation of technical initiatives
Cognitive bandwidth through discussing technical nuances, because Staff Engineers are supposed to be on top of the latest technical development both internally and externally
They do have other duties as well. For example, bridging the gap between organizational silos by operating horizontally across the org and breaking free from the org chart.
Whatever you do, never ever replace yourself with a Staff Engineer. Staff Engineers, no matter how competent, are primarily concerned with technology. Putting them in a position where they have an oversized say in people/product matters is risky.
Let me give an example. A few years ago, we hired a Staff Engineer from a reputable company. He was sharp, smart, and a well-rounded technical leader. Unfortunately, he was put in a people management position: in charge of tens of teams. He didn’t have any formal experience in EM, even at the team level.
He had a handful of Staff Engineers reporting to him. The Staff Engineers were frustrated by the poor state of DX (developer experience). So, this cluster lead (formerly Staff Engineer) decided to do something about it. He managed to convince the leadership to create a dedicated DX department which he would lead. That means the original cluster was left headless.
He spent the next few months talking to people and developing a tech strategy only to throw the towel and leave the company. Before leaving the door, he left a long wish list that he gathered from across the org. Reading through that list, they were all great ideas that would improve our lives as engineers. But it was evident that it required many hands to execute and that was a challenge with someone who has recently been promoted to such a high level of engineering leadership —despite being a super technical person.
Another example is from my own career. Many years ago, I got a job as a TPM (technical product manager). I had read multiple books about product management prior to that job and even launched my mini-products. Unfortunately, the job proved harder than I was prepared for. More specifically, I’m a techie and loved to dabble in the engineering aspects way more than the business aspects. Ironically, that product background gives me extra lens operating as Staff Engineer, but at the time, it hurt my ability to lead the product team to a better place. My takeaway from that exercise is to have immense respect for PMs —it’s a hard job. But I also learned something about myself: for now, I want to continue operating as IC (individual contributor) and be responsible for tech.
Both stories are meant to clarify one point: Staff Engineers are primarily engineers, so don’t expect too much when it comes to product or people management despite the fact that their impact depends on both.
Does this mean that Staff’s mandate over tech relieves the EM from that responsibility? Absolutely not. The main value of Staff comes from operating across teams:
As an engineering leader you should not need a translator to understand engineers. Don’t [ab]use Staff Engineers for that purpose. Going back to the military origin of the word “staff”, the accountability of decision is with the commander not the Staff.
The Staff Engineer represents the engineers. They are not substitutes for engineering leaders.
One could argue that technical literacy is only necessary for the lowest levels of management (e.g. the EM of a team). The argument is that the higher-level leaders (e.g. Senior EM, Director, Vice President, etc.) have too much on their plate and it’s ok to rely on Staff Engineers to be their eyes and translators.
Absolutely the opposite: The higher-level leaders are responsible for even more important decisions where the stakes are even higher. It is true that they are a few layers further away from the code, but that's exactly what makes those positions hard to get right. That’s the reason many of these higher-level leaders are incompetent, having no clue about what they're talking about. They are confidently wrong. That’s why you get cartoons like this circulating around:
Unfortunately, human beings are hard-wired to confuse confidence with competence! It takes deliberate effort and critical thinking to see the bullsh*t.
If people are promoted through a meritocratic process, the higher-level leaders are equally technical (if not more). It is a challenge of course to be both very technical and at the same time go to all those meetings about strategy, reorg, product planning, etc.
But that's exactly why it is so hard to hire competent engineering leaders and it takes a lot of time and energy to grow into those roles.
Just because someone was an EM for a few years doesn't mean that they should become a Senior EM and so on and so forth go up all the way to the CTO level just because they have the years.
A word with Staff Engineers
I once heard a Staff Engineer proudly saying:
As a Staff Engineer, part of my job is to help engineering leaders with technical questions they are too afraid to ask others 😎
If that’s how you see it, you have completely misunderstood the dynamics of that relationship!
Great engineering leaders often gather a wide range of insights from across the org to make informed decisions.
You should feel honored that they're consulting you. But make no mistake: your mastery in one area doesn't mean you are overall superior to the leader.
Besides, assuming that asking question is a sign of ignorance or weakness is such a rookie mistake. That engineering lead is probably juggling tons of responsibilities (some of which you know nothing about).
The moment you think you're better than someone else, a door will shut. You stop learning from that person. Everyone has something to share because we all have different life paths.
So instead of arrogance, just focus on giving them the colors to paint a picture —their picture. If you play your cards right, maybe you can learn a thing or two in return.
Conclusion
What is your experience of non-technical engineering leaders? What do you think about the combo setup where the Staff Engineer is covering the lack of engineering skills for an engineering leader?
My monetization strategy is to give away most of content for free. However, these posts take anywhere from a few hours to days to draft, edit, illustrate, and publish. I pull these hours from my private time and weekends. You can support me by sparing a few bucks for a paid subscription. Right now, you can get 20% off via this link. If you don’t want to spend money, sharing it with a wider audience also helps. Thanks in advance.
Thanks for this great article Alex, and thanks for the mentions.
I don't think we necessarily disagree on the topic of coding. Staying technical involves a lot more than just coding. An EM should have a solid technical background - and I mean it when I say solid - but should also be able to give up their attachment to the code and move on to other aspects: architecture, planning, etc.
And as you also mention, if prefer the approach of occasional Engineer-ications as they allow the Manager to fully focus on that specific task for a week, get a real understanding of what is going on with the team and tooling, and then take initiative out of those learnings. I see this as a much more deliberate, disciplined, and effective approach than just picking some random tasks every now and then just because "you can".
Ultimately, this is a hot topic, and the pendulum keeps swinging back and forth when it comes to the general sentiment in the industry. Definitely a subject to follow and be open-minded about
Good reflections. The Staff figure is the one representing engineers in conversations of a bigger scope. Not someone to substitute the EM/PM. Not someone to dictate, but to enable