Feedback geben und empfangen in Engineering-Teams

# The SBI Framework
# Situation: When and where did this happen?
# Behavior: What specifically did the person do?
# Impact: What was the result or effect?
 
# ❌ Vague feedback (unhelpful)
"Your code reviews need improvement."
→ What specifically? Which reviews? What should change?
 
# ❌ Personal feedback (defensive reaction)
"You're too nitpicky in code reviews."
→ Attacks character, not behavior. Person shuts down.
 
# ✅ SBI feedback (specific and actionable)
"In yesterday's PR review on the auth service (Situation),
 you left 23 comments, most about formatting and naming
 conventions that our linter already enforces (Behavior).
 The author spent two hours addressing comments that
 added no value, and the PR was delayed by a day (Impact).
 Could we agree that linter-enforceable issues don't
 need manual review comments?"

// Structure for preparing feedback
interface FeedbackNote {
  situation: string;   // Specific time, place, context
  behavior: string;    // Observable action (not interpretation)
  impact: string;      // Effect on team, project, or outcomes
  suggestion?: string; // Optional: what to do differently
}
 
// Positive feedback follows the same structure
const positiveFeedback: FeedbackNote = {
  situation: 'During the incident on Tuesday',
  behavior:
    'you wrote a clear timeline in Slack, tagged the right people, '
    + 'and kept stakeholders updated every 15 minutes',
  impact:
    'the rest of the team could focus on the fix instead of fielding '
    + 'status questions, and we resolved it 40 minutes faster than usual',
};
 
// Constructive feedback
const constructiveFeedback: FeedbackNote = {
  situation: 'In the last three sprint plannings',
  behavior:
    'you committed to 15-18 story points but consistently delivered 8-10, '
    + 'with the remaining work carrying over',
  impact:
    'other team members who depend on your deliverables had to adjust '
    + 'their plans mid-sprint, and the product team lost confidence in '
    + 'our estimates',
  suggestion:
    'What if we started with 10 points and added more mid-sprint '
    + 'if you finish early? That gives a more reliable baseline.',
};

// ❌ Bad code review comments
 
// Too vague
"This doesn't look right."
// → What doesn't look right? What should it look like?
 
// Condescending
"You should know that this is an anti-pattern."
// → Assumes intent, creates defensiveness
 
// Nitpicking without value
"Rename 'data' to 'userData'."
// → If the linter didn't flag it, is it worth blocking the PR?
 
// ✅ Good code review comments
 
// Specific with reasoning
"This query runs inside a loop (line 45-52), which will execute
 N+1 queries for N items. Consider batching with a WHERE IN clause.
 Here's an example: [link to internal doc]"
 
// Question format (non-threatening)
"I noticed this bypasses the rate limiter. Is that intentional?
 If so, could we add a comment explaining why?"
 
// Acknowledging trade-offs
"I see why you used a Map here for O(1) lookups. One concern:
 this map grows unbounded over the request lifecycle. For long-running
 requests, this could become a memory issue. Would an LRU cache with
 a max size be worth the added complexity?"

# Code Review Comment Template
 
## For bugs or issues:
"[What I see] → [Why it's a problem] → [Suggested fix]"
 
Example: "This catches all exceptions (line 30) including the
ValidationError we throw intentionally in line 15. This means
validation failures return a 500 instead of 400. Suggest catching
only DatabaseError here."
 
## For style/approach (non-blocking):
"nit: [suggestion]. Not blocking — take it or leave it."
 
Example: "nit: extracting lines 20-35 into a validateInput()
function would make the handler easier to scan. Not blocking."
 
## For learning opportunities:
"TIL / FYI: [concept]. [link to docs or explanation]"
 
Example: "FYI: PostgreSQL's ON CONFLICT DO UPDATE (upsert)
could replace this check-then-insert pattern and avoid the
race condition on concurrent requests. Docs: [link]"

// ❌ Defensive responses to feedback
 
// Explaining away
"Well, I did it that way because the deadline was tight."
// → May be true, but this stops the conversation
 
// Deflecting
"Everyone writes code like that."
// → Doesn't address the specific feedback
 
// Counter-attacking
"Maybe if the requirements were clearer, I wouldn't have to..."
// → Turns feedback into conflict
 
// ✅ Productive responses to feedback
 
// Acknowledge and clarify
"Thanks for pointing that out. Can you walk me through
 what you'd expect instead? I want to make sure I
 understand the standard."
 
// Accept and commit
"You're right, that query pattern would cause N+1 issues
 at scale. I'll refactor it before merging."
 
// Disagree respectfully
"I see your concern about the Map growing unbounded.
 In this case, the request lifecycle is capped at 30 seconds,
 so the map would hold at most ~100 entries. I think the
 simplicity trade-off is worth it here, but I'm open to
 adding a size guard if you feel strongly."

## Preparing Feedback for a 1-on-1
 
### Before the meeting:
1. Write down the SBI (Situation-Behavior-Impact) using the template
2. Identify one specific, recent example (not a pattern from 6 months ago)
3. Think about what "better" looks like — have a suggestion ready
4. Check your intent: is this feedback meant to help THEM, or vent YOUR frustration?
 
### During the meeting:
1. Ask permission: "I have some feedback about [topic]. Is now a good time?"
2. Deliver the SBI concisely — don't over-explain or dilute with caveats
3. Pause. Let them respond. Don't fill silence.
4. Listen without rebutting — understand their perspective
5. Agree on a specific next step
 
### After the meeting:
1. Follow up on the agreed action in the next 1-on-1
2. If you see improvement, say so explicitly — "I noticed X changed and it helped Y"

// The feedback sandwich is a common anti-pattern
// ❌ Feedback sandwich
const sandwich = [
  "You're doing great work on the API migration.",  // Praise (feels fake)
  "But your PR descriptions are often missing context...", // Real feedback
  "Keep up the good work though!",  // Praise (definitely fake)
];
// The person learns to ignore the praise because
// it always precedes criticism
 
// ✅ Direct feedback with genuine context
const direct = [
  "I want to talk about PR descriptions.",
  "The last three PRs had no description of why the change was made.",
  "When I review them, I have to read every file to understand the intent.",
  "A two-sentence summary of the 'why' would save review time significantly.",
  "Would it help to set up a PR template with prompts?"
];
// Clear, specific, action-oriented

## Team Feedback Norms
 
### In Code Reviews:
- Comments are about the code, not the person
- Use "we" language: "We should handle this edge case" not "You missed this"
- Prefix non-blocking comments with "nit:" so the author knows what's required
- Approve with comments for minor issues — don't block PRs over style
 
### In Retrospectives:
- Focus on systems and processes, not individuals
- "We had three incidents caused by missing tests"
    not "John keeps shipping untested code"
- Every criticism must include a proposed improvement
- Action items have owners and due dates
 
### In Daily Work:
- Give positive feedback publicly and immediately
- Give constructive feedback privately and promptly (within 48 hours)
- Assume positive intent — ask "why" before assuming the worst
- Manager models the behavior: asks for feedback on themselves first