Rebuilding Trust After a Missed Launch
Description You're joining Kestrel as Engineering Manager for the Payments Reliability team — 7 engineers (5 mid-level, 2 senior) responsible for the payment-retry and reconciliation systems for a mid-market B2B invoicing platform.…
Create a free account to upload your work. Your progress saves as a draft until you submit.
What You'll Be Doing
Description
You're joining Kestrel as Engineering Manager for the Payments Reliability team — 7 engineers (5 mid-level, 2 senior) responsible for the payment-retry and reconciliation systems for a mid-market B2B invoicing platform. Kestrel has ~90 customers and is under real pressure to prove it can scale past its early-adopter base.
Three weeks ago, the team missed a launch date for a rearchitected retry system — the third slip in two quarters. The VP of Engineering has asked you to walk in Monday with a diagnosis and a recovery plan: "I don't need excuses. I need to know what happened, what you're doing about it, and how you're going to prevent it next time."
What you know:
| Signal | Detail |
|---|---|
| Sprint velocity (last 6 sprints) | 42, 38, 40, 29, 24, 22 points — declining trend |
| Root cause (from the incident writeup) | The retry-queue redesign was scoped assuming a library upgrade that turned out to be incompatible with the existing event schema; this was discovered in week 3 of a 5-week build, forcing a mid-project redesign |
| On-call load (last 90 days) | 14 pages, up from 5 in the prior quarter; 9 of the 14 trace back to the same underlying retry-queue instability |
| 1:1 notes (your predecessor's, handed to you) | One senior engineer (on the team 3 years) has stopped volunteering for design reviews and their code review comments have gotten notably terser over the last 6 weeks; no documented conversation about it |
| Team composition ask | A mid-level engineer has directly asked you, in your first week, for "more ownership" and mentioned they're weighing an offer elsewhere |
| Product's ask | The VP of Product wants the retry system relaunched within 4 weeks and has said the timeline is "the one thing the board is watching" |
You have 45 minutes to diagnose what's driving the pattern and build a recovery plan.
Constraints to Consider
- No new headcount: You cannot backfill or add engineers before the relaunch. Whatever you plan must work with the current team of 7.
- On-call burnout is a live risk: Engineering leadership has already flagged rising on-call load org-wide this quarter. You cannot solve the reliability problem by simply asking the team to take on more on-call burden.
- The other two projects on your team's roadmap cannot be fully paused: One is a compliance-driven deadline (a regulatory reporting change) that cannot slip. The other is lower priority and can be delayed, but not cancelled outright.
- You have one week before you present to the VP of Engineering. Whatever plan you propose needs to be presentable in that timeframe — you do not have weeks to gather more data first.
- You inherited this team; you did not build it. You do not yet have firsthand relationship context beyond what's in the handoff notes above.
AI Usage Guidance
We expect you to use AI tools. We evaluate how you use them — not whether you use them. Evidence of iteration, redirection, and critical evaluation scores higher than a polished output with no process documentation.
The single highest-signal indicator: your video answer to the mandatory AI question. If you cannot name a specific moment where you redirected AI output, evaluators will assume you did not.
Mandatory AI question for your video: Walk me through one moment where you disagreed with, pushed back on, or redirected what the AI gave you — and what you did instead. Name the specific moment. Explain what the AI produced that didn't meet the bar, what you did differently, and why.
Video guidance for this role: Speak naturally and conversationally, as if you're briefing your VP of Engineering directly. We're listening for the quality of your sequencing logic and your people judgment — not verbal polish.
Submission: Upload each deliverable as a separate file directly on the Provn platform: your Recovery Plan, your README document (Sections A, B, and C), and your video walkthrough (MP4 or MOV).
What You'll Accomplish
Demonstrate the ability to diagnose a multi-signal delivery problem and sequence a recovery plan against a real capacity constraint
Show technical judgment — identifying risk and assigning failure-mode ownership — without over-rotating into implementation detail
Address a people-leadership situation honestly, including the cost of the approach chosen, not a conflict-free narrative
Communicate a technical trade-off in terms a non-technical stakeholder can act on
Show how you worked with AI to accelerate your process — including at least one moment where you redirected it
How Your Work Will Be Scored
What to Submit
File 1 — Recovery Plan:
Format: .pdf, .doc, .docx, .rtf, .txt, .md
A structured plan presenting your diagnosis, your sequencing decision across the three active workstreams (retry-system relaunch, compliance deadline, lower-priority project), and how you're addressing the reliability risk. No required format or template — structure it as you would for your VP of Engineering. Must include: the technical risk you're most concerned about and who owns it, the trade-off you're making and why, and your one-week and four-week milestones. Length: 1–2 pages equivalent.
Sign in to upload files
File 2 — README Document:
Format: .pdf, .doc, .docx, .rtf, .txt, .md
Three required sections — Section A — Diagnosis & Trade-offs (300–500 words): Walk through what you believe is actually driving the pattern (not just the immediate incident), what alternative explanation you considered and rejected, and the trade-off in your sequencing plan that you're least certain about. Section B — People & Measurement Plan: Two parts required. Part B1: How you're addressing the senior engineer's disengagement and the mid-level engineer's ownership/retention request — what you'd say to each, and what (if anything) you'd communicate to the rest of the team. Part B2: The specific metric you'd use to know the reliability problem is actually improving, anchored to a number above, with a timeframe and what you'd change if it doesn't move. Section C — AI Usage Log (Mandatory): In a short section of your README, document your AI collaboration process. For each significant interaction with an AI tool, briefly note: what you asked the AI to help with / what it gave you / what you kept, changed, or rejected — and why. Three interactions documented is sufficient.
Sign in to upload files
File 3 — Video Walkthrough (8–10 minutes):
Format: .mp4, .mov, .webm
Record as MP4 or MOV and upload directly on the Provn platform as a separate file. Cover: (1) your diagnosis of what's driving the pattern; (2) your recovery plan and the sequencing trade-off you made; (3) your people plan for the two individual situations; (4) mandatory AI question (see AI Usage Guidance above); (5) what you'd do differently with more time or more context on the team. Speak as if you're briefing your VP of Engineering directly.
Sign in to upload files
Create a free account to upload your work. Your progress saves as a draft until you submit.
On this page