Staff to Senior Manager: 90% the Same Job

I came back to Dropbox in May 2023 as a Staff Engineer. Three months later I was a Senior Engineering Manager. That transition scared me more than it should have.

The fear was that management would be a fundamentally different discipline. That I'd be bad at it. That the things I'd spent years getting good at (architecture, technical decision-making, building systems that scale) would become irrelevant overnight. I'd heard the stories: "You'll never write code again." "It's all politics and spreadsheets." "You'll miss building things."

Three months in, I can say with confidence: the job is about 90% the same.

The Staff Archetype That Transfers

Will Larson's staff engineering archetypes describe the ways staff engineers create impact outside of direct code output. (His book Staff Engineer and the surrounding community at staffeng.com are still the best resources for anyone navigating this level.) I was some blend of the Tech Lead and Architect archetypes. When I look at what that actually meant day-to-day, the overlap with senior management is almost complete:

Gathering requirements. Understanding what stakeholders actually need, not just what they say they want.
Clarifying requirements. Translating vague asks into specific, actionable work.
Understanding complexity. Assessing the real difficulty of a problem before committing to a solution.
Breaking down work. Decomposing large, ambiguous projects into pieces a team can execute on.
Sequencing work. Figuring out what comes first, what can be parallelized, and what blocks what.
Prioritizing work. Saying no to the things that don't matter this quarter, even when they're interesting.
Bringing the team along. Communicating context so people understand why they're working on what they're working on.
Creating safe spaces. Making it okay to flag risks, ask questions, and push back on bad ideas.
Being personable. Building trust, being someone people want to work with, reading the room.

That's not a "management" list. That's what I was doing as a Staff Engineer. The promotion just made it official and removed the expectation that I'd also be writing production code every day.

What Actually Changed

The honest answer: not much, at first.

As a Staff Engineer I was already running the technical direction for the team. I was already in the planning meetings, already breaking down the roadmap, already coaching engineers on their approach, already escalating risks and unblocking people. The title change formalized a role I'd been performing informally.

The 10% that's new:

Explicit people responsibility. As a Staff, I influenced without authority. I could recommend someone for a stretch opportunity but couldn't assign it. Now I own career development conversations, performance feedback, and growth plans. The feedback I used to give informally ("hey, I noticed you're holding back in design reviews") now has formal weight behind it.

Scope of communication. I'm now in rooms I wasn't in before. Cross-functional planning, headcount discussions, org-level strategy. The information flow changed: more context from above, more responsibility to filter and distribute it down.

Being evaluated differently. Nobody measures a Staff Engineer on team health metrics or retention. Now they do. My success is measured by the team's output, not my personal contributions. That's a mindset shift, not a skill shift.

Player-Coach by Conviction

I still write code. Not as much, but I refuse to fully disconnect from the codebase. This is a deliberate choice, not a failure to let go.

I believe technical leaders have to stay close to the code. Not to be the best individual contributor on the team, but to maintain the judgment that makes their other work credible. When I review an architecture proposal, my feedback is better because I've felt the friction of working in this codebase recently. When I push back on a timeline, it's because I've seen similar problems take longer than expected in practice, not because of abstract concern.

I think this becomes even more important as you get more senior. Even through to being a director (which I'll write about in a later post), I intend to stay a player-coach. Directors need to be extremely technical. It's a superpower to be in a room with other directors and form technical strategy because you understand the code, not just the org chart. Finding ways to restructure teams and systems simultaneously is only possible if you're fluent in both.

The engineers on my team know I can read their PRs and actually understand the tradeoffs. That earns trust that no amount of management training replicates.

The Nervousness Was Wrong

The fear came from a category error. I thought "manager" and "engineer" were different species. They're not. Charity Majors wrote about this in Twin Anxieties of the Engineer/Manager Pendulum, and she's right that the anxieties are overblown. The Staff Engineer archetype, at least the version of it that emphasizes influence, communication, and system-level thinking, is management without the title.

If you're a Staff Engineer who finds yourself constantly in the position of rallying people, clarifying direction, and removing obstacles, you might already be managing. The title is just permission to own it explicitly.

The people who should be nervous about the transition are the Staff Engineers whose identity is entirely wrapped up in individual contribution: heads-down coding, deep in the weeds, not particularly interested in what the rest of the team is doing. That's a valid Staff archetype too (closer to Larson's "Solver"), but it's a bigger jump to management. Gergely Orosz and Kent Beck's piece on Measuring developer productivity touches on a related point: the further up the experience curve you go, the more your impact is measured in outcomes and influence, not output. For the rest of us, the ones already operating at the system level, it's mostly just acknowledging what was already true.