Retrospective

A structured look back at a period of work that surfaces what went well, what did not, and what the team will change.

Retrospective

A retrospective is a structured look back at a completed period of work - a sprint, a project, or a quarter - to surface what went well, what did not, and what the team will change. Its purpose is improvement, not blame, and it runs on a regular cadence regardless of whether anything went wrong. The retrospective examines the whole working process and ends in concrete action items with named owners.

Unlike a postmortem, which is triggered by a specific failure or incident and drives to a systemic root cause using a time-stamped timeline and a severity rating, a retrospective covers the full arc of a working period. No single event needs to have occurred; the format works across ordinary sprints, smooth quarters, and difficult ones alike.

The standard retrospective structure organizes observations into three questions: What Went Well (practices to protect or repeat), What Did Not Go Well (friction, blockers, waste), and What Will We Change (specific, owned commitments for the next period). Some teams use named exercises - Start/Stop/Continue or the 4Ls - that map to the same three questions under different labels.

The retrospective earns its keep not in the meeting itself but in the action items that follow. A retrospective that surfaces problems without producing owned commitments is cathartic venting, not improvement. The change column is the product.

Canonical template

# Retrospective: [Period] - [Team or Project]

## Date
[Date held]

## What Went Well
- [practice, decision, or behavior worth repeating]

## What Did Not Go Well
- [friction, blocker, or waste that cost the team]

## What Will We Change
- [ ] [Specific change] - Owner: [person] - By: [next retro / date]

## Notes
[Anything that does not fit the three columns but the team needs to remember]

When to use

At the end of every sprint, iteration, or regular working period; after a project or milestone to capture what to carry forward and what to leave behind; when recurring friction or slowdowns have no shared name or owner; when the team needs a shared record of what it is committing to change; when establishing a norm of open process reflection with a new or growing team.

When not to use

When a specific incident or failure needs investigation - use a postmortem that drives to root cause and quantifies impact; when the goal is to document a decision and its rationale for future readers; when the team has not yet completed a working period to reflect on.

Pairs well with

coach, operator, candid, encouraging, decision-log

Often confused with

postmortem: A postmortem is a structured account of a failure, near-miss, or significant service degradation - triggered by a specific incident, not by the passage of time. It uses a precise, time-stamped timeline to reconstruct what happened and when, drives the analysis to the systemic root cause rather than stopping at the proximate trigger, and quantifies blast radius with an impact section. A retrospective, by contrast, runs on a regular cadence and examines the whole working period; no incident needs to have occurred. When a specific failure needs dedicated root-cause investigation and owned remediation commitments, a postmortem is the right format.

Tells

• Three-question structure: What Went Well, What Did Not Go Well, What Will We Change
• Covers a whole working period rather than a single event or incident
• Runs on a fixed cadence regardless of whether anything went wrong
• Action items in the change column carry a named owner and a target deadline
• Participation is collective - observations represent the whole team, not one author
• Forward-looking frame: the output is a commitment list, not a verdict or audit

Anti-patterns

• Naming individuals in What Did Not Go Well instead of the practices or processes that broke - The improvement mandate collapses when people feel they are on trial; the column exists to name systemic and process failures, not personal fault.
• Collecting action items without assigning a named owner and a target date - An unowned action item is a wish; without a name and a deadline, it reappears unchanged in the next retrospective.
• Running the retrospective format when a specific incident has occurred and needs dedicated investigation - A postmortem is triggered by a specific failure or near-miss and uses a time-stamped timeline to reconstruct the sequence of events, driving to a systemic root cause; a retrospective covers the full working period and cannot substitute for that focused causal analysis.
• Skipping What Went Well because the period was difficult - The went-well column identifies practices to protect and repeat; omitting it produces a document that only names problems and gives the team no anchor for what is working.

Failure modes

• Psychological-safety norm tips into conflict-avoidance - the blameless stance gets pushed so far that the What Did Not Go Well column fills with trivial inconveniences while real friction goes unspoken - Distinguish blame from candor: blame attributes failure to an individual; candor names the practice, decision, or system that broke. A column full of trivial items signals the format has tipped into false safety.
• Commitment-to-change tips into an aspirational backlog - the change column accumulates more items than the team can execute, items roll forward indefinitely, and the format loses credibility - Cap the change list to what can realistically ship before the next session; treat a recurring item as an escalation rather than a re-add; close items before opening new ones.

Instruction

Write as a team retrospective. Use the three-question structure: What Went Well, What Did Not
Go Well, and What Will We Change. In What Went Well: name specific practices, decisions, or
behaviors worth repeating - not vague praise. In What Did Not Go Well: name the process,
practice, or system that created friction, not individuals. In What Will We Change: every item
must have a named owner and a target date or next-retro deadline; unowned items do not count.
Keep the frame improvement-focused, not verdict-focused; the purpose is the change column, and
everything else exists to fill it well. Do not let the change list grow beyond what the team
can realistically execute before the next session.

Template

See the Retrospective template.

Related

Pairs well with

Coach, Operator, Candid, Encouraging, Decision Log

Avoid with

Reverent, Urgent, Skeptical

Often confused with

Postmortem

Examples

Whether the team should move to async-first standups

Retrospective: 30-Day Async Standup Trial - Engineering Team

Date

Day 30 of the 30-day async standup trial

What Went Well

• Timezone equity, realized. IST-based engineers participated every weekday across the final two weeks of the trial - a first for this team. The change was structural, not motivational: removing the 9:30pm IST constraint worked.
• Blocker resolution improved. Median time from @mention to first substantive reply settled at 18 minutes by Week 2. Under the sync model, blockers raised at 9am Pacific routinely waited until afternoon for a real conversation.
• Searchable, persistent record. The three incidents per quarter where engineers duplicated work on already-solved problems did not recur during the trial. Status is now findable in Slack history.
• Posting rate trended up week over week. Week 1: 78 percent on-time. Week 2: 85.5 percent. The three-field template became a daily habit faster than expected.
• Signal-to-time ratio improved. The 14-minute sync meeting produced roughly 4 minutes of actionable signal. The async channel delivers equivalent signal without the 10 minutes of passive listening.

What Did Not Go Well

• Post length discipline eroded by Week 2. Three engineers were writing 200-plus word posts. The format is designed to be skimmed in under 60 seconds per teammate; long posts reduce reader engagement and undercut the signal-density goal.
• On-call triage load exceeded the target. The on-call engineer spent roughly 25 minutes per morning on channel triage against a 10-minute target. Blockers are surfacing earlier and louder than they did in sync - which is a net positive - but the review process did not scale with the volume.
• Thursday session attendance varied. The 60-minute session at 8am Pacific (8:30pm IST) was harder for IST-based engineers than anticipated. Two sessions had incomplete participation, and a third was cancelled late.
• Daily social contact was not replaced. Several engineers noted in end-of-trial 1:1s that they missed the brief social warmth at the top of the sync standup. The Thursday session offered scheduled contact but did not fully substitute for daily shared presence.

What Will We Change

• Update the #team-standup pinned message to include two exemplar posts demonstrating the three-bullet ceiling. Owner: Engineering manager. By: Thursday this week.
• Add a post-length note to the /standup Slack shortcut workflow description. Owner: On-call rotation lead. By: next Thursday.
• Review on-call triage load and propose whether the role should be time-boxed or split between two engineers. Owner: Engineering manager. By: Day 37.
• Assess Thursday session attendance for two more sessions. If IST participation falls below 3 of 4, evaluate an alternate time or format and bring a proposal to the team. Owner: Engineering manager. By: next retrospective.

Notes

The trial met its headline goal: the IST attendance gap closed and has stayed closed. The team has voted to extend the async format permanently, with the four change items above as conditions of adoption. The synchronous Thursday session continues on a separate 30-day clock; it will be evaluated on its own terms at the next retrospective.

Designing a sustainable morning routine

Retrospective: Month 1 - Morning Routine Experiment

Date

2026-06-14 (held as scheduled in ADR-001 review clause; accountability partner joined by async voice note)

What Went Well

• Phone-in-the-kitchen rule held. Phone deferred to step 4 on 28 of 30 mornings (93 percent). The behavior change came almost entirely from removing the decision point. Device out of reach meant the temptation did not arise.

• Water and light as the first two steps. The ordering held on every completed morning. Starting with water and then 10 minutes of natural light produced a noticeably different first hour compared to skipping or reordering them.

• Paper planning stick rate. Every completed morning included the paper planning step. Writing the top-three list by hand consistently produced a cleaner handoff to the 9am workday start than previous screen-based tools did.

• The 30-day frame. Previous attempts at 90 days collapsed by day 11. Anchoring to 30 days with a scheduled review reduced the psychological weight of the commitment. This framing was the right call.

• Full protocol completion: 23 of 30 mornings (76.7 percent) - above the 70 percent threshold set in ADR-001 as the condition for independent continuation.

What Did Not Go Well

• Tuesday morning completion rate. Three of four unexplained missed wake targets fell on Tuesdays. Monday’s load consistently spilled into Tuesday morning. The pattern had no owner and no mitigation when the protocol launched.

• No travel variant. The protocol assumed a familiar home environment. Two of three travel days were attempted under the original protocol structure, and both failed. Improvising a partial version without a written travel variant did not build the habit.

• Weekend ambiguity. The protocol did not decide weekends. Running the same protocol on weekends consumed buffer days without a deliberate rationale. After 30 days the verdict remains genuinely unclear.

• Wake time consistency. Target of 6:15 held on 19 of 30 days (63 percent). Travel (3 days), illness (4 days), and unexplained drift (4 days) each eroded it. The drift cluster has no identified cause yet.

• Spouse conversation deferred. ADR-001 named potential family friction as a known negative consequence. I assumed silent tolerance rather than confirming it. That conversation should have happened in week 1.

What Will We Change

• Write a travel variant of the protocol (minimum viable: water plus planning, no light or movement requirement) - Owner: Me - By: 2026-06-21, before the next overnight trip
• Add a Sunday-evening 15-minute planning session to front-load Monday’s accumulated load - Owner: Me - By: 2026-06-21 (first Sunday of Month 2)
• Write an explicit weekend rule (same as weekdays / relaxed version / off) and commit it to the protocol file - Owner: Me - By: 2026-06-15
• Have one direct conversation with spouse to confirm whether the silent first-hour norm is actually working for the family - Owner: Me - By: 2026-06-18

Notes

ADR-001 included a “one-month commitment, then revisit” clause. Month 2 continues the protocol as designed, with the four changes above folded in. The accountability partner’s async note agreed on all four items; no escalation needed.

The 70 percent completion threshold survived intact. Do not raise the bar to 80 percent before Month 2 is in hand. Raising a threshold that was just barely cleared is a way of manufacturing a problem that does not exist.

Choosing Postgres vs DynamoDB for a new service

Retrospective: Sprint ending 2026-05-16 - Notification Service

Date

2026-05-16

Participants

Ana Rivera, Marcus, Priya, Jordan, Sam

What Went Well

• Time-boxed spike produced usable evidence. The DynamoDB spike (experiments/notify-ddb/) was completed within its allocated window and gave the architecture meeting concrete findings (access-pattern fit confirmed; operational cost documented) rather than an inconclusive result.

• The operational capacity framing gave the meeting a shared anchor. Framing the decision around what a 4-person on-call rotation can realistically absorb turned “which DB is technically better” into a bounded, team-specific question. The Wednesday session reached a recommendation in one meeting.

• Marcus and Ana aligned before the lock, not at it. Rather than leaving the DynamoDB vs. Postgres tension for Priya to resolve, Marcus and Ana worked to a single recommendation overnight. The 11am sync closed cleanly on the first pass.

• ADR-0023 came out of the architecture meeting as a draft, not as a follow-up task. Having the ADR structure in the room meant the Wednesday session ended with a document rather than a verbal outcome that had to be transcribed later.

What Did Not Go Well

• Verbal sign-offs did not convert to written confirmations quickly enough. Marcus’s written agreement on the 5M events/day revisit threshold was still pending EOD Thursday, a full day after Wednesday’s meeting. A verbal agreement is not a closed action item.

• Evaluation criteria were defined informally and after the spike was already under way. We ran the DynamoDB spike, then articulated the decision criteria (access-pattern fit, operational cost, reversibility) in the architecture meeting itself. Defining criteria before the spike would have shortened the meeting and reduced the risk of criteria shifting mid-evaluation.

• The Slack-partnership deal is a forcing function the team cannot see. If the deal closes earlier than the 12-month projection, we hit the Postgres revisit window ahead of schedule. Nobody on the team tracks deal timing, which meant this risk sat unowned until the retro surfaced it.

What Will We Change

• For the next multi-option datastore evaluation: write a one-page decision matrix (criteria, weights, candidates) and share it before the spike begins - Owner: Ana - By: next architecture review kickoff
• Close verbal sign-offs from architecture meetings in writing on the same day, not the following day - Owner: decision driver (Ana for any ADR-0023 follow-ups) - By: immediate, starting now
• Priya sends a monthly one-liner to #notify-arch on Slack-partnership deal status so the team can adjust the 5M events/day revisit horizon if the timeline shifts - Owner: Priya - By: 2026-06-01

Notes

• ADR-0023 is accepted as of the 2026-05-16 11am sync. The 5M events/day sustained threshold is the team’s primary leading indicator for revisiting the Postgres path.
• Sprint planning ran at 2pm the same day and locked the first two weeks of build work. Retrospective action items carry into the next sprint’s tracking board.
• The three action items above are the full commitment list; no additional items were added. Jordan and Sam carry no retro action items - their upcoming deliverables (dashboard metrics by 2026-05-22, schema spec by 2026-05-20) are tracked in sprint planning, not here.

Telling stakeholders a committed feature is being cut this quarter

Retrospective: Q3 2026 - Insights / Platform Team

Date

September 30, 2026

What Went Well

• The billing-system migration was prioritized correctly. Completing it before year-end removes a hard regulatory dependency, and the team executed without production incidents.
• The decision to ship a CSV export rather than release a half-built dashboard was sound. Customers get access to their underlying data before the quarter closes, and the team avoids creating a credibility hole going into Q1.
• Outreach to the four key accounts was proactive. Individual calls were offered alongside written notice, and communication went out before the quarter closed rather than after.
• ADR-0027 gave the deferral decision a permanent, searchable record. Anyone who needs the reasoning later can find it without asking.

What Did Not Go Well

• The billing migration scope was not visible at Q3 planning. The work was non-optional, but the estimate was wrong early enough that it set a false expectation with sales and enterprise customers before anyone had a chance to course-correct.
• The sales-to-engineering loop moved too slowly. Sales positioned Insights as a closing point for enterprise accounts before engineering had validated the Q3 capacity plan. There was no checkpoint where a qualified estimate could have surfaced the risk before customers received a delivery date.
• Customers were given a quarter label rather than a target date, which left the four key accounts without a concrete anchor when the deferral notice arrived. The news landed abruptly for accounts that had planned around the original commitment.
• The team carried two major workstreams into Q3 without a formal prioritization decision. When the trade-off became unavoidable, it required an escalation that took time the team did not have.

What Will We Change

• Add an engineering capacity review gate to the pre-commitment process for customer-facing delivery dates. No date leaves the team without a named engineer signing off on feasibility. Owner: Maya Chen. By: Q4 planning kickoff (October 6, 2026).
• Define a single-priority rule for the team: when two major workstreams compete for capacity in the same quarter, one is paused rather than both slowed. Codify this in the team operating agreement. Owner: Maya Chen + Dario Reyes. By: October 13, 2026.
• Introduce a mid-quarter scope check at week four of each quarter. If any workstream shows a twenty-percent-or-greater schedule slip, the product lead and engineering lead convene within forty-eight hours to make an explicit trade-off decision, not absorb the slip quietly. Owner: Dario Reyes. By: week five of Q4 (November 3, 2026).
• For the next customer delivery commitment, include a specific target date alongside the quarter label, and state one named contingency risk in writing at the time of commitment. Owner: Jordan Park + Maya Chen. By: next outbound commitment (Q1 2027 Insights, targeting March 13, 2027).

Notes

The Q1 2027 Insights target (March 13, 2027) is directional and not yet backed by a closed capacity plan. Engineering design begins October 6 and the design document is the first real signal on whether March 13 is achievable. If scope concerns surface before the end of October, Maya owns raising them with leadership and key accounts before the expectation hardens.

Jordan Park should collect feedback from the four key accounts by October 14 on whether the CSV export (released September 26) is meeting their interim data needs. That feedback should inform whether any Q1 Insights scope needs to be reordered before the design document closes.

Getting a new engineer productive in their first two weeks

Retrospective: Priya Onboarding - Jun 22 to Jul 3

Date

Fri Jul 3

What Went Well

• Pre-scoping the first change before week one started meant Priya had a real task waiting in week two. The team made that decision without her; she did not have to wait for us to figure it out after she arrived.
• The access and tooling checklist gave day-one friction a named owner. When the setup doc turned out to be missing the VPN cert step, Priya caught it immediately because she was following the doc step-by-step. Mei patched the doc the same day. Nobody spent time in a silent gap wondering who was responsible.
• Guided walkthroughs front-loaded the architecture before Priya encountered it under pressure. By Day 3 she was navigating the three services she will own without hand-holding, including locating the test harness and naming conventions on her own.
• Pulling Priya into the Thursday design session as a co-driver rather than an observer produced an immediate return: she caught an edge case the team had missed. It also established her as a contributor before her first PR landed.
• Belonging was tracked alongside functional milestones, not assumed from them. Three async threads opened between Priya and teammates outside the formal protocol. That signal came from how the two weeks were structured, not from a dedicated “be welcoming” checklist item.

What Did Not Go Well

• The staging access provisioning request went in on Jun 23 and sat in the infra queue for the remainder of the two weeks. The on-call alert drill had to be deferred because Priya did not have her own credentials. The team covered with a shared credential, but that was a workaround that masked the gap rather than fixing it.
• The setup doc gap (missing VPN cert step) was caught because Priya followed the doc precisely and got a hard error. A less thorough new hire would have self-debugged without surfacing it. The doc was fixed, but the review process did not catch it before her first day.
• Buddy capacity was absorbed but not planned for. The sprint carried standard load through both weeks. Arjun covered the week-two deficit informally. The cost was real and invisible to velocity tracking; it did not appear anywhere until this retro.
• The belonging vs. function question was flagged as a risk in the week-one status report but not operationalized until today. A single question at the end of week one would have been more actionable than a watch-list risk note.

What Will We Change

• Move the staging access provisioning request to the week before a new hire’s start date, not day one or day two. Add this step to the pre-boarding checklist. Owner: Mei - By: pre-boarding prep for next hire (target start Aug 4)
• Run a dry-run of the setup doc against a clean machine before each new hire’s first day. Assign to whoever holds the buddy role for that cycle. Owner: Arjun (for next cycle) - By: one week before next hire’s start date
• Add buddy capacity to sprint planning as a standing flag: 30% reduction for the primary buddy in week one, 15% in week two. This belongs in the sprint planning template, not the onboarding protocol. Owner: Mei - By: next sprint planning session (Jul 7)
• Add a ten-minute belonging check-in at the end of week one with one explicit prompt: “What has felt off this week that you have not said out loud yet?” Log the answer even when the answer is nothing. Owner: Mei - By: protocol update Jul 10

Notes

Priya’s first change was merged on Jul 3 before EOD. She drove the full deploy cycle. The formal onboarding window closes today with no open blockers.

The on-call alert drill was deferred, not cancelled. Rescheduled target: Jul 9, contingent on staging access resolving by Jul 7. The infra escalation is active; Mei owns the follow-up.

Priya is on the on-call rotation calendar starting week five. The buddy relationship with Arjun is expected to continue informally; the team should treat that as a feature of the protocol, not drift from it.

Writing to thank a mentor who shaped your career

Retrospective: March 2016 - April 2017 - Alderton Platform Migration

Written to Dana Forsythe, ten years after the quarter that changed my working life.

Date

June 2026 (original period: March 2016 - April 2017)

What Went Well

• You nominated me to lead the Alderton platform migration before I told you I was ready; the timing was deliberate and it was correct
• I was given real accountability rather than a rehearsal for accountability; that distinction compounded across the years that followed
• You stayed close through the first several months without becoming the decision-maker; you answered questions without substituting your judgment for mine
• When I offered the work back in a moment of genuine panic around month four, you declined and redirected me toward the answer rather than providing it
• The project shipped; I owned the outcome; the organization knew it
• The pattern of working under real stakes rather than simulated ones became a reference point I have returned to in every significant project since

What Did Not Go Well

• I reached up to you for check-ins too frequently in the first two months instead of sitting with uncertainty long enough to work through it myself; that habit cost you time you were not billing anywhere
• I did not recognize in the moment how much reputational exposure you were absorbing quietly on my behalf; I was too focused on my own uncertainty to track what was at risk for you
• I never told you what the project produced in my working life; I intended to, and a decade passed instead; that omission was not modesty - it was the avoidance of a debt I did not know how to name

What Will We Change

• In February 2026: put Priya Osei forward to lead the Cassava data-pipeline rebuild before she felt ready, using the same pattern you used with me - Owner: Sable Marchetti - Done (Priya is four weeks ahead of schedule as of this writing)
• In March - April 2026: attend the first two review sessions; stay close without taking over; correct Priya privately, after the meeting, not during - Owner: Sable Marchetti - Done
• Send this retrospective to Dana before this quarter closes - Owner: Sable Marchetti - By: June 30, 2026

Notes

A retrospective runs on a regular cadence. This one ran on a decade. That is the gap the change column above is meant to close.

Your practice, reconstructed: nominate before they feel ready; stay visible without becoming the fallback; refuse to accept the work back when they offer it in a moment of panic. I did not have a name for what you were doing while you were doing it. I have one now because last month I watched myself replicate it with Priya, and in the middle of that I recognized where I had learned every step.

The Went Well column is all downstream of the decision you made in March 2016. The Did Not Go Well column is mostly on me. The change column has one open item. It is this letter.

Reflecting on keeping a discipline of rest

Retrospective: Weeks 11-14 - Weekly Rest Practice

Date

June 21, 2026

What Went Well

• The practice held for three consecutive weeks - the longest unbroken stretch since restarting eleven months ago. The structure survived two weeks where it would previously have collapsed under a deadline or a compulsion to stay current.
• The phone-away window extended from four hours to ten hours over the course of the period. The extension happened without forcing; the window grew because the previous boundary proved survivable.
• One work message sat unanswered from Sunday afternoon through Monday morning without a reply being drafted in my head. This is the first time the practice produced that quality of non-engagement, and it is worth naming as a distinct behavior rather than a side effect of tiredness.
• The Sunday productivity review - the habit of mentally scoring what the week produced - did not run for the first time in week 14. The habit is old; not running it once is a meaningful signal even if it runs again next week.
• Two problems that had been circling for days resolved more cleanly on Monday than expected. The connection to rest is a hypothesis, not a proof, but the pattern is worth recording.

What Did Not Go Well

• The productivity accounting habit ran in the background during rest on most days in this period. Even on weeks when the full time was held, a background process tallied whether the rest was good enough to justify the cost. This is not a personal failure; it is a habit shaped over years of measuring days by output. But it is undermining the rest from inside the practice.
• The phone-away window begins too late. Saturday at 8 p.m. leaves Friday evening and most of Saturday morning inside work-mode; the transition time that should belong to rest is still spent in the same state the practice is trying to interrupt.
• Sunday evening re-entry is happening too fast. The first fifteen minutes after the phone returns involve scanning everything - notifications, inbox, ticket tracker - and whatever steadiness accumulated during the day compresses before the new week starts.

What Will We Change

• Move phone-away window to begin Friday at sundown and hold through Sunday evening. Owner: Self. By: June 28, 2026.
• Write a brief pre-rest log before each rest period - what I expect to feel and what I am afraid of missing - to compare against what actually happened. Owner: Self. By: June 28, 2026 (next rest day).
• Name the one check most likely to be rationalized as necessary (inbox, ticket tracker, or notifications feed) and write the rule before the moment arrives. Owner: Self. By: July 5, 2026.
• Cap Sunday evening re-entry at thirty minutes: triage only, no replies. Owner: Self. By: June 28, 2026 (next rest day).

Notes

The productivity accounting habit has been named before and it is named again here. Naming it twice has not dissolved it. The working hypothesis is that it resolves as evidence accumulates over time rather than through direct attack; the evidence this period is that two problems cleared on Monday that had been stuck for days. The change column above does not include a direct fix for this pattern because no direct fix is available. The closest substitute for a mitigation is keeping the practice long enough for the evidence base to grow.

The change column is four items. That is at the upper limit of what this practice can realistically absorb before the next review. If any item does not ship, it carries forward as an escalation rather than a re-add.

Marking a long-serving colleague's departure

Retrospective: Howard Thayer Transition - Crestfield Group Operations

Date

June 27, 2026

What Went Well

• Runbook documentation completed in two structured sessions (May and June) with Dana Reyes and Marcus Okonkwo. The final document covers vendor escalation paths, four utility contacts Howard maintained personally, and the informal decision sequences the team had relied on for years.
• System access and vendor credentials transferred to three named successors by June 20, ahead of Howard’s final day. No hard account dependencies remain.
• All-hands send-off on June 25 drew 40 in-person attendees and 18 remote and was recorded for the regional site. The event was brief, on-time, and felt like Howard.
• Mentee archive compiled with contributions from Priya Sandhu, Ben Holter, and four others. The archive documents specific practices rather than general praise and exists as a reference, not a tribute.
• The team named the gaps honestly rather than treating the posted backfill as a solution. Leadership entered this transition with a realistic picture of what is and is not transferable.

What Did Not Go Well

• The documentation effort started too late in Howard’s tenure. Two sessions at the end of a twenty-six-year career captured the outline, not the substance. The vendor contacts that existed only in Howard’s personal memory are now transferred; the judgment behind why he maintained them that way is not.
• The informal mentoring function had no named owner, no place in the org structure, and no formal acknowledgment until departure planning surfaced the gap. The team benefited from it for years without treating it as something the organization needed to protect.
• Several pieces of institutional context turned out to exist in Howard’s memory alone - not because he withheld them, but because no one asked, and no system prompted anyone to ask.
• The official directory still listed Howard’s extension on his final day. No offboarding process covered that cleanup, and it fell to individual effort after the fact.

What Will We Change

• Stand up quarterly knowledge capture sessions for the two highest-tenure remaining senior ICs, using the same structured format as the Howard sessions. Owner: Carolyn Marsh. By: September 30, 2026.
• Close the Q3 stress test: complete at least one incident response without escalating to Howard, relying only on the runbook and transferred contacts. Owner: Dana Reyes. By: September 30, 2026.
• Complete gap analysis of the knowledge wiki against the six most common incident types Howard handled. Owner: Marcus Okonkwo. By: August 15, 2026.
• Add informal mentoring as an explicit expectation in the senior IC role description - not a title, an expectation, and not retroactive. Owner: Carolyn Marsh. By: Q4 2026 role review cycle.
• Six-month check-in with Howard’s mentees to surface where the absence is felt and respond to the actual need rather than the anticipated one. Owner: Carolyn Marsh. By: December 2026.
• Add directory deactivation and system access cleanup to the standard offboarding checklist, with a 72-hour deadline from final day. Owner: IT Operations. By: July 11, 2026.

Notes

This retrospective covers the transition period (May 15 - June 27, 2026), not Howard’s full tenure. His departure made visible a set of process gaps that predated his retirement announcement; several actions in the change column are responses to conditions the team had accepted for years.

The test of this retrospective is not June 27. It is Q3, when the first real incident arrives and Howard is not available.

Marking the team shipping a hard, long project

Retrospective: Project Halyard - Checkout Rebuild (Full Project Arc)

Date

June 30, 2026

What Went Well

• Parallel-run architecture justified its cost. Running both checkout flows simultaneously for fourteen months was operationally expensive, but it paid off directly: the February and April near-misses were caught and fully resolved before any user saw them. The rollback path was not theoretical.
• Both slip decisions were called correctly and held. Dani Rowe called the hold on the March window; Priya Vasquez called the hold on the second. Both were made under real schedule pressure. The February near-miss (Marcus Teel’s cart-state mismatch in multi-item orders under split payment) and the April near-miss (Jordan Osei’s payment-callback race condition under load) would have reached production if either call had bent to that pressure.
• Shadow-comparison tooling surfaced issues the automated suite missed. Dom Ferreira’s shadow-mode infrastructure made the first near-miss visible during the Phase 3 ramp. The test suite did not catch it on its own; the comparison layer did.
• The final cutover held through peak load. June 13 went cleanly. The June 13-14 peak weekend ran without latency spikes, rollback triggers, or customer impact. Cart completion rate held at the modeled target.
• Yuki Tanaka held the “ship when it is ready” line with stakeholders through both slips. The team never had to choose between shipping safely and shipping on a date. That protection required sustained effort across fourteen months and was not free to maintain.
• Sam Wickfield held the regression bar at the end when the pressure was at its highest. The June 9 freeze call was contested. It was correct, and the cutover was clean because of it.

What Did Not Go Well

• Automated test coverage did not surface either near-miss. Both the February and April issues were found through manual inspection - one via shadow-mode comparison, one during a live dress rehearsal. Payment-critical paths required human attention to validate; the test suite alone was not sufficient.
• On-call burden concentrated on a small set of engineers for the full 14-month parallel-track period. Maintaining two live checkout systems required sustained coverage that did not rotate evenly across the team. The people who carried the most operational load had no meaningful relief window.
• The work was largely invisible to the rest of the organization. No shippable features came out of the migration period. Communicating progress to non-engineering stakeholders required repeated framing, and protecting the team’s capacity during the final push was harder than it should have been.
• Decision criteria for calling a launch hold were not documented in advance. Both slip decisions were made well, but they required individuals to absorb pressure without a shared frame for what justified a hold. A new team inheriting this architecture would have to reconstruct that frame under identical pressure.

What Will We Change

• Define and assign explicit on-call rotation ownership for any future parallel-track project before the parallel run begins, not after it is under way. - Owner: Priya Vasquez - By: before next parallel-track kick-off
• Write a test coverage standard for payment-critical paths that specifies which scenarios require manual rehearsal in addition to automated tests. Ground the standard in the February and April near-miss scenarios as the minimum required cases. - Owner: Marcus Teel - By: July 31, 2026
• Document the decision criteria for calling a launch hold - what evidence is sufficient, who has authority, and what the escalation path looks like - so the next team does not reconstruct this under pressure. - Owner: Dani Rowe - By: July 7, 2026 (alongside the operational runbook handoff)
• Build a progress-communication template for long-running platform rebuilds that translates traffic-migration percentages into terms stakeholders outside engineering can track. - Owner: Yuki Tanaka - By: July 14, 2026

Notes

This retrospective covers the full project arc: ADR-0017 acceptance (February 2025) through final cutover (June 13, 2026) and the first post-launch peak weekend (June 13-14, 2026). It is not a sprint retro. The working period is 14 months, and the format was adapted accordingly, as noted in the June 20 close-out status report.

The cart-abandonment baseline report from Mia Chen’s analytics team is due July 7. Post-launch outcome data will be a separate artifact; clean attribution requires 21 days of post-cutover data without the parallel-period overlap. That document is not part of this retrospective.

The two near-miss postmortems are archived separately and carry more detail than the mentions here. Anyone using this retrospective for lessons-learned should read those documents alongside it.

Arguing a public position on return-to-office

Retrospective: Work Location Policy Initiative - Policy Working Group

Date

July 7, 2026

What Went Well

• The decision to frame the anchor-day model as a deliberate choice rather than a compromise held throughout the brief and survived leadership review intact; grounding it in its own logic prevented the “split the difference” framing from taking hold in executive discussions.
• Both major objections (office-first and remote-only) were documented and formally responded to before the leadership session, so no objection arrived in the room that the group could not answer on paper.
• The junior-mentorship-density concern surfaced during Q&A was logged immediately as an implementation gap rather than treated as a counter-argument; this kept the brief’s main claim intact and produced a scoped addition (Manager FAQ) rather than a revision.
• Naming the anchor days concretely as Tuesday and Thursday rather than leaving them as “two days to be determined” made the policy testable from day one and made objections easier to answer because there was nothing abstract to object to.

What Did Not Go Well

• Decision authority between Facilities and HR was left unresolved until the final week of the campaign; the two workstreams ran on different timelines and were premised on different assumptions about attendance load, creating a credible blocking risk before the all-hands announcement.
• The Manager FAQ was not identified as a necessary deliverable until Q&A during the brief review period; it was scoped reactively rather than planned as a parallel track alongside the position brief from the start.
• The risk that leadership would reframe the policy as a compromise rather than a principled choice was flagged late as a communications risk to manage, rather than treated as a framing constraint to build the brief against from the outset.

What Will We Change

• Add a “confirm who owns the final call” step as the first item in the policy working group kickoff checklist, before any drafting begins. Owner: Priya - By: Before next policy initiative opens.
• Draft supporting materials (Manager FAQ, Facilities brief, HR brief) on a parallel track with the position brief, not after it closes. Owner: Priya - By: Next initiative kickoff.
• Schedule a framing-alignment session with the executive sponsor at the position brief’s midpoint, not only at the close, so that positioning language is locked before the leadership session rather than flagged as a risk inside the final brief. Owner: Priya - By: Next initiative kickoff.

Notes

The underlying disagreement about the right amount of in-person time has not been resolved by this policy; it has been given a structure and a two-day-per-week floor. Anchor days will drift if managers do not hold them. The working group’s mandate ends at endorsement; implementation accountability belongs to the people team and the management layer. A check-in retrospective at the 90-day mark is recommended to assess whether Tuesday and Thursday attendance is holding and whether the Manager FAQ has meaningfully addressed the mentorship density concern raised during the brief review.

Announcing a new product to an outside audience

Retrospective: Launch Sprint - Tidemark

Date

July 7, 2026

What Went Well

• Early-access cohort produced clean pre-launch signal. Twenty-two small teams ran the full feedback-to-roadmap loop before June 30 without filing a support request. The intake question asking each team to describe their current workflow surfaced the scatter pattern (spreadsheets, chat threads, ticket trackers) as the dominant pain point, confirming the framing we chose for the announcement.
• Problem-led announcement framing held across channels without contradiction. Press contacts who responded used our framing language back to us in their notes. No one tried to slot Tidemark into a roadmap-tool or feedback-tool category exclusively, which was the outcome we were trying to protect against.
• Launch assets were ready several days before June 30. Screenshots, the 90-second demo video, and the one-page product summary were in hand early enough for press contacts and community builders to prepare their own coverage before launch day.
• Pricing was live before the landing page launched. Prospective users could evaluate cost before committing to a signup, and no one landed on a “contact us for pricing” dead end. The free solo plan, $29/month team plan, and custom tier were all visible from day one.
• Help documentation deployed as a single step on launch day. Staging it in advance meant the team did not scramble to publish support articles after the product was already live.

What Did Not Go Well

• The sharing ask in the cohort offboarding email was buried. The email led with account-transition logistics before reaching the request for cohort members to share their experience publicly. Several who did share said they almost skipped past it. The ask itself was clear; its placement was not.
• The team had no agreed definition of a “quiet launch week.” When organic sharing moved slower than expected in the first 48 hours, the team spent time in a holding pattern. There were no documented criteria for what a quiet signal meant and what, if anything, to do about it at the 24-hour or 48-hour mark.
• The free-plan infrastructure risk had no named owner before launch. The usage threshold that would trigger a pricing review was documented in the status report, but who would pull and read the dashboard daily was not established. The monitoring setup existed; the accountability did not.

What Will We Change

• Rewrite the cohort offboarding email so the sharing ask appears in the opening paragraph, ahead of account-transition logistics. - Owner: Marisol - By: August 1, 2026 (before next cohort offboards)
• Before the next launch, write a one-page “quiet launch” protocol that defines what we will do at 24, 48, and 72 hours regardless of reach signals. Treat silence as a state with a defined response. - Owner: Marisol - By: July 21, 2026
• Assign a named dashboard owner to any future free-tier experiment before the experiment begins, not after. Add this as a checklist item to the launch-readiness template. - Owner: engineering lead (confirm in July 14 team sync) - By: July 14, 2026

Notes

The July 7 cohort feedback session revealed that several teams re-ranked items manually after receiving the automated ranking output. This may indicate the scoring logic needs either an explicit explanation of how weights are calculated or a user-facing weighting control. This finding does not belong in the launch retrospective’s change column - it is scoped and ready for first patch release planning.

A personal year-end reckoning with a difficult year

Retrospective: Year 2025 - Marcus Delgado

Date

December 2025

What Went Well

• Professional baseline held. Client work continued, deliverables shipped on schedule, and external commitments outside the Meridian initiative were met throughout the year. This is a floor to acknowledge, not a win to celebrate. Holding function when the things that made function feel worth it were in question is evidence that some practices are more durable than I gave them credit for.

• Named what went wrong without alibi. The internal retrospective in September produced a clear finding: I conflated momentum with progress on Meridian, and I kept the coalition aligned around optimism past the point where some members needed a harder truth. I named this accurately. I did not soften it into a lessons-learned bullet or attribute it solely to external circumstances.

• Stayed with the difficulty. I did not manufacture a resolution for the year or decide that either the Meridian closure or the loss of regular contact with Celeste was something I had worked through. Accurate accounting, without rounding the hard parts up to meaning, is something I did this year. That is a practice worth repeating.

What Did Not Go Well

• Missed the signals in February. There were indicators before the March closure that the primary funder’s priorities were shifting. I did not act on them. I escalated my own investment under the assumption that the effort gap was mine to close. That assumption was wrong, and I held it longer than the evidence supported.

• Closed out the Meridian coalition inadequately. Eleven people gave significant time to the initiative. When it dissolved in March, I thanked them inadequately. The written account they are owed - what happened, what the decision-making looked like from the inside, what I would do differently - still does not exist.

• Kept Celeste outside the difficulty. After the Meridian closure, I kept Celeste too far outside what I was actually going through. I told myself that was independence. It read as distance. By June the friendship had drifted in ways I had half-denied until they became undeniable. By August we had not spoken. I do not think the project collapse caused this. I also do not think the two events are unrelated.

• Avoided Theo’s message. Theo sent a message in April that I read and did not answer. The reason was not that I lacked an answer. It was that answering required naming something I was not ready to name. I let time pass as a substitute for a decision.

• Pattern of starting new things to avoid finishing difficult existing ones. The pull toward the next large effort is already present. The pattern that contributed to what went wrong this year is the same one pulling me toward beginning something new before the unfinished obligations from this one are closed.

What Will We Change

• Write the Meridian retrospective and share it directly with the coalition - Owner: Marcus - By: February
• Answer Theo’s message - Owner: Marcus - By: January
• Do not evaluate or commit to the next large project until the retrospective is drafted and Theo’s message is answered - Owner: Marcus - By: March (no earlier)
• Repair at least two under-maintained relationships before the next large effort begins - Owner: Marcus - By: March

Notes

The two losses happened in the same year and I have not always known which one I was grieving when I thought I was analyzing the other. This is worth watching in the next period. The unresolved status with Celeste is not blocked by a missing action item - it is blocked by mutual uncertainty and time. It is not on the change list because I do not yet know what I am asking myself to do. That is an honest place to leave it.