Skip to content

Common Pitfalls

If What Good Looks Like is the mirror, this page is the shadow. These are the patterns we most often see when a Staff Engineer is not yet operating at the level — or has drifted away from it. They’re described without judgment because most of them are understandable, and many of us have been in at least one of these modes at some point. The goal is recognition, not shame.

The Senior Engineer Who Got Promoted

This is the most common failure mode. You were an excellent Senior Engineer — you shipped reliably, wrote clean code, owned problems end-to-end. Then you got promoted, and you kept doing exactly the same thing. Your output is still strong, your technical skills are sharp, but your impact hasn’t changed shape. You’re still the person who builds things, not the person who makes building better for everyone around you.

The tell: your commit history looks the same as it did eighteen months ago. You’re not in the design reviews, the cross-functional working groups, or the architectural conversations where the important decisions get shaped. You’re comfortable, and the comfort is the problem.

The Ivory Tower

You’ve embraced the “strategic” part of the role so fully that you’ve lost touch with the ground. You write architecture documents that don’t reflect the actual constraints teams are working under. You make pronouncements about technical direction without staying close enough to the code to know whether your direction is realistic. Engineers have stopped pushing back on your designs — not because the designs are good, but because they’ve learned it’s easier to nod and then quietly work around you.

The tell: you can’t name the top three operational pain points your team dealt with last sprint. Your last meaningful code review was weeks ago.

The Context Hoarder

You sit in all the right meetings. You have organizational context that nobody else on your team has. And you keep it to yourself — not maliciously, but because translating context is hard and you’re busy. The result is that your team is constantly surprised by organizational decisions, doesn’t understand why priorities shifted, and can’t make good local decisions because they’re missing the bigger picture.

The tell: engineers on your team regularly say “I didn’t know that was happening” about things you’ve known for weeks.

The Critic Without a Path Forward

You’ve developed a sharp eye for what’s wrong — bad architecture, poor process, misaligned priorities. And you name these problems loudly and often. But you rarely propose a solution, build a coalition to fix it, or do the unglamorous work of actually driving change. You’ve become the person who points at fires but never picks up a hose.

The tell: people have started to tune you out in reviews and meetings, even when your observations are correct. Being right isn’t the same as being effective.

The Lone Wolf

You take on hard problems and solve them — alone. You don’t pair with other engineers, don’t bring problems to your local staff group early, and don’t use Architecture Office Hours. The work you produce is often good, but it doesn’t multiply. Nobody else learned from the problem, nobody reviewed the approach before you committed to it, and the team’s collective capability is unchanged.

The tell: you can’t point to a single engineer whose growth trajectory changed because of something you deliberately did in the past six months.

The Conflict Avoider

You see a principle violation in a PR, a design that’s heading in the wrong direction, or a team decision that’s going to create technical debt — and you say nothing. Not because you don’t notice, but because engaging feels uncomfortable, you don’t want to be “that person,” or you tell yourself it’s not worth the political cost. Over time, your silence becomes a signal that the standard isn’t real.

The tell: you review design docs and PRs regularly but rarely leave substantive feedback that challenges the approach. Your reviews are thorough on correctness but silent on direction.

The Space Filler

You’re in every meeting, on every Slack thread, and in every design review — but you’re not actually shaping outcomes. You’ve confused presence with participation and visibility with impact. Your calendar is full, but if someone asked you to name the three most important things you influenced this quarter, you’d struggle to answer.

The tell: you’re exhausted and busy, but when you look back at the quarter, you can’t identify a decision that went differently because you were in the room.

If you recognized yourself in one of these descriptions, that’s a feature, not a bug. The first step in changing a pattern is seeing it. Pick the one that fits most closely, and look at the corresponding section in Core Responsibilities or What Good Looks Like for the behavior you’re trying to build instead.
Further Reading
Several of these anti-patterns are described in the source material: Larson names the danger of continuing to do Senior-level work after a Staff promotion and the trap of “snacking” on low-leverage tasks (Staff Engineer, “Work on What Matters”). Reilly describes the ivory tower architect and the importance of staying technically grounded (The Staff Engineer’s Path, Chapter 1). Larson’s Learn to Never Be Wrong covers the shift from being right to being effective — the antidote to the Critic Without a Path Forward.