Your Staff Engineer is a partner, not a senior report

Your Staff Engineer isn't your most senior individual contributor. A seniority label, nothing more. It doesn't describe what the job actually is.

A Staff Engineer leads technical decisions across a boundary bigger than any one person's code, mentors people who aren't on their reporting line because nobody told them to, and notices a systemic problem three teams are quietly paying for and fixes the problem instead of the nearest symptom. "Very good coder, longer tenure" doesn't cover any of that. It's a different function, and if you manage one like an experienced junior, you're wasting the best technical judgment on your team by making it wait for permission.

Two jobs, one team

Engineering manager and tech lead is a real split, and this partnership is the fullest version of it. You own people, team health, clear priorities, and clearing whatever sits between the team and delivery. They own technical direction, quality, the system's health, and the team's technical judgment as it grows.

Neither of you owns only the work or only the people, honestly. You both care about both. What's different is where your expertise actually sits, and where the buck stops when something specific breaks.

A design decision that turns out wrong eighteen months from now is theirs to answer for. Someone on the team struggling and nobody noticing is yours.

Don't let your title win the argument

Here's the part that's easy to say and hard to actually live by: your title gives you zero extra votes on a technical question. None.

Being the manager means you decide who gets hired, what the priorities are, and how someone's year gets scored. It doesn't mean you get an opinion that outweighs theirs on whether the caching layer should be event-driven. Settle a technical disagreement by being the one who signs the review, and you've told your Staff Engineer their judgment is decorative. They'll start bringing you decisions instead of decisions already made, because there's no cost to you overruling either way.

Healthy disagreement resolves like every other reversible call does: fast, with one accountable person, and for anything inside their remit that person is them, not you. Save your veto for the actual one-way doors, and even there, argue the case instead of pulling rank.

The other half of this deal is real, not a courtesy you're extending. A Staff Engineer who wants that authority has to explain the decision to someone who wasn't in the room, and own it when it's wrong. This reads a lot cleaner on the page than it feels the first few times. Working out how disagreement actually gets handled, and how a decision gets communicated to the rest of the team once it's made, usually takes one visible miss before you both get it right.

The right kind of hard

For a while I gave my strongest Staff Engineer the hardest problem in the building, every time, which mostly meant whatever project was already on fire.

Felt like respect. Was actually a narrow use of somebody with a much wider job. Rescuing troubled projects teaches a Staff Engineer to be a very good firefighter, and it teaches everyone else that competence gets you assigned to disasters. Neither of those is the point of the role.

The right challenge is ownership of a problem that needs depth, judgment, and influence past the edge of their own team, not just difficulty. Help them build a technical vision tied to what the business and the customer actually need, not an architecture diagram nobody outside engineering can read. Protect the long-horizon work (the kind that pays off in a year, not a sprint) from getting quietly bumped every planning cycle, and in exchange hold them to actually turning that vision into progress people can see.

Do the job well and it makes the whole team more effective, not just the person doing it. If the only evidence of their impact is the tickets they personally closed, you're still measuring them like a senior IC.

Multiply, don't gatekeep

The failure on the other side of firefighting is quieter, and for a while it looks like success. Everything technical routes through them because it's fast and it's right.

Push against that on purpose. Encourage them to mentor and sponsor, not just review. Put them in front of leaders and cross-functional partners, and coach them to say the technical thing in plain language, since that's a learned skill most engineers never get taught. Give them real chances to present and help steer a conversation bigger than their own team's roadmap.

A strong Staff Engineer's real output is more people around them who can make a good call without asking first. Two years in, if decisions still bottleneck on them the same way they did on day one, that's not a compliment to their standards. It means nobody built the muscle in anyone else.

Letting go of the keyboard

Staying hands on with the actual tools is right, and none of this contradicts that. It just has a boundary, and the boundary is critical-path production work.

Build the prototype. Ship the learning exercise. Take the noncritical thing nobody's blocked on. That keeps your judgment calibrated, and it should. What you don't do is become the person delivery quietly depends on, because a manager sitting on the critical path has exactly one bad week before something slips, and every hour you spend implementing is an hour you took from an engineer who needed it to get better at the job.

Ask yourself the plain question: what happens the day you're in back-to-back interviews and someone actually needs you. If the honest answer is that the work stalls, you're not staying hands on, you're the bottleneck wearing a hands-on story.

Some of this is letting someone struggle on purpose, and that's fine. Care doesn't always look like rescue. Stewardship is knowing which struggle is the productive kind, the kind that's actually how the skill gets built, and staying out of it even when you could obviously fix it faster yourself.

Leading technically without being the tech lead

You don't need to be the most technical person on the team. Not the point. What you need is to understand the work well enough to ask a useful question, spot real risk when it's in front of you, and help the team decide when a decision has stalled.

A specific, learnable competence. Not a softer version of the real thing.

Know enough about scope, dependencies, operational risk, and the tech debt actually piling up to have a real opinion on a trade-off, even when the final call belongs to your Staff Engineer. Make sure the team has real ways to build judgment in each other (pairing, mentoring, hiring loops that teach as much as they screen). Partner with product so work gets broken into pieces small enough to ship and learn from, instead of one long bet nobody can course-correct. Spec review instead of diff review is exactly this kind of shift, and it's a good test of the whole idea: you don't have to read the code to ask whether the spec covers the case that's actually going to break in production, you just have to know the domain well enough to know what that case is. Know enough about where things stand to help without turning a status update into an interrogation. Tell stakeholders the truth about timelines even when it costs you something.

And remove yourself from decisions that belong closer to the work than you are. Its own kind of blocker to clear, just aimed at yourself for once instead of at whatever's in the team's way.

Their growth is still your job

The easiest mistake with a senior person is assuming they're finished. That they don't need feedback, don't need a career conversation, don't need somewhere to say "I don't know" out loud.

They need it more, honestly. Not less.

Almost nobody else on the team is qualified to give it to them, and the isolation that comes with being the most senior technical person in the room is real, even when nobody complains about it. Psychological safety isn't a beginner's benefit. Invite them to challenge your judgment specifically, not as a courtesy, and mean it when they do.

Tie whatever they actually want next to a real problem the organization has, not a title they'd like. Expand scope through wider influence, deeper ownership, or both, and say plainly what the next level looks like instead of leaving them to guess from who got promoted last time. The career ladder only works when someone can see the next rung, and for your strongest engineer, pointing at it is still your job, same as it is for anyone else on the team.

The split between manager and Staff Engineer here owes a lot to a leadership guide a former colleague wrote at CircleCI.

Most of what breaks in this partnership breaks quietly, over months, in the direction of you doing more of the deciding than you meant to. Check it the way you'd check anything else that drifts, and don't just ask yourself whether you trust them. Count how many real technical calls this quarter were actually theirs.