Performance and Feedback: SBI Model, Growth Plans

Feedback is the single tool that grows engineers. Done well, the team's bar rises every quarter. Done poorly, the team stagnates and the strongest people leave. This chapter shows the SBI model for individual feedback, the growth plan that drives quarterly conversations, and the underperformer process that gives people a fair chance.

When does formal feedback discipline matter?

Three signals.

You manage people. From day one, you owe them feedback. Not giving it is a worse signal than giving difficult feedback. The 1-on-1 cadence is the channel that carries it.

Promotion or demotion conversations are coming. A clear paper trail of feedback over time is the only honest basis for either.

The team is large enough that you cannot remember every moment. Documented SBI feedback per engineer becomes the record.

If you are a peer tech lead with no direct reports, feedback still matters but happens informally - "hey, that PR review was too harsh".

What is the cost of weak feedback culture?

Three failure modes.

Surprise dismissal. Engineer let go after 2 years; they had no idea their performance was concerning. Career-damaging for them, lawsuit-risk for you.

Strong-performer attrition. High performers want growth feedback. Without it, they assume they are stagnating and leave. The flat performer who never asked for feedback stays.

Vague reviews. "Be more collaborative" or "level up your skills" - phrases that mean nothing actionable. Engineer reads, shrugs, changes nothing.

What is the SBI feedback template?

For a single feedback conversation:

# Feedback — {{ engineer name }} — 2026-06-17

## Situation
In yesterday's sprint planning meeting.

## Behaviour
You committed the team to shipping the refund email template
this sprint without checking with Carol, who owns design and was
out sick.

## Impact
Carol returned today, found the commitment, and feels the
team is making decisions about her work without her. She
mentioned she's "thinking about her role" - that's a serious
flag we need to address.

## What I'd like to see
Before committing scope that depends on someone, ping them in
the meeting (Slack works) or defer the decision. Same outcome,
no surprise.

## Engineer's response
{{ Captured live during the conversation }}

The template is for the manager's notes. The conversation itself is more flowing - SBI is the spine, not the script.

What does the quarterly review template look like?

# Performance Review — {{ engineer }} — Q2 2026

## Summary
{{ One paragraph: what they shipped, growth observed, one focus
   area for next quarter }}

## Wins this quarter
- {{ Project / outcome }}
- {{ Behaviour / culture contribution }}
- {{ Mentorship / cross-team help }}

## Growth themes (from quarter's SBI feedback)
- {{ Theme 1 — strong examples }}
- {{ Theme 2 — area to develop }}

## Goals for next quarter
- {{ Outcome goal: ship X by Y }}
- {{ Behaviour goal: lead 1 cross-team initiative }}
- {{ Skill goal: deepen knowledge of {{ area }} }}

## Career conversation
- Current level: {{ level }}
- Aspiration in 12 months: {{ from engineer }}
- Bridge: {{ what we'll do this quarter to move toward it }}

## No surprises
The engineer should recognise everything in this review from
prior 1-on-1 conversations. If anything is new, the manager
failed and apologises in the meeting.

The "no surprises" clause is the contract. Engineer reads review, recognises the themes from past 1-on-1s, knows where to focus.

How does feedback scale to multi-team?

flowchart TB
    SBI[Daily SBI feedback<br/>via 1-on-1] --> Quarterly[Quarterly review<br/>1 manager + 1 engineer]
    Quarterly --> Calibration[Cross-team calibration<br/>EMs align on bar]
    Calibration --> Promo[Promotion / comp decisions]
    Quarterly --> Growth[Updated growth plan]

Calibration across teams keeps the performance bar consistent. Without it, Team A's 'meets bar' becomes Team B's 'exceeds bar' and promotion politics emerge. EMs review each other's reviews quarterly to align.

What failure modes does feedback introduce?

• Saved up feedback. "I'll mention it at the review." Mitigation: deliver feedback within 48 hours; review consolidates, doesn't introduce.
• All positive or all negative. Vague positivity is unhelpful; pure negativity demoralises. Mitigation: balance, but don't manufacture - if there's nothing positive, that's the message.
• Comparison feedback. "You should be more like Bob." Mitigation: feedback is about the engineer's behaviour, not about Bob.
• Promotion only at review time. Engineer waits 6 months for any growth conversation. Mitigation: growth is a 1-on-1 topic monthly; review consolidates.

When is formal feedback overkill?

One case. Pair-programming partner, peer-level, no manager relationship: feedback happens in the moment. "That code review was harsh" said today is enough.

The formal structure earns its overhead at manager-report relationships and at quarter+ time horizons.

Where should you go from here?

You have completed the people group. Next chapter: status reports that work - the artifact that communicates project health. After that, decision logs and ADRs is the last artifact chapter before case studies.