The misconception about the staff engineer transition is that it's a continuation of the senior engineer role with more technical depth. It isn't. The senior engineer is the person who solves hard technical problems; the staff engineer is the person who decides which hard technical problems are worth solving. That's a fundamentally different job, and the skills that got you to senior — deep technical knowledge, fast execution, reliable delivery — are necessary but not sufficient for staff. The new skills are about scope, influence, and navigation: working across teams rather than within one, influencing decisions rather than just making them, and navigating the organizational dynamics that determine which technical work actually gets prioritized.

The transition was disorienting because the feedback loops changed. As a senior engineer, the feedback loop is tight: I write code, I see it work (or not), I ship it, users use it (or don't). As a staff engineer, the feedback loop is much longer: I work on architecture proposals that take months to implement, I influence technical decisions that don't bear fruit for quarters, I mentor engineers whose growth I won't see the results of for years. The longer feedback loops made it harder to feel productive, because the daily satisfaction of "I shipped a feature" was replaced by the weekly ambiguity of "I moved a proposal forward, but I won't know for months whether it was the right proposal." Learning to be productive on longer timescales is the psychological core of the staff transition.

The first thing that changed was what I worked on. As a senior engineer, my work was assigned — a PM gave me a feature, I designed and implemented it. As a staff engineer, I'm expected to find my own work — to identify the technical problems that matter to the organization and to pursue them without being told to. That shift from assigned work to discovered work is the biggest day-to-day change, and it requires a different kind of initiative. Instead of waiting for someone to tell me what to build, I'm scanning the organization for problems, evaluating which ones are worth my time, and making the case for investing in them. That's a skill that doesn't get practiced at the senior level, and developing it was the steepest part of the learning curve.

The second thing that changed was how I influenced decisions. As a senior engineer, my influence came from being the person who implemented the decision — I had opinions, but the implementation was where I added value. As a staff engineer, my influence comes from being the person who shapes the decision before implementation starts — writing technical proposals, facilitating design reviews, building consensus across teams. That's a different kind of influence, and it requires different skills: writing clearly, facilitating meetings effectively, navigating disagreements without either escalating or capitulating. The technical depth is still necessary, but it's no longer sufficient — the technical depth has to be paired with the communication and navigation skills to turn it into organizational impact.

What stayed the same is the technical foundation. The staff engineer who doesn't have technical credibility is a staff engineer in title only, because the influence comes from being someone whose technical judgment is trusted. If I stopped writing code entirely and became a pure "architecture astronaut," my influence would erode within months, because the engineers I work with would stop trusting that my proposals were grounded in the reality of the codebase. The balance is different — I write less code than I did as a senior, and the code I write is more exploratory (prototypes, proofs of concept) than production — but staying technically engaged is non-negotiable.

The other thing that stayed the same is the importance of mentoring. As a senior, I mentored junior engineers. As a staff, I mentor senior engineers, and the mentoring is one of the highest-leverage things I do, because a senior engineer I help grow becomes a force multiplier for the entire organization. The investment in mentoring compounds: each senior engineer I help grow goes on to mentor their own juniors, and the organizational capability expands in a way that wouldn't be possible if I were doing all the technical work myself. The staff engineer who tries to do everything themselves becomes a bottleneck; the staff engineer who builds capability in others becomes a multiplier.