Drill 59 — The Deprecation Email

Theme: Vendors & Dependencies · Format: 20-min drill · Difficulty: intro

The story

A data vendor does everything right: six months' written notice that API v1 will be sunset on a fixed date, sent to the integration-contact address on file. That address is an alias pointing at a distribution list from two reorgs ago — delivered successfully, read by nobody. Six months later, on a random Tuesday at 9 a.m., v1 starts returning 410 Gone and production identity checks fail across every product that touches them. The vendor's support line, entirely reasonably, points at the email.

⏸ Stop here and ask the room: the vendor gave six months' notice. Where did the six months go?

Run it — facilitator script

Timing: 2 min story · 10 min questions · 3 min reveal · 5 min transfer.

Read the story aloud and pause at the ⏸. Resist the urge to move on quickly — the room needs a moment to notice that nobody in the story did anything wrong, and the outage happened anyway.

"Where do our vendors' notices actually land today, and who reads them?"

Listen for: a specific, checkable answer — a monitored team channel or shared inbox with a named owner, plus a recent example of a notice that was read and acted on. Extra credit for anyone who knows what contact address is actually on file with each vendor, as opposed to what we assume is on file.

Weak signal: "whoever set up the integration gets those" — a personal inbox, a stale alias, or a distribution list nobody can enumerate. If the room has to debate where the mail goes, the debate is the finding.

"How many of our dependencies are running on versions already announced for sunset?"

Listen for: a number — or at least the place a number would come from: a registry, a dashboard, a spreadsheet with a review cadence. The strong answer treats version currency like tech debt with a metric attached.

Weak signal: confident guesses with no source ("probably none?"), or the honest-but-alarming "we'd have to go check each one" — which means the audit that closes this story's postmortem has never been run here.

"Whose job is it to know?"

Listen for: a named owner per dependency — a person, not a team — and a standing ritual, like a quarterly registry review, where sunset status is somebody's agenda item rather than everybody's background worry.

Weak signal: diffuse ownership ("the platform team, broadly") or event-driven attention ("we look when something breaks"). That's asymmetric attention reproduced internally — the dependency matters enormously and is nobody's job.

Facilitator close: land the reveal hard — the outage isn't the real finding. The three other unread notices are.

The reveal

The postmortem's real finding isn't the outage — it's that a quick audit turns up three more dependencies quietly running on announced-deprecated versions, their notices sitting unread in the same class of stale aliases. This wasn't an event; it was the first detonation in a minefield.

Why this happens — the mechanics

For the vendor, sunsetting API (Application Programming Interface) v1 is a line item in a release plan — announced once, to the address you gave them, obligation discharged. For you, it's every product that touches identity checks. That's the asymmetric-attention trap at its purest: the notice matters enormously to exactly one side of the relationship, and it's not the side that sent it. The vendor's email is a compliance artifact; reading it was always your problem.

Contact records rot faster than anyone expects because they're written once, at procurement, by someone who may have reorged away twice since. Email delivery keeps succeeding technically — the alias resolves, the message lands — while the human route behind it decays silently. Deliverability is not readership, but nothing in the system distinguishes the two: there is no bounce, no error, no signal that six months of warning went into a void.

And deprecation itself is a non-event until the sunset date. Nothing degrades during the notice period — no latency creep, no error-rate wobble, nothing that competes for attention against live incidents. The only alarm anyone would ever get was that one email: a single point of failure for a production dependency, with no monitoring on it whatsoever. Systems that fail loudly get fixed; announcements that land silently get discovered at 9 a.m. on a Tuesday.

Diagrams

Problem — how the failure unfolds:

timeline
    title Six months of notice, read by nobody
    section The announcement
        Month 0 : Vendor emails v1 sunset notice : Lands in alias from two reorgs ago : Delivered, read by nobody
    section The quiet months
        Months 1-6 : Integration untouched : Nobody owns the notice
    section Sunset day
        Tuesday 9am : v1 returns 410 Gone : Identity checks fail everywhere
    section The postmortem
        Week after : Audit finds three more : deprecated dependencies running

Solution — where the guardrails go:

flowchart TD
    A["Vendor announces v1 sunset"] --> B["Notice routed to a<br/>monitored team channel"]
    B --> C["Dependency registry: every<br/>API, feed, package with<br/>version and owner"]
    C --> D["Registry entry flagged:<br/>sunset announced"]
    D -.-> AL["Quarterly review surfaces<br/>it with five months to<br/>spare"]
    G["Version-currency dashboard<br/>tracks deprecated versions<br/>as tech debt"] -.-> AL
    AL --> E["Migration ticket created,<br/>owned, and scheduled"]
    E --> F["v2 migration ships weeks<br/>before the deadline"]

What good looks like

• A dependency registry with real fields: dependency name, current version, named owner (a person), vendor contact address on file, contract renewal date, sunset status, last-reviewed date. An entry with no owner is itself a finding.
• One monitored route for vendor mail: every vendor's contact-on-file points at a team channel or shared inbox with an on-call reader — never a personal address, never an alias whose membership nobody can list.
• An annual routing test: send a fake deprecation notice to your own contact-on-file for each critical vendor and confirm a human acknowledges it within a week. If it reaches nobody, fix the route before a real notice takes the same path.
• A version-currency dashboard: "N dependencies on deprecated or sunset-announced versions" as a standing number, reviewed quarterly — tech debt with a metric, not a postmortem discovery.
• Notices become tickets automatically: a deprecation announcement creates a migration ticket with the sunset date as the due date and the registry owner as the assignee — the email is the trigger, never the tracking system.
• Quarterly registry review on the calendar: thirty minutes, walk the registry, ask "what's on borrowed time?" — the review the story's team would have needed exactly once.

The lesson

Keep a dependency registry — every external API, data feed, and package, with its version, its named owner, and its sunset status — and review it quarterly. Route vendor communications to a monitored team channel, never a personal address or a stale alias. Track version currency as tech debt with a dashboard: "how many of our dependencies are on borrowed time?" should be a number someone can read, not a surprise someone discovers.

Named concepts: dependency registry, deprecation tracking, vendor communication routing, version currency.

Real-world echoes

• left-pad (2016). A maintainer unpublished left-pad — eleven lines of JavaScript — from the npm registry, and builds broke across the internet within hours, including at major projects whose developers had never heard of it. Different trigger (an unpublish rather than a sunset), same anatomy: a dependency nobody tracked, load-bearing right up until the moment it wasn't there.

Transfer

Pick our five most critical external APIs. For each: who receives that vendor's emails today — and when did that person last actually read one?

Make it a ticket: audit the contact-on-file for those five vendors this sprint — re-point each to a monitored team channel, record the named owner in the dependency registry, and count how many current versions have announced sunsets. The count goes on the dashboard.

Related

• Drill 60 — The Package That Turned — the same asymmetric attention one layer down, at the package level, where the "notice" is a release note nobody reads either.
• Drill 63 — The Acquisition — the sunset you can't migrate away from on your own clock.
• Drill 39 — vendor drift: the change the vendor doesn't email you about at all.