Feedback and the Path to Staff Level — The Senior Engineer Playbook

Feedback is one of the highest-leverage activities in engineering organizations. Given well, it accelerates growth, surfaces problems early, and builds the psychological safety that makes teams effective. Given badly, it damages trust, creates defensiveness, and drives the kind of silence that lets problems compound.

Most engineers give feedback badly. This chapter is about doing it well — and about receiving it in a way that actually helps you.

Why Feedback Is Hard

The core difficulty: giving meaningful feedback requires caring about the person's growth more than about avoiding an uncomfortable conversation. Most people, most of the time, optimize for comfort — softening feedback to the point where it is unclear, or delivering it in a context where the person cannot act on it, or avoiding it entirely.

The cost of avoiding feedback is invisible in the short term and significant over time. The junior engineer who never gets clear feedback about a pattern in their work will repeat that pattern for years. The senior engineer whose architecture decisions go unchallenged will compound on shaky foundations. The team whose retrospectives are full of vague "we should communicate better" suggestions will have the same retrospective next quarter.

Giving Feedback That Changes Behavior

Effective feedback is specific, behavioral, and consequential. The SBI model (Situation-Behavior-Impact) is a reliable structure:

Situation: the specific context — not "in general" but "last Tuesday's design review"
Behavior: what you observed — not what you inferred, not what you felt, but what you saw or heard
Impact: what the effect was — on the team, on the project, on you, on the user

"You are not communicating well" is not feedback. It is a judgment.

"In the design review last Tuesday, you interrupted three different people while they were making points about the migration approach. I noticed the discussion started to shut down after that — fewer people spoke up in the second half of the meeting." — that is feedback. It is specific, behavioral, and it names an impact that the person can connect to something they can change.

The Delivery Conditions

Feedback delivered in the wrong conditions does not land regardless of quality. The conditions that matter:

Private, not public. Feedback that might be embarrassing should almost never happen in front of others. Even constructive feedback in a public setting activates self-protection rather than reflection.

Soon after the event. Feedback delivered three months after the incident being discussed is reconstructed history, not a useful signal. The person being reviewed will not remember the event clearly, and the pattern may have already changed. Sooner is better. "Can I share something about that meeting while it is still fresh?" is almost always the right move.

With permission. "Can I give you some feedback?" is not just a courtesy. It activates the person's openness to hear it. Someone who is surprised by feedback often goes into defense mode before the first sentence is complete.

With specificity about what you are asking for. If you want someone to change a behavior, say so. If you are sharing an observation for their awareness without a specific ask, say that too. "I am not asking you to do anything differently, I just want you to be aware of this" and "I would like you to try X differently going forward" are very different conversations.

Strong Recommendations, Not Vague Observations

A pattern that plagues senior engineer feedback: the observation without a recommendation. "I notice you tend to underestimate tasks" is less useful than "I notice you tend to underestimate tasks — next time, try adding 30% to your initial estimate and see if that puts you closer to actual." The first is information. The second is actionable.

Engineers who give strong, specific recommendations in their feedback are more trusted as feedback providers, because their feedback reliably translates into something the recipient can do. Vague observations leave the recipient with the uncomfortable work of figuring out what to do with them — and if that work is hard enough, most people will not do it.

Receiving Feedback Without Defensiveness

Receiving feedback well is as much a skill as giving it. And for engineers who have built a strong sense of identity around their technical competence, it is often harder.

The defensive response pattern: someone gives feedback, you explain why you did what you did, you cite the context that made the action reasonable, and the conversation ends with the other person not sure whether they were heard. This is not receiving feedback — it is explaining it away.

A better approach:

Listen first. Do not start formulating your response while the other person is still speaking. Listen until they are finished.

Ask a clarifying question before responding. "Can you tell me more about what you observed?" or "When specifically did you notice this?" gives you more information and signals that you are taking it seriously.

Acknowledge the impact. Even if you disagree with the interpretation, acknowledge that the impact they described was real. "I hear that the meeting felt less open in the second half — that is not what I intended, and I want to understand it better" keeps the conversation productive.

Decide later. You do not have to agree or disagree in the moment. "Let me think about this" is a complete and professional response to feedback you are not sure what to do with. Deciding under social pressure is different from deciding after reflection.

The engineers who receive feedback best are the ones who have genuinely separated their ego from their work product. Their code, their architecture decisions, their communication patterns — these are things they did, not things they are. That separation makes feedback feel like information rather than attack.

What Staff Level Actually Requires

The transition from senior to staff is the hardest level transition in an engineering career. It is harder than junior to mid, or mid to senior, because the gap is qualitative rather than quantitative. You are not doing more of what you did at senior. You are doing a different kind of thing.

Staff level requires operating at organizational scale. Where a senior engineer's primary unit of impact is their team, a staff engineer's primary unit of impact is a set of teams, a technical domain, or a business area. The question "what did you personally build?" becomes less important than "what did you enable?"

The specific things that distinguish staff-level impact:

Scope that spans teams. A senior engineer's roadmap is their team's roadmap. A staff engineer shapes the roadmap across multiple teams — identifying the dependencies, the conflicts, the leverage points that only become visible at altitude.

Technical strategy ownership. Staff engineers write the documents that define how a technical area should evolve over one to three years. Not "here is the design for this feature" but "here is how our data infrastructure should be structured over the next two years, and here is the sequencing that gets us there."

Multiplying engineer output. The clearest signal of staff-level impact: other engineers produce significantly better work because of your presence, your code reviews, your design document reviews, your architectural guidance. Your output is other people's output.

Credibility in multiple contexts. A staff engineer can speak credibly in the engineering review, the PM roadmap discussion, and the leadership business review — not because they are a generalist, but because they can translate between these contexts. They know how to frame a technical trade-off as a product risk and a product risk as a technical constraint.

Building the Portfolio of Impact

The visibility problem is real: good work that nobody knows about does not advance careers. This is not an argument for self-promotion in the pejorative sense. It is an argument for making your work's impact legible.

Specific practices:

Write brief retrospectives after significant projects: what you did, what impact you can measure, what you learned. These serve as records when review cycles come.
Present engineering work in team and cross-team forums. Not to take credit, but to make the thinking visible to people who were not in the room.
Volunteer for high-visibility, cross-team work. Working with people outside your team is how you build the reputation and relationships that staff-level influence requires.
Connect your technical decisions to business outcomes in writing. "This refactor will reduce the time to implement new integrations from two weeks to two days, which directly affects our ability to support the partnership roadmap" is more powerful documentation than "cleaned up legacy code."

The Practical Move This Week

Write your own "impact brief": three to five bullet points describing the most significant things you have delivered in the last six months, with specific outcomes or metrics where possible. Send it to yourself. Read it through the lens of "is this senior-level work or staff-level work?" The gap between what you wrote and what staff-level would require is the gap to close.

That is the playbook. The chapters are practices. The thread connecting them is operating mode: how you show up, how you communicate, how you lead. Every chapter describes something that can be practiced starting this week.