Skip to content

11. The 30-60-90 plan

Stakeholder management sustains modernisation across months. The 30-60-90 plan is what makes those months legible. It is the lead's structural commitment — what is done in the first thirty days, the first sixty, the first ninety — sequenced from the disciplines this module has built.

A platform lead joins a Mumbai content company in week one of January. By week three she has finished the audit and built the first eval. By week six the prompts are in a registry and observability is live. By week ten the model migration is complete and feature work has resumed. None of this is luck. The lead committed to a 30-60-90 plan on day five, posted it to leadership, and executed against it. The plan was honest about what was uncertain; it shifted twice as new findings arrived; both shifts were communicated. At day ninety, the system is in a defensible operational state; the team can ship features safely; the executive can speak about the AI platform without hedging.

This chapter is the plan template. It is not a fixed sequence — every inherited system is different — but it is a defensible default that you can adapt.

What the plan is for

Three uses, each load-bearing.

1. The lead's commitment to themselves. The plan forces sequencing decisions early, when the audit is fresh and the trade-offs are visible. Without it, the work drifts toward whichever fire is loudest each week.

2. The lead's commitment to stakeholders. Chapter 10 covered the communication; the plan is the substance the communication points to. A weekly update with no plan to reference is just status; an update against a plan is progress.

3. The team's shared map. The engineers working with the lead need to see how their work fits the larger sequence. The plan is the map.

The shape of the plan

A 30-60-90 plan is three columns. Each column is the outcome by end of that period — not the activities, the outcomes. Activities derive from outcomes; the outcome is what is true at the end.

A reasonable default for an inherited AI system at moderate complexity:

+--------------- 30 days ---------------+--------------- 60 days ---------------+--------------- 90 days ---------------+
| Audit complete and shared             | Observability live across the system  | Strangler boundary picked and       |
| Eval backstop live (50-80 cases)      | Prompts in registry                   |   first extraction shadow-running   |
| Top bleeding fix patched              | First model migration in canary       | Data-side audit complete            |
| Stakeholder cadence established       | Feature work resumed selectively      | First model migration complete      |
| Top deprecation date on calendar      | Second eval pass (failure modes from  | Feature delivery cadence steady     |
|                                       |   stabilisation period)               | Long-tail modernisation plan        |
|                                       |                                       |   communicated to executive         |
+---------------------------------------+---------------------------------------+---------------------------------------+

Five to seven items per column. Each is the outcome the lead promises by the end of that period.

The first column is the most tightly scheduled — the audit is finite work, the eval setup is finite work, the first patch is finite work. The second and third columns have more flex; they depend on what the first column reveals.

Day 1 to day 30 — Diagnose and steady

The first thirty days are the audit (chapter 02), the eval (chapter 03), one bleeding fix (chapter 04), and the start of stakeholder communication (chapter 10). The outcome at day thirty is "the system is operable and we know what we have."

Concrete milestones:

  • Day 5: First posted draft of the audit; first version of the 30-60-90 plan.
  • Day 14: Audit complete. Top 5 failure modes identified. Eval set scoped.
  • Day 21: Eval set built and runner live. Baseline scores captured. First bleeding fix shipped.
  • Day 28: Stakeholder communication rhythm established. First weekly updates sent.
  • Day 30: 30-60-90 plan updated based on the audit; communicated to leadership.

If the audit is slipping at day 14 — common in larger systems — the 30-60-90 plan should already be communicating that, with new dates.

Day 31 to day 60 — Stabilise and instrument

The second thirty days build the structural foundations: observability (chapter 06), prompts in the registry (chapter 05), model migration kick-off (chapter 08). The outcome at day sixty is "the system is observable, the prompts are owned, the model is on a calendar."

Concrete milestones:

  • Day 40: Observability layer 1 (per-call audit) live across the system. First dashboard available.
  • Day 50: First prompt migrated to registry, verified by eval. Migration of remaining prompts under way.
  • Day 55: Model migration canary at 25% or higher, verified by eval.
  • Day 60: Feature work resumed selectively on the stabilised parts of the system. Plan updated based on what month one revealed.

The cross-cutting work — the eval expanding, the audit collecting samples, the dashboards being read by the on-call — happens continuously across this period.

Day 61 to day 90 — Restructure and resume

The third thirty days lift the larger structural work: the first strangler extraction (chapter 07), the data-side audit (chapter 09), the model migration's completion. The outcome at day ninety is "the system is modernising, feature delivery is sustainable, the long-tail work is mapped."

Concrete milestones:

  • Day 70: Data-side audit complete; sources have owners and SLAs.
  • Day 75: First strangler boundary picked; new implementation in development.
  • Day 85: Model migration at 100%; deprecation calendar updated.
  • Day 90: Strangler shadow-running for first component. Long-tail plan (months 4–9) communicated.

By day ninety, modernisation is no longer the single focus; the system is in an operating mode where structural work continues alongside feature delivery, at a sustainable rhythm.

When the plan needs to slip

It usually does. Two patterns to handle the slip gracefully.

Audit reveals more than expected. The system is more entangled than the early read suggested. The 30-60-90 plan from day 5 was honest at the time; at day 14 the picture is fuller and the dates need to move. Communicate the new dates with the reason. Adjust the plan; do not pretend.

An incident interrupts. A production incident in the middle of the modernisation absorbs days that the plan budgeted for structural work. The interruption is real; the plan slips. Communicate; adjust.

The plan is a commitment, not a contract. Commitments can be renegotiated when conditions change; contracts cannot. The 30-60-90 is the former.

Variations: what changes the default sequence

The default sequence works for most inherited systems. Three conditions change it.

Tight retirement deadline. A model retiring in 45 days forces the migration earlier in the plan. The audit and eval shrink to fit; the model migration starts in week 3 instead of week 5. The risk is real and the lead should communicate it. Sometimes the only honest response is to ask for the retirement deadline to be re-negotiated with the provider (rarely successful) or to triage which features can ship on the new model on a shorter window.

Active compliance finding. A regulatory issue surfaced in the audit takes precedence over the structural work. The plan front-loads the fix to that finding even if it disrupts the natural flow. Chapter 04's compliance-overrides-everything rule applies.

Team is much smaller or larger than default. A solo lead can do everything in this plan but at half the pace; a team of five can compress the timeline. The plan adjusts to the resourcing; the sequence generally does not.

What "complete" means at day 90

Honestly: the modernisation is not complete at day 90. The eval has grown; the prompts are owned; the model is on a calendar; observability is live; one strangler boundary is shadow-running. The system is modernising — it is no longer the inherited mess from day one, but the long-tail work continues for months.

The executive update at day 90 should say this clearly. "We are out of crisis mode. Operational state is defensible. Feature delivery is resuming at a sustainable rate. The structural work continues; here is the plan for months 4-9."

The day-90 outcome is sustainable modernisation, not modernisation complete. The latter takes longer; the former is what makes the latter possible.

Communicating the plan

A useful day-5 communication to leadership:

30-60-90 plan for the AI platform modernisation:

By day 30:
- Audit complete, posted, and discussed
- Eval backstop live (target: 50-80 cases)
- Top bleeding fix patched
- Stakeholder communication rhythm established
- Top model deprecation date identified

By day 60:
- Observability live across all model call sites
- Prompts migrated to registry
- First model migration (where deprecation pressure exists) in canary
- Feature work resumed on stabilised parts of the system

By day 90:
- Data-side audit complete
- First strangler boundary picked and shadow-running
- First model migration complete
- Long-tail modernisation plan (months 4-9) shared

Known risks:
- claude-3-opus retires day 75; tight but achievable
- Three engineers on the team, including me

Updates: weekly, Mondays, to this channel.

Five short sections; commitments are dated; risks are named; cadence is set. The plan is now the substance every weekly update references.

Common mistakes

No plan. The lead executes without a sequence; weeks drift; stakeholders lose confidence; the modernisation never feels like it is making progress.

Overly precise plan. A plan that commits to specific deliverables in specific weeks for ninety days will be wrong by day twenty. The 30-60-90 column boundaries are the right granularity.

Plan never updated. The plan written on day 5 is wrong by day 30 once the audit is done. Update it; communicate the update.

Plan that is all activities, not outcomes. "Build the eval runner" is an activity; "eval backstop live with 50+ cases and CI integration" is an outcome. Outcomes commit the lead; activities do not.

Plan that hides the bleeding fix. The top symptom needs to be addressed visibly in the first month. A plan that focuses entirely on structural work in month one tells stakeholders the user pain is not a priority.

Interview Q&A

Q1. You are five days into a new lead role on an inherited AI system. The executive asks for the 90-day plan. What do you say? The plan, in three columns by day 30, 60, and 90, with outcomes per column (audit + eval + bleeding fix; observability + registry + model migration; strangler + data audit + sustainable cadence). Acknowledge that the day-5 plan is the best version of the plan available right now, will be refined when the audit completes at day 14, and will be re-communicated then. The executive gets the structure and a commitment to keep them updated. Wrong-answer notes: "I need more time to plan" loses the early commitment moment; "here is a precise weekly plan for 12 weeks" overcommits to false precision.

Q2. The 30-day plan is slipping at day 21 — the audit took longer than expected. What do you do? Communicate immediately. New dates for the day-30 milestones; the reason; the impact on day-60 commitments. The slip is honest because the audit's true size was unknowable on day 5; the communication makes the slip absorbable. Adjust the plan visibly; do not let day 30 arrive with milestones unmet and no warning. Wrong-answer notes: "push harder to hit day 30 anyway" produces a rushed audit and worse downstream work; silent slippage produces a trust deficit.

Q3. The executive wants modernisation "complete" in 90 days. How do you reframe? Honest reframing: "Day 90 is when the modernisation has reached a sustainable cadence — operational state is defensible, feature delivery has resumed, the long-tail structural work continues. The crisis is over by day 90; the long-tail is what we communicate the plan for in months 4-9. 'Complete' in 90 days is not realistic for a system of this size, but 'in a defensible operating state' is achievable." Provide the milestones that constitute "defensible operating state" so the executive has a concrete picture. Wrong-answer notes: agreeing to "complete in 90 days" without reframing produces broken commitments later.

Q4. The plan has structural work in month two and feature work resuming in month three. The PM is anxious about no features for two months. How do you reconcile? Two moves. First, identify any features that can resume earlier on the parts of the system already stabilised — usually some features only touch the prompt-registry layer or the audit layer, which are early-month-two work. Second, frame month one explicitly: the structural work is the reason feature delivery becomes safe and predictable in months 3+; the alternative was shipping features blind on a system that was producing the chapter-opening incidents. The PM trades two months of no feature delivery for sustained safe delivery thereafter; that is the deal. Wrong-answer notes: "we'll squeeze in some features" without making the trade explicit risks shipping into an unstable system and re-creating the problem.

What to do differently after reading this

  • On day 5, post the 30-60-90 plan. Update it on day 30, day 60, day 90.
  • Write outcomes per column, not activities.
  • Include a "known risks" section; communicate slippage as soon as it is visible.
  • Pair the plan with the weekly stakeholder cadence (chapter 10).
  • At day 90, communicate the long-tail plan for months 4-9. The modernisation does not end at day 90; the crisis does.

Bridge. Eleven chapters of discipline. The last two synthesise. The next chapter is the architect's checklist — twenty items that distinguish a modernisation you can defend from one you cannot. → 12-architect-checklist.md