Taking ownership of an unmeasured system

The Scenario

You join a new team, or an existing service gets orphaned to your squad, and you're the owner. The system has been running for three years. There is no runbook. The APM dashboards exist but no one trusts them. The original author left eighteen months ago. When alerts fire, people guess.

This is a useful interview situation because it reveals how you make progress when the facts are incomplete.

What the Prompt Is Testing

When a prompt asks, "Tell me about a time you inherited a system you didn't understand," it is testing whether you can:

• Pragmatism — Can you make incremental progress without needing complete information?
• Systematic thinking — Do you work through unknowns methodically, or randomly?
• Stakeholder management — Do you communicate uncertainty to users and leadership?
• Build vs. ask — Do you know when to dig in yourself vs. find the person who knows?

If you have not inherited a production service in exactly this condition, use the closest real example you have and say what was true of your experience. Do not turn the framework below into a personal story you did not live.

30-Second Opening

Open with the system, the gap, your responsibility, and the result. Replace every bracketed item with evidence from your own work:

I took ownership of [system] when it was responsible for [user or business function]
but had limited visibility into [specific gap]. I was responsible for [your scope],
so I first [initial step]. We then [measurable or observable result], with [next
guardrail or follow-up] left in place.

This is a speaking template, not a claim about a particular experience. If the result is still in progress, say that plainly.

The Acquisition Framework

Phase 1: Map the blast radius (day 1-2)

Before doing anything else, understand what this service owns and what breaks if it fails:

Questions to answer:
- What does this service do? (user-facing? internal?) 
- What calls it? (upstream dependencies)
- What does it call? (downstream dependencies)
- What would break if it went down right now?
- Is there an SLA on it?

You can get most of this from: service mesh topology, API gateway routing, deployment configs, and asking your team lead for 30 minutes.

Phase 2: Audit existing signals

Audit checklist:
☐ Is there a health check endpoint?
☐ Are there application-level metrics (not just infra metrics)?
☐ Are there logs? What log level? Structured or unstructured?
☐ Are there traces? Do they propagate across service boundaries?
☐ Are there alerts? Who gets paged? When were they last tuned?
☐ Is there a dashboard? Does it reflect current architecture?

This tells you what you have to work with before you build anything new.

Phase 3: Run through the failure scenarios manually

For each critical path your service owns (e.g., "process a payment"), walk through:

"If this step fails, what happens?
 Is there a fallback? Is it tested?
 Is the failure observable? Would I see it in monitoring?
 Is there retry logic? Is it bounded?"

This is a live documentation exercise. Write it down as you go. You now have the beginnings of a runbook.

Phase 4: Add coverage to the dark spots

Now you know which failure modes are unobservable. Add metrics/logs in priority order:

Priority 1 (add this week): 
- Error rate on critical paths
- p99 latency on user-facing endpoints
- Queue depth if async

Priority 2 (add this month):
- Business metric (orders processed / payments authorized)
- Resource saturation (connection pool utilization, thread pool)

Priority 3 (nice to have):
- Detailed per-operation traces
- Cold start metrics
- Dependency health

The Stakeholder Communication

Inheriting an unmeasured system creates a trust problem: you don't know what you don't know, which means you can't make promises about reliability. Say that:

The wording below is an illustrative template. Replace it with your actual scope, evidence, and timing:

"I'm in the process of documenting this service's failure modes and
 adding observability. Right now I can't commit to a specific uptime 
 target because I don't have full visibility into the system. 
 I'll have a clearer picture in two weeks and can give you a more 
 specific answer then."

This is uncomfortable but correct. The alternative — making a commitment you can't back up — is worse.

Common Mistakes and Anti-Patterns

Immediately rewriting it. An unmeasured system you don't understand yet is not a good candidate for a rewrite. You don't know what behavior is intentional vs. accidental yet.

Spending weeks on observability before going on call. You can't wait for perfect visibility before owning the service. Build incrementally while starting to respond to incidents.

Treating the lack of documentation as someone else's failure. Correct observation — but not useful. The system is yours to document now.

Getting confident too fast. Three weeks in, the system seems fine. Four weeks in, a failure mode you didn't know about hits. Maintain healthy uncertainty.

Overclaiming the outcome. Do not claim that you improved uptime, reduced incidents, or completed a runbook unless you measured or actually completed it. A smaller, evidenced result is stronger than a precise result you cannot support.

Presenting a plan as personal history. "I would add metrics and document the failure modes" is a valid hypothetical answer, but it is not evidence that you did those things. Label plans as plans and keep the personal story to what you actually did.

Build a 2–5 Minute STAR Answer

Use the outline below with one real situation. Replace bracketed details with your own facts; do not present the outline as a personal experience until you have filled it with something you actually did.

Situation (30s): What was [system] responsible for, and what state was it in when you took over? Mention the missing [metrics, runbook, documentation, or ownership] and the risk it created.

Task (20–30s): What were you responsible for? State the outcome you needed, such as [make the service supportable] or [reduce uncertainty before the next on-call rotation], plus any [time or reliability constraint].

Action (2–3 min): Walk through the phases you actually used — [map the blast radius], [audit existing signals], [trace a critical path], and [add the highest-value coverage]. Explain what you prioritized and why. If a real incident tested the new understanding, describe what happened when you had to respond before you knew everything and what you did.

Result (30–60s): What changed in [visibility, response time, incident confidence, or operational ownership]? Name the dashboard, runbook, metric, or process that exists now, and include a measured result if you have one. If the work is incomplete, say what remains and how you will measure it.

This structure runs about 3–4 minutes at a normal pace. Spend most of the time on your decisions and evidence, not on a long description of the legacy code.

Choose and Adapt a Real Story

Choose a story in which you personally did at least two of the following:

• took ownership of an unfamiliar service, workflow, or codebase;
• found a gap in monitoring, documentation, tests, or ownership;
• made a prioritized improvement while keeping the system running; and
• measured a result or left a concrete next step for the team.

The story does not need to be a perfect match. A handoff, a new team assignment, or a poorly documented internal tool can work if you explain the real stakes and your actual contribution. If the system was not truly unmeasured, say what was missing rather than exaggerating the gap.

If you have no direct example, use this bridge honestly: "I have not inherited a production service with no trusted metrics. My closest example is [real situation], where I was responsible for [actual responsibility]. I [actual action], and the lesson I would carry to this situation is [specific principle]." Keep the last sentence hypothetical; keep the earlier sentences factual.

Follow-up Questions and How to Answer

"How did you decide what to measure first?" Explain the risk and user impact, then name the smallest signal that would reduce uncertainty—usually critical-path errors, latency, or queue depth before detailed tracing.

"Why did you not rewrite the system?" Say what you knew at the time, how you reduced uncertainty, and why an incremental change was safer. If you did choose a rewrite, explain the evidence that made incremental change impractical.

"What did you do when you needed help?" Give credit to the person or team with the missing context, and be precise about your part: [investigation], [coordination], [documentation], or [implementation].

"How did you know the system was safer afterward?" Point to evidence such as [an alert tested against a known failure], [a documented dependency map], [a shorter diagnosis time], or [a measured change in errors]. Do not substitute confidence for evidence.

"What would you do differently?" Name one specific improvement, such as involving the original domain expert earlier or adding a minimum observability checklist to future handoffs.

Test Your Understanding

1. Why map the blast radius before adding instrumentation?

Because it tells you which paths and dependencies matter most, so early work reduces the greatest operational risk.

2. What makes an observability improvement a good first step?

It answers an important failure question with a small, reliable signal—for example, critical-path error rate or latency.

3. What should you do if you lack an exact story?

Use the closest true example, state the difference, and describe how you would apply the lesson without claiming hypothetical work as past work.

4. What belongs in the Result part of STAR?

The evidence of what changed, what remains uncertain, and the guardrail or follow-up that keeps the improvement useful.

Quick Recap

1. Before adding anything, map the blast radius — understand what breaks if this service fails.
2. Audit what observable signals already exist before building new ones.
3. Walk the critical paths manually as a failure exercise — it produces a runbook and identifies gaps simultaneously.
4. Prioritize observability by: error rate > latency > business metric > resource saturation > detailed tracing.
5. Communicate uncertainty to stakeholders early — premature confidence commitments are worse than honest uncertainty.

Related Skills

• Observability: selecting metrics, logs, traces, and alerts that answer concrete failure questions.
• Incident response: using the new signals to assess impact, form hypotheses, and escalate safely.
• Technical ownership: turning an inherited system into a service with clear boundaries, documentation, and an owner.
• Stakeholder communication: setting expectations with evidence while the system is still being understood.