Giving constructive feedback to Senior ICs as a new manager fails not because the feedback is wrong, but because you lack the credibility to deliver it. The template you need is not a script — it is a pre-negotiation of intent. Most new managers lead with the feedback content; they should lead with why their opinion should matter. The only template that survives a Senior IC’s scrutiny is one that separates your judgment from your role, and frames the feedback as a test of shared standards, not personal critique.
Title: Template: Giving Constructive Feedback to Senior ICs as a New Manager
TL;DR
Giving constructive feedback to Senior ICs as a new manager fails not because the feedback is wrong, but because you lack the credibility to deliver it. The template you need is not a script — it is a pre-negotiation of intent. Most new managers lead with the feedback content; they should lead with why their opinion should matter. The only template that survives a Senior IC’s scrutiny is one that separates your judgment from your role, and frames the feedback as a test of shared standards, not personal critique.
Running effective 1:1s is a system, not a talent. The 0→1 SWE Interview Playbook (2026 Edition) includes agenda templates and question banks for every scenario.
Who This Is For
A first-time engineering or product manager who was recently promoted from IC to manager, now responsible for a team that includes Senior ICs (Staff+ level) who were peers or informal mentors six months ago. You have the title, but you feel like an imposter every time you give feedback to someone who has shipped more products than you have managed meetings. You need a template that works when your authority is borrowed, not earned.
Why do Senior ICs resist feedback from a new manager?
The resistance is not about the feedback — it is about your standing to give it. In a Q3 debrief for a Staff engineer at a top-tier search company, the hiring manager rejected a candidate because the candidate said "I always welcome feedback from my manager." The manager replied: "You should welcome feedback from anyone who can help you ship faster. If you only listen to managers, you’re not Senior."
Senior ICs have a higher bar for who gets to critique their work. They do not see your title as a license to judge; they see your technical or strategic depth as the only license. The problem isn't your feedback content — it's your credibility signal. A Senior IC will test whether you understand their context before they let your words land.
The counter-intuitive insight: you must prove you understand their work first, then deliver feedback. Not the other way around. Most new managers lead with the feedback, hoping the title will carry them. It will not.
How do I structure a feedback conversation with a Senior IC?
Start with a framing statement that separates your role from your judgment. Do not say "I think you should..." because that invites debate about your opinion. Instead, say: "I need your help understanding something. I saw X, and I want to check if my read matches your intent."
This shifts the dynamic from judge-and-correct to co-diagnosis. The Senior IC now has agency. They can confirm or correct your observation. Once they agree on the data, then — and only then — can you offer your judgment.
In a real conversation at a FAANG company, a new manager tried this with a Staff engineer who had been ignoring sprint deadlines. The manager said: "I noticed you missed the last two sprint commitments. I want to understand if that was a priority call or a capacity issue." The Senior IC paused and said: "It was both. I deprioritized those tickets because the architecture decision required more research. I should have communicated that." The manager then said: "I agree with the priority call. But next time, I need you to flag it before the sprint ends, not after." The Senior IC accepted it. Why? Because the manager first validated the Sr IC’s judgment before adding their own constraint.
The template is not the script — the template is the sequence: observe, validate intent, then add your constraint.
What specific language should I use in the template?
Use the "Intent-Impact-Contract" framework. Not the "Situation-Behavior-Impact" model that works for junior ICs. Senior ICs find SBI condescending because it assumes they don’t already know their impact.
Intent: "This is what I think you were trying to do."
Impact: "This is what actually happened from the team’s perspective."
Contract: "This is what I need from you going forward."
Example for a Senior IC who is over-mentoring and under-producing:
"Your intent was to grow the junior engineers. That is valuable. The impact is that your own deliverables slipped two sprints in a row. The contract is: you can mentor, but only after your core work is done, and you must flag trade-offs before they become delays."
In a hiring committee at a top tech company, a VP rejected a candidate who used SBI on a Senior IC during a mock feedback exercise. The VP said: "You treated a Staff engineer like an intern. They know what they did. Tell them what you need, not what they already know."
How do I handle pushback when a Senior IC disagrees with my feedback?
You do not escalate. You clarify the standard. Senior ICs will push back if they think your feedback is subjective or arbitrary. The only defense is a shared standard — a team agreement, a company principle, or a measurable outcome.
When a Senior IC says "I disagree with your assessment," do not defend your opinion. Say: "Let’s look at the data. What does done look like here?" If you have no data, you lose. That is the real test.
In a project review at a major cloud provider, a new manager told a Senior IC that their API design was "over-engineered." The Senior IC pushed back hard. The manager had no data — just a feeling. The Senior IC said: "Over-engineered compared to what? Show me the latency requirement we violated." The manager had nothing. The feedback was ignored, and the manager lost credibility for months.
The correct approach: the manager should have said: "I see your design has 3 abstraction layers. The team’s latency budget is 50ms. Can you show me how this design meets that budget?" Now the Senior IC has to prove their design against a standard, not against your opinion.
Not "I think this is wrong," but "does this meet our standard?"
Should I give feedback publicly or privately to a Senior IC?
Always private. This is not a debate — it is a risk calculation. Senior ICs have influence that extends beyond their title. Public feedback, even if constructive, triggers a status threat. They will defend their reputation before they process your content.
In a sprint retro at a high-growth startup, a new manager publicly said: "I think we need to improve code review turnaround. Sarah, your reviews have been averaging 3 days." Sarah, a Staff engineer, did not respond in the retro. She later scheduled a 1:1 and said: "If you have feedback about my work, you bring it to me first. You do not use me as a teaching example for the team." The manager had to apologize.
The rule: praise publicly, feedback privately. If the feedback is about a team process, frame it as a process problem, not a person problem. "Our code review SLA is slipping. Let’s discuss as a team how to fix it." Then in private: "Sarah, your reviews are the longest. Can we talk about what’s blocking you?"
How do I give feedback on strategic direction to a Senior IC who knows more than me?
You do not give feedback on their strategy — you give feedback on their communication of it. This is the hardest lesson for new managers. You cannot out-strategize a Staff+ IC in their domain. You can, however, judge whether their strategy is understood by the team, aligned with company priorities, and actionable by others.
The template: "I trust your technical judgment on this decision. But I noticed the team is confused about the timeline. Can you walk me through how you communicated the trade-offs?"
In a real case at a large e-commerce company, a new manager tried to critique a Senior IC’s architectural decision. The Senior IC had 10 years of experience in distributed systems. The manager had 2. The conversation went nowhere. The manager later shifted to: "I am not questioning your choice. I am asking: does the rest of the team understand why you chose this? Because I see hesitation in the implementation." The Senior IC paused and said: "You are right. I assumed they would trust my judgment. I need to explain the reasoning better."
The feedback was accepted because it was about communication, not competence. The new manager stayed in their lane — managing alignment, not technical depth.
Preparation Checklist
- Write down the Senior IC’s intent before the conversation. If you cannot articulate what they were trying to achieve, you are not ready to give feedback.
- Prepare a shared standard to reference. A team principle, a sprint goal, a latency SLA. Without it, the feedback is just your opinion.
- Rehearse the "Intent-Impact-Contract" sequence. Say it out loud. If it sounds like a script, rewrite it.
- Schedule the feedback as a 1:1, not a drive-by. 30 minutes minimum. Senior ICs need time to process and push back.
- Ask yourself: "Would this feedback survive a public challenge?" If not, rethink it.
- Work through a structured preparation system (the PM Interview Playbook covers managing Senior ICs with real debrief examples from FAANG-level feedback conversations).
Mistakes to Avoid
BAD: "I think your code review comments are too harsh. You need to be nicer."
GOOD: "The team’s code review satisfaction score dropped 20% last quarter. Your comments have the highest clarity score but the lowest empathy score. Can we talk about how to balance both?"
BAD: "You missed the deadline again. This is unacceptable."
GOOD: "We agreed on a Friday delivery. It is Monday. What changed, and what do you need to prevent this from repeating?"
BAD: I will give this feedback in the team standup so everyone learns from it.
GOOD: I will give this feedback in a private 1:1, and only mention it in standup if the Senior IC asks me to.
FAQ
Can I give feedback to a Senior IC without any technical expertise in their area?
Yes, but only on communication, alignment, and impact — not on technical decisions. Stay in your lane as a manager of outcomes, not a judge of implementation.
What if the Senior IC ignores my feedback entirely?
Schedule a follow-up with a shared standard. If they still ignore it, escalate to your manager with data showing the impact. Do not escalate without data.
How often should I give feedback to a Senior IC?
Monthly at most. Weekly feedback feels like micromanagement to a Senior IC. Let the work speak between conversations.
Ready to build a real interview prep system?
Get the full PM Interview Prep System →
The book is also available on Amazon Kindle.