Build a Tech Radar From Your Own Incident Log, Not Conference Keynotes

Day 1: Put the Postmortem Beside the Migration Backlog

Picture the workspace before a quarterly architecture review. On one monitor, an engineer opens a raw postmortem with its incident timeline, recovery steps, and unfinished follow-up work. On the other, a migration backlog sits open, stalled tickets still attached to the components they were supposed to replace. The architecture slides can wait.

Inventory operational pain, separate technology failures from implementation failures, and give every radar decision an evidence trail and a next action. That is the job.

The scene is staged, but the tension belongs to ordinary engineering culture: the proposal describes where the stack should go; the incident report describes what operating it demands. Put those documents together before someone mistakes enthusiasm for a migration plan.

Use a trailing 12-month window to assemble a component-level Adopt, Hold, and Retire grid. Draw from production incident reports, high-urgency on-call pages, and infrastructure migration tickets within that window. This seven-day itinerary gives a staff engineer or tech lead a concrete preparation path for the review.

Keep the first pass plain. A ledger, a decision grid, and links back to records will carry more weight than a beautifully rendered radar whose rings nobody can explain.

Day 2: Give Each Operational Event a Single Ledger Entry

What belongs in the ledger? Begin by writing down the review dates, included services, and environments. Then collect records from that scope. Otherwise, a heavily instrumented service can look troublesome simply because its monitoring produces more paperwork.

Include incident reports, actionable high-urgency pages, and related migration work. For pages, use a practical admission rule: an engineer had to intervene, such as running a command or merging a corrective change. Auto-remediated CPU spikes and transient network alerts belong in monitoring history; importing the entire alert stream makes the review harder to read.

Keep the Ledger Flat

Use these 11 columns:

1. Record ID: a stable identifier for the originating event.
2. Date: when the event occurred.
3. Service: the service responsible for the record.
4. Component/version: the relevant dependency and version.
5. Environment: where the failure occurred.
6. Failure mechanism: what failed operationally.
7. Customer impact: the affected behavior and duration.
8. Recovery action: what restored operation.
9. Operator effort: hands-on response and labeled cleanup estimates.
10. Related migration ticket: the linked corrective or replacement work.
11. Source URL: links to the underlying records.

A page, a postmortem, and a follow-up ticket can describe the same outage. Give that event one ledger ID and preserve all its source links. Count its consequences together rather than turning document volume into apparent recurrence.

Keep elapsed recovery time separate from engineering effort. The duration of degraded service answers a customer-impact question. A person-day estimate for cleanup answers a staffing question. Combining them obscures both.

Day 3: Trace the Connection Pool Before Blaming the Database

A beginner often starts with the loudest component name in the incident report. The database appeared in every dashboard, so the database gets the blame. A useful review follows the mechanism further.

Give each event separate tags for affected component, observed failure mechanism, contributing configuration or deployment choice, detection path, and recovery action. Keep these distinctions even if the ledger stores them together in a structured cell.

A Hypothetical Pool Exhaustion

Consider an application-tier database client configured with a static pool limit of 200 connections per pod. During a routine autoscaling event, the application reaches 12 pods and exhausts available sockets. Four dependent checkout and inventory services start returning HTTP 502 responses.

Tag the database client and its pool configuration as the source of the connection demand. Record socket exhaustion as the observed mechanism. Preserve the database service as affected infrastructure. Attach the downstream service failures to the originating ledger ID.

The detection and recovery tags should describe the path actually observed and the action actually taken; do not fill them with what the runbook says should have happened.

For a more mature ledger, retain service-level impact under the parent event. That preserves the blast radius without counting every dependent service as another independent database failure.

This distinction changes the radar decision. The example supports Hold with a pool-tuning ticket and validation work. Automatically placing the database engine in Retire would send the migration backlog after the wrong problem.

Day 4: Rate the Burden That Reaches the On-Call Engineer

Keep the pain profile visible as separate Low, Medium, and High bands. This is an editorial rubric, with written judgments and source links. A weighted total would let a rare incident's low recurrence cancel out an ugly manual recovery procedure.

Evaluate each component across these dimensions:

• Mechanism recurrence: does the same failure return after corrective work, or remain an isolated event?
• Customer impact: does the failure produce isolated degradation, partial disruption, or service interruption?
• Hands-on recovery burden: does automation restore service, does an operator execute a bounded procedure, or does recovery require invasive coordination?
• Detection difficulty: do actionable signals identify the mechanism, or must the responder reconstruct it from scattered symptoms?
• Upgrade and rollback friction: can the team perform routine changes, or must it coordinate dependency migrations and recovery across services?

Write the reason beside each band. “High recovery burden: requires manual state mutation” gives the review something to challenge. “High complexity” gives it an adjective.

Manual Recovery Counts

Under this rubric, automated pod recycling sits at the low end of recovery burden. A procedure requiring SSH access, manual state mutation, or coordinated multi-service restarts moves that dimension to High. Low recurrence does not erase that assignment.

Use Medium for bounded operator work between those extremes, and describe the procedure. Apply the same discipline to upgrades: a routine upgrade and a coordinated migration impose different work even when both eventually succeed.

Keep disagreement attached to the relevant band. That makes industry opinions discussable without letting them quietly replace the incident record.

Day 5: Give Each Radar Ring an Executable Meaning

A high-pain component can still belong in Hold. When replacement lacks an executable path, fund corrective work and record the boundary. Retire becomes useful when someone can carry it out.

Build the decision grid with eight fields: component/workload, pain bands, linked ledger IDs, proposed ring, written rationale, accountable owner, next action, and review trigger. Keep workload in the first field because approval for one use does not automatically authorize every use.

Adopt for a Named Workload

Adopt approves a specific workload or bounded expansion. Record the operating requirements and a validation task: exercise recovery, establish telemetry, or verify the upgrade procedure before expanding use. An empty incident history supplies no operational test by itself.

Hold Within a Boundary

Hold authorizes continued use inside a written boundary, paired with corrective work where needed. For the hypothetical connection pool, that means retaining the component while tuning connection demand and validating behavior during scaling.

Hold can be the economical decision. It lets the team spend effort on the mechanism causing trouble instead of replacing infrastructure that merely appeared in the incident.

Retire With a Cutover

Require a replacement path, linked migration epic, accountable engineering owner, dependency sequence, tested rollback condition, and completion trigger before assigning Retire. The completion trigger should describe an observable end state, such as removing the final dependent client and closing the migration work.

Without those pieces, the ring becomes a wish somebody else inherits.

Day 6: Make the Rewrite Pitch Answer a Ledger ID

Now stage a hypothetical proposal review. A pitch promises simpler operations and better performance. Place it beside the completed grid and ask the proposer to connect each operational claim to a recorded failure mechanism.

For the pool-exhaustion example, changing the database engine deserves scrutiny if the application still multiplies connection demand during scaling. A replacement proposal must explain how that behavior changes.

• Which ledger ID captures the mechanism this proposal addresses?
• Which operational responsibility disappears, and which team inherits the replacement's responsibilities?
• How will compatibility hold through the dependency cutover?
• What condition triggers rollback, and how will the team execute it?
• Who owns the replacement's on-call response and upgrades?

Turn the answers into a bounded trial. Use a 30-to-60-day staging and shadow-production soak, with synthetic load, to exercise automated recovery, minor-version upgrades, telemetry fidelity, compatibility, and rollback execution. Record where an operator must intervene.

Choose acceptance criteria from the pain bands. A proposal intended to reduce recovery burden should demonstrate recovery without the manual state changes recorded in the ledger. One aimed at upgrade friction should exercise the upgrade and rollback path before approval.

Place projected latency or throughput gains beside migration effort and on-call preparation. Developer tooling that reduces one team's work can create another team's operating responsibility. The review needs both sides on the page.

Day 7: Publish the Decision and Its Next Migration Ticket

Publish two artifacts with different access boundaries. Keep the raw operational ledger behind internal engineering permissions. Share an appropriately redacted decision grid with the intended engineering audience.

The summary should carry the review window, included services, component/workload boundaries, pain bands, ring decisions, owners, source-record references, next actions, and review triggers. Preserve traceability through ledger IDs while keeping sensitive incident mechanics and restricted postmortem details in the controlled ledger.

Attach the active remediation or migration ticket to each relevant decision. A reader should be able to find the person responsible and the work currently authorized without reconstructing the architecture meeting.

Refresh an entry after a relevant incident, completed remediation, meaningful workload change, or migration milestone. Explicit triggers can include a severity-1 incident, closure of the linked remediation epic, or a doubling of workload traffic. Ring assignments should move when their evidence changes.

That last trigger matters in the worked example: a static limit of 200 connections applies to each of the 12 autoscaled pods, while the exhausted database appears downstream of that configuration choice.