That playbook breaks at the staff level — and breaks in a particular way. Not because the work is harder, but because the feedback loop disappears. Your manager is often not technical enough to evaluate your architectural decisions in detail. Your impact is measured in quarters and years, not sprints. The “did I do well this week” signal that used to arrive through PR comments and 1:1s no longer exists. You are flying on instruments.

The staff engineers who stay sharp over time tend to have one thing in common: they do not wait for the performance review cycle to tell them where they stand. They run their own.

Why Manager Feedback Gets Thin at the Staff Level

This is not about bad managers. It is structural.

At senior level, a good manager can look at your PRs, your code quality, your on-call behavior, and your team dynamics and form a real picture of your performance. The signal is dense, observable, and largely within their domain of expertise.

At staff level, your most consequential work — the architecture decision you made six months ago, the RFC that quietly settled a cross-team dispute, the one-on-one conversation that unblocked a team lead who was spiraling — is often invisible to your manager until it starts echoing in other people’s behavior. Your manager is frequently one level removed from the teams you are most influencing. Their picture of you is assembled from impressions, hearsay, and occasional artifacts like documents or reviews.

This is not a failure of management. It is the expected structure of the job. The responsibility for understanding your own trajectory shifts to you.

The Four Questions a Staff-Level Quarterly Review Should Answer

A useful self-review is not a list of things you did. It is a structured interrogation of four questions.

1. Where did I have real leverage?

Not “what did I work on,” but “what would have happened differently if I had not been here?” This is the staff engineer’s primary question. Staff-level impact is fundamentally about leverage: the ability to move more than your own weight.

Look back at the last quarter and identify the two or three moments where your involvement changed the trajectory of something. An architecture review where you caught an assumption that would have cost two teams a month of rework. A strategy conversation where your framing helped a VP see a tradeoff they were glossing over. A new engineer you spent time with early who is now shipping independently.

If you cannot find those moments, that is information. Not necessarily bad information — sometimes a quarter is correctly spent building context or recovering from a high-leverage quarter — but it is worth examining.

2. What was the quality of my technical judgment?

The hardest thing about self-evaluating technical judgment is that good judgment often prevents visible events. You did not have a production incident because you flagged the risk in advance. The migration did not fail because you insisted on the dry-run. Absence of catastrophe is not a natural self-review item.

To get at this, look for the decisions you made and trace their outcomes. What did you recommend, and was it right? Where did you defer to someone else, and how did that turn out? Where did you express a technical opinion and get overruled — and what happened? This last category is particularly worth examining. Being overruled is not failure, but tracking outcomes when you were overruled tells you whether your pattern recognition is ahead of or behind the organizational consensus.

Also: where did you not weigh in when you should have? Staff-level technical debt is often the sum of many silent moments.

3. What did I do for other people’s careers?

At senior level, mentorship is encouraged. At staff level, it is part of the job description even when it does not appear in the job description.

Think about the engineers whose growth you observed this quarter. Did any of them grow faster because of your involvement? Did any of them stagnate while you were nearby and you did not notice? Did you advocate for anyone in a context they could not see?

This question is not about being a caretaker. It is about recognizing that your returns at the staff level are increasingly mediated through other people’s capabilities. An engineer who becomes 30% more effective because of your guidance creates more cumulative output for your organization than any direct contribution you could make in the same time.

4. Where is my technical currency?

The invisible risk of staying in staff-level work for several years is that your technical opinions start to calcify. You know the systems you know deeply. The systems you do not know you stop knowing you do not know.

A quarterly self-review should include a hard look at what you are actually learning versus what you are confidently applying. Is your confidence in a domain based on fresh signal or on reputation? When did you last change your mind about something technical because of new evidence? Are there areas where juniors are shipping things you do not fully understand — and is that fine, or is it a gap worth closing?

You do not need to stay current on everything. But you need to know which domains you are current in and which you are trading on old credit.

Building the Evidence Trail

The self-review only works if you have material to review. The common failure mode is trying to reconstruct a quarter from memory and ending up with a document that is mostly things you remember feeling good about.

Some habits that make this easier:

Weekly artifact logging. Five minutes at the end of each week: What did I make? What decision did I make or influence? What did I learn? A single sentence each. A quarter of these entries gives you a real record.

Document everything that later disappears. The hallway conversation that redirected a project. The Slack thread that settled a debate. The 1:1 where you said something that visibly shifted someone’s thinking. These do not naturally turn into artifacts. You have to make them into artifacts — a brief written note, a follow-up doc, anything that can be referenced later.

Ask for explicit signal at key moments. After a major decision or deliverable, ask: “Was this useful? What would have been more useful?” Not fishing for praise — calibrating the instrument.

The Formats That Actually Work

A self-review does not need to be formal. The format that matters is one you will actually use.

Some staff engineers use a simple quarterly doc with four sections matching the four questions above. Some use a running notes file and do a quarterly read-through and synthesis. Some use VividMap’s growth modules to structure the review against concrete dimensions — the tool was designed specifically for the kind of multi-axis career tracking that becomes important above the senior level.

Whatever format you use, the constraint that makes it useful is specificity. “Had broad cross-team impact” is not a self-review. “Proposed and got approval for the event-sourcing migration during the Q1 architecture forum; three teams have since adopted it, reducing their schema-change cycle times by roughly half” is a self-review. The first is a vibe. The second is evidence.

When to Do It

Quarterly aligns well with most company review cycles, but the timing that matters most is: before you need it.

The staff engineers who get into trouble in performance reviews are typically the ones who start trying to recall their impact while the review form is open. By then the frame is defensive — you are reconstructing rather than reporting.

Run the self-review at the end of each quarter, ideally the week after the quarter closes while the material is still accessible. This turns performance reviews into transcription rather than excavation. You already know what happened. You have already evaluated it. The review form becomes a summary, not a reckoning.

The Broader Frame

The staff engineer’s relationship to career development is different from every prior level. Earlier in a career, your manager is largely responsible for your trajectory — they set goals, give feedback, decide what you get to work on, and advocate for you in calibration. A good manager at those levels is genuinely difference-making.

At the staff level, your manager is still important, but the responsibility has shifted. You are expected to understand your own impact, articulate your own trajectory, and create the visibility your work needs. The quarterly self-review is not a nice-to-have practice. It is the mechanism by which you stay the author of your own career rather than the subject of someone else’s impressions.

No one is going to tell you how you are doing in the ways that matter most. That job is yours now.

The second one exists nowhere in writing. It lives in people’s heads — in the instincts of engineers who have been around long enough to know who you really need to talk to before a proposal goes anywhere. This is the shadow org chart, and understanding it is one of the more underrated career skills an engineer can develop.

What the Official Chart Actually Represents

Org charts are documentation of authority, not influence. They tell you who has formal power — who can hire, fire, promote, and approve budgets. That information is real and it matters. But it captures a snapshot of a single dimension of organizational life.

What it misses is everything informal: who the technical expert is that three teams quietly consult before making architecture decisions, which program manager is the actual connector between two organizations that are theoretically aligned but practically siloed, and which senior engineer has been at the company long enough that even VPs will run a contentious idea past them before taking it to a staff meeting.

The org chart is the skeleton. The shadow org is the nervous system.

Why Informal Power Structures Develop

Organizations are made of people, and people form relationships that predate and outlast any reporting structure. A manager who was promoted two years ago still defers to a peer who mentored them. An engineer who moved teams carries institutional knowledge and trust that their new org chart position does not reflect.

Tanya Reilly’s The Staff Engineer’s Path makes this point clearly: staff-level engineers need to understand not just the technical landscape but the organizational one. The ability to influence without authority — a phrase that appears often in conversations about senior technical leadership — is fundamentally a shadow-org skill. It only works if you know where the informal authority actually sits.

Expertise creates its own gravity. When someone becomes the go-to person for a particular system, a domain, or a type of problem, people route around the org chart to reach them. Trust networks form through repeated collaboration, especially in ambiguous situations where the org chart offered no guidance. Historical relationships — people who worked together through a reorg, a crisis, or a product launch — carry weight that no reporting line can fully convey.

The Types of Power That Never Appear on Any Chart

There are a few archetypes worth learning to recognize.

Decision gatekeepers are people whose approval or buy-in is required before something moves forward, even though they have no formal authority over it. This might be a security architect who hasn’t shipped code in three years but whose concerns can halt a launch.

Informal advisors are the people leadership quietly consults before making anything official. Their titles are often misleading. They might be an individual contributor with a decade of context, or a director who is technically peers with five others but whose read on a situation carries disproportionate weight.

Connectors hold the shadow org together. They know everyone, they understand each team’s actual priorities (not the stated ones), and they are often the fastest path between two groups that technically have a shared manager but practically never talk.

Blockers are their own category. These are individuals whose opposition — stated or unstated — can stall an initiative indefinitely. Ignoring them is almost always a mistake.

What It Costs to Not Know

The consequences of shadow-org blindness tend to be concrete and painful. An initiative that needed sign-off from a particular team lead stalls because the engineer driving it escalated to the wrong person. A proposal gets shot down in a staff meeting because the informal advisor whose concerns were never addressed chose that moment to voice them publicly.

Missed alignment is probably the most common failure mode. Two teams are nominally working toward the same goal but the engineers who actually have influence over each team’s direction have never been in the same room. The official structure suggests this should be fine. The shadow org makes clear it isn’t.

How to Start Mapping It

Observation is the first tool. Watch who speaks in large meetings — not who is called upon because of their title, but who volunteers information and whose contributions visibly shift the conversation. Watch who gets thanked in all-hands updates. Both patterns point toward informal influence.

One-on-ones are the best research instrument available. When meeting someone new, asking “who else do you think I should talk to about this?” generates a map of consultation networks faster than any org chart crawl. The people who keep appearing in these referrals are usually load-bearing nodes in the shadow structure.

Pay attention to who gets consulted before decisions go public. There is almost always a pre-meeting before the meeting — a round of informal calls or Slack conversations where the real debate happens. Noticing who is in that circuit, and eventually being in it yourself, is how influence compounds over time.

Watch where escalations actually land. When something is stuck, where do people take it? The answer is often a person, not a process — and that person’s real organizational weight becomes visible in how quickly the problem moves afterward.

The Map Is Never Finished

Shadow org charts are not static. They shift when people leave, when teams merge, when someone builds trust through a high-stakes project or loses it through a public misstep. The engineer who was a key node two years ago may be largely invisible today.

The work of mapping it is therefore ongoing, not a one-time exercise. It requires staying curious about people — their history, their relationships, their areas of real expertise versus nominal responsibility.

The engineers who navigate organizations well are rarely the ones who read the official chart and followed it literally. They are the ones who understood that the chart describes one kind of organizational reality, and built the patience to understand the other kind too.