Staff Engineers: how to manage them without micro-managing
Managing a Staff Engineer is a balancing act. Too present, you block someone who needs space to have broad impact. Not present enough, you lose visibility into what's happening and can't help them navigate the organizational and political aspects that are part of their role.
Most EMs err in one direction or the other. Here's how to find the right balance.
Understanding what they need
A Staff Engineer is not a Senior Engineer with more experience. It's a different level with a different scope. Their impact is no longer measured in PRs or features — it's measured in the technical quality of decisions across an entire team, in the ability to move cross-team topics forward, in architectural influence over 6–18 months.
This scope implies specific needs. They need autonomy to explore, time to think without being in the constant flow of delivery. They need visibility into strategy and organizational priorities so their work is aligned. And they need to be recognized for their real impact — not for surface-level activity.
That last point is crucial. A Staff Engineer who pushes few commits this week because they're thinking through the next 6 months of architecture is not "working poorly." A manager who measures performance solely on visible activity creates an environment where Staff Engineers spend their time justifying their value rather than creating it.
The micro-management trap
Micro-managing a Staff Engineer often takes subtle forms. It's not "show me your code before merging." It's "why weren't you at that meeting?", "have you made progress on what we discussed?", "send me a summary of what you're doing this week."
These requests seem reasonable — a manager has the right to know what's happening in their team. But for a Staff Engineer, they mean something else: you don't trust my judgment about how to use my time, and you're forcing me to account for granularity that isn't the right level.
The long-term consequence: the best Staff Engineers leave. Not immediately — they try to adapt, to give the expected reporting while doing their work. But over time, as the environment becomes too constraining for their way of operating, they look elsewhere.
Staying informed without blocking
The right interface with a Staff Engineer isn't a weekly status report — it's a quality 1:1, perhaps less frequent, but substantively dense. The goal isn't "what did you do this week?" but "where are you blocked?", "what can I unblock organizationally?", "how can I help you have more impact?"
You don't need to know everything they do. You need to know: is their work aligned with strategic priorities? Are there organizational blockers only you can resolve? Do they feel recognized for their real impact?
These three questions, asked regularly in a space of trust, give you everything you need without getting into the details of daily execution.
Impact and visibility
A recurring problem for Staff Engineers: their work is hard to make visible. A Senior Engineer merges PRs — that's measurable. A Staff Engineer spends two weeks building consensus around an architecture decision — that doesn't show up in standard metrics.
Your role as manager is to amplify the visibility of that impact. Not in their place — by creating spaces where they can share it: design reviews, tech talks, conversations with other teams. And by explicitly naming, in performance reviews and conversations with your own management, what this person has made possible.
This is an invisible but essential form of management. The Staff Engineer who knows their manager understands and values their type of impact is infinitely more aligned and engaged than one who constantly has to justify how they spend their time.
In Moston, you can note these non-quantifiable contributions — decisions influenced, topics unblocked, alignments achieved — and have them at hand when the time comes to talk about them. Managerial memory shouldn't forget what isn't easily measured.