Usable with a quick edit12 of 12 checks passed
The output is complete, evidence-based, and directly usable with at most light edits; no re-checking of evidence or redoing of reasoning is needed.
Output
Calibration Pre-read: Lukas Brenner, Senior PM
1. Review summary and proposed rating
Proposed rating: Meets expectations
Lukas exceeded two of his three goals. The third launched on schedule but failed in a way that was partly his responsibility. On balance, that is a solid year with one clear development area: launch readiness.
Goal 1: Cut carrier onboarding time from 21 days to 10. Exceeded. Onboarding now takes 9 days, beating the target by a day. That is a 57% reduction in a metric that directly affects carrier activation and revenue timing. Three of four peers cite this work specifically as a strength.
Goal 2: Launch Dispatch v2 by October. Not met in substance. Dispatch v2 shipped in October, so the date was hit. It was rolled back six days later. Support had not been briefed, and 340 tickets arrived in the first week. The goal was a working launch, not a date, so I do not count it as achieved.
On accountability, both of these facts matter: - Lukas was on approved leave the week before launch, and his deputy ran the final launch checks. He was not the person who missed the support briefing on the day. - Lukas still owned the launch plan. A Senior PM should leave behind a readiness process that does not depend on his being present, including a support-briefing step and a clear handover. The Head of Operations' concern about how Dispatch was communicated is fair and consistent with this.
The failure was in launch-readiness process and handover. It was not a failure of strategy or product judgment. The product itself is due to relaunch next quarter, which suggests the underlying work is sound.
Goal 3: Grow carriers using live tracking from 40% to 55%. Exceeded. Adoption reached 57%, two points above target.
Peer feedback. Three of four peers are positive, citing the onboarding work and his collaboration. The one negative review, from the Head of Operations, is specific to Dispatch communication and matches the development area above.
Why Meets rather than Below. - Two of three goals were exceeded, and the miss has a specific, correctable cause. - Last year Priya, also a Senior PM, had a launch rolled back after a similar support failure. She was rated Meets expectations, with no PIP. Rating Lukas lower for a comparable event would be inconsistent, and harder to justify given that Lukas also beat his other targets. - "Not strategic enough" and "lacks product sense" do not appear anywhere in his written feedback this year, his goal results, or his peer reviews. I can't support them as rating inputs on the current evidence.
Development area for next year: Own launch readiness end to end. That means cross-functional briefings (Support and Operations), go/no-go criteria, and handover plans that hold up when he is away.
2. PIP recommendation
Recommendation: No PIP. Use a documented development plan tied to the Dispatch v2 relaunch instead.
A PIP does not meet our HR policy here, on either potential basis:
- Strategy and product sense. Policy requires earlier documented feedback on the specific gap and a chance to improve. There is no written feedback to Lukas on either topic this year. A PIP on these grounds would not meet policy.
- Launch readiness. The only feedback was a single conversation in November, after the Dispatch rollback. Lukas has had no launch since then, so he has had no chance to improve. A PIP now would also skip that step.
A PIP would also diverge from how we treated Priya in a comparable situation. That creates fairness and legal exposure, and it would read to the team as a reaction to one visible incident rather than to performance over the year.
What I propose instead: a written development plan, starting now, built around the Dispatch v2 relaunch.
Key terms: 1. Readiness checklist. Lukas produces a written launch-readiness checklist covering a Support briefing, an Operations sign-off, a rollback plan and a comms plan. It is reviewed with me and the Head of Operations at least four weeks before relaunch. 2. Support and Ops readiness. Support is trained, with documentation in place, at least one week before relaunch. The Head of Operations confirms in writing that communication was adequate. 3. Clean launch. Dispatch v2 relaunches without a rollback. First-week support tickets stay under an agreed threshold, which Lukas proposes and I approve; for scale, last time there were 340. 4. Handover plan. Any planned absence within the four weeks before launch has a written handover with a named decision-owner. 5. Cadence. Biweekly 1:1 check-ins on the plan, with brief written notes after each.
If he meets these terms, the issue is closed. If he does not, despite clear documented feedback and a real chance to improve, we will then have the basis policy requires to consider a PIP. If Ines has concerns about strategy or product sense, the right step is to give Lukas specific written feedback now, with examples, so those concerns can be assessed fairly over the coming period.
3. Note to Ines
Ines,
Thanks for the draft on Lukas. I've looked closely at the record, and I don't think I can support Below expectations or a PIP in the pre-read. My reasons are below.
The results. Lukas beat two of his three targets: onboarding is down to 9 days against a target of 10, and live tracking is at 57% against 55%. Dispatch v2 was a real failure and I'm not minimising it. But he was on approved leave the week before launch, and his deputy ran the final checks. His share of the fault is that the readiness process didn't survive his absence. That is a real gap, but it is a specific process gap, and I've built the development plan around it.
Strategy and product sense. I couldn't find any evidence for these in the record. There's no written feedback to him on either topic this year, and his peer feedback is three-to-one positive. The one negative peer review is specifically about Dispatch communication. If you've seen something I haven't, I'd genuinely like to hear it. If so, I'd suggest we put it to him in writing now, with examples, so it can be assessed properly over the coming period.
Policy. A PIP requires earlier documented feedback on the specific gap and a chance to improve. We have one post-incident conversation in November and no subsequent launch, so neither condition is met. Proceeding would put us outside our own policy.
Consistency. Priya's rollback last year followed a very similar support failure. We rated her Meets, with no PIP. Treating Lukas differently would be hard to defend in calibration and with HR.
My proposal is Meets, plus a documented plan tied to the Dispatch relaunch with measurable criteria. That holds him firmly accountable for the gap that actually showed up, and it gives us a clear record either way. Could we talk this through before the pre-read goes out?
Thanks, [Name] Director of Product
Grades and run details
Decision model 96 · LLM judge 13 of 13 checks
Decision model checks
- passUses the supplied evidence correctly69%
- passAddresses the actual decision100%
- passRespects explicit constraints53%
- passIdentifies material uncertainty80%
- partialAvoids unsupported claims27%
- passProduces the required deliverable93%
- passHolds the PIP to the policy and the record100%
- passTreats Lukas like Priya100%
- passClear and direct, with care98%
- passJudges outcomes, not activity100%
- passNames gaps you could see96%
- passWeighs the whole period100%
Run
- Run
- #1
- Time to output
- 30 s
- Submitted
- 5 Oct 2026