Ownership and Accountability Under Operational Pressure Questions

Direct answer

With incomplete information, I make the assumptions explicit rather than silent, act on the option that's easiest to reverse if I'm wrong, and treat speed versus caution as a question of what being wrong here actually costs, rather than a fixed personal preference for one or the other. Afterward, I go back and specifically check whether the assumption held, rather than assuming a good outcome means the assumption was right.

Structured elaboration

• Making assumptions explicit: under pressure, it's tempting to act on a gut read without naming it, which makes the assumption invisible even to yourself. Saying out loud, or writing in the incident channel, that you're assuming X and here's what changes if that's wrong, keeps the decision auditable and makes it easy to correct once better information arrives.
• Speed versus caution as a reversibility question: I weigh how easy the action is to undo if the assumption turns out wrong. A fast, easily reversible action, such as turning off a recently added code path, is worth taking on weaker evidence than a slow, hard-to-reverse one, such as deleting data or a database failover with replication risk, which deserves more caution even under time pressure.
• Choosing based on cost of being wrong, not just cost of waiting: the pressure to move fast is constant during an incident, but the right pace depends on what a wrong decision actually costs versus what a few more minutes of confirmation costs. Those aren't always the same, and conflating them leads to either reckless speed or paralysis.
• Validating or reversing afterward: once better information is available, actually go back and check the original assumption against it, rather than treating a good outcome as automatic proof the assumption was correct, since a good outcome can happen for the wrong reason.

Worked example

During an incident, a service was returning elevated error rates, and two plausible causes were in play: a recent minor configuration change, or a spike in traffic from a specific partner integration. I didn't yet have enough log detail to be certain which one it was. I made my assumption explicit in the incident channel: assuming this was the configuration change since the timing lined up closely, rolling it back now since that's fully reversible either way, and continuing to investigate the traffic angle in parallel. Rolling back the configuration change was low-risk even if I was wrong, since it just returned a value to its previous state, so I acted on partial evidence there. I deliberately didn't take the more aggressive, harder-to-reverse action available, throttling that partner's traffic entirely, since that carried real cost to a legitimate integration if my traffic-spike theory turned out wrong, and the evidence for it was weaker than for the configuration theory.

The rollback didn't fully resolve the error rate, which was itself useful information: it meant my assumption had been partially wrong, the configuration change wasn't the whole story. With that confirmed, I went back to the traffic theory with more confidence, pulled the actual request logs rather than acting on the correlation alone, and found the partner integration really was sending a malformed batch that was triggering errors on a specific code path. At that point the evidence was strong enough to justify the more aggressive, less reversible action I'd held off on earlier, so I applied a targeted rate limit to that specific partner's traffic, which resolved the remaining error rate.

Afterward I explicitly checked both original assumptions against what I'd learned rather than just closing the incident once resolved: the configuration theory had been a real contributing factor, just not the complete cause, and the traffic theory turned out to be the dominant one. Writing that down mattered, because if I'd stopped investigating the moment error rates started improving after the rollback, I'd have wrongly concluded the configuration change was the entire story.

Trade-offs and pitfalls

The common mistake is treating speed and caution as a single dial to turn up or down uniformly, when the right answer depends on how reversible each specific action is, not on a general instinct to move fast or slow. The other trap is stopping the investigation the moment things start improving, mistaking partial improvement for full confirmation of the original assumption, which can leave the actual root cause unaddressed and ready to resurface. Being explicit about assumptions also has a real cost, it takes a few extra seconds during a stressful moment, but that cost is small compared to what it saves later when someone needs to understand why a decision was made.

Direct answer

In the moment, my first job is to actually listen to the criticism rather than start explaining or defending myself before I've fully heard it, even when the instinct to justify is strong. Afterward, rebuilding trust isn't about the conversation where I received the feedback, it's about visibly acting differently going forward in the specific way the feedback pointed at.

Structured elaboration

• Managing the reaction in the moment: the instinct right after an outage, already stressed, is to explain the context and mitigating factors as soon as criticism starts. I've learned to let the person finish first, genuinely hear the specific complaint, and only then respond, since jumping in early to explain often lands as defensiveness even when that isn't the intent.
• Separating the valid signal from the delivery: tough feedback right after an outage often arrives with real frustration attached. The useful move is extracting the actual substance, what specifically should have gone differently, rather than reacting to the tone it arrived in.
• Not over-apologizing either: there's a version of managing the reaction that overcorrects into excessive self-criticism, which doesn't address the substance any better than defensiveness does; the goal is a level, accurate acknowledgment, not performing contrition.
• Rebuilding trust afterward: the actual trust repair happens in what changes afterward, doing the specific thing the feedback pointed at differently next time, not in how gracefully the original conversation went.

Worked example

Right after an outage I'd contributed to, my manager gave me direct, pointed feedback in a one-on-one: that I'd been slow to escalate once it became clear I was stuck, and that the delay had made the outage longer than it needed to be. My first instinct was to explain the reasoning that had made sense to me in the moment, that I'd thought I was close to a fix. I held off on that and let them finish first, and once I actually listened past my own defensiveness, the specific point was fair: I had, in fact, kept trying alone for longer than made sense given how the situation was unfolding.

I acknowledged the specific point directly rather than the vaguer "I hear you, I'll do better," and said what I'd concretely do differently: escalate earlier next time I'm stuck past a set point, rather than continuing to push alone. The actual trust rebuilding happened over the incidents that followed, not in that conversation. In the very next incident where I got stuck, I escalated well before I would have previously, and I made a point of telling my manager afterward that I'd deliberately applied the earlier feedback, which is what actually closed the loop for them, seeing the specific behavior change rather than just hearing that I'd taken the feedback well.

Trade-offs and pitfalls

The common failure mode is treating receiving feedback well as the whole task, being gracious and non-defensive in that one conversation and considering it handled. Without a visible change in behavior afterward, gracious listening reads as agreeable in the moment and forgotten a week later, which damages trust more than a defensive reaction followed by real change would. The other trap is swinging to excessive self-criticism, which can feel like taking it seriously but doesn't actually engage with the specific, actionable substance of the feedback any better than dismissing it does.

Direct answer

Taking responsibility here doesn't mean claiming I caused it or pretending I understand a system I've only been in for a month. It means owning the response: being visibly present, honest about what I don't yet know, and driving the incident toward resolution instead of waiting for someone more senior to take charge because I'm new. Afterward, responsibility means making sure the fix has an owner and a deadline that outlives the adrenaline of the incident itself, since that's exactly the kind of fix that quietly dies once things calm down.

Structured elaboration

• Responsibility without false confidence: say plainly, to the team, what I know and don't know: still ramping up on this system, here's what I can see so far, here's where I need someone with more context. Pretending to more understanding than I have slows the incident down and erodes trust faster than admitting the gap.
• Owning the response, not the blame: being new doesn't excuse disengaging or deferring entirely to others. I can still own coordinating, documenting what's been tried, and driving toward next steps, even while relying on someone else's deeper system knowledge for the actual diagnosis.
• Being visibly accountable in front of the team: staying present and engaged through the incident rather than quietly stepping back because it isn't officially my mistake, and afterward being willing to say what I personally learned and would do differently, since that's the part that's genuinely mine to own even if the original bug wasn't.
• Preventing the fix from being forgotten: the single biggest risk to a "we'll fix this properly later" item is that it has no named owner and no deadline once the incident channel goes quiet. I write down the concrete follow-up action, assign it an owner (myself, if I'm capable of doing it once I understand the system better, or explicitly someone else if not), attach a real deadline, and put it somewhere that gets reviewed, not just left as a comment at the bottom of an incident channel nobody revisits.
• Following up personally: beyond just filing the ticket, checking back after a set number of weeks whether the fix actually landed, rather than assuming that filing it discharged the responsibility.

Worked example

A month into a new role, I got paged (received an automated on-call alert summoning me to respond) for a service degrading badly during business hours. I'd touched that part of the system exactly zero times before. Rather than waiting silently for someone senior to jump in, I opened the incident, immediately posted what I could observe (elevated latency, one specific downstream dependency also showing errors) and explicitly asked in the channel for anyone with deeper context on that service to join, being upfront that I was still new to it rather than pretending otherwise. A more experienced engineer joined and diagnosed the actual cause, an exhausted connection pool, the shared set of reusable database connections had all been checked out with none available, under an unusual traffic pattern, while I handled coordinating the timeline, keeping the stakeholder updates going, and documenting what we tried as we tried it, so nothing had to be reconstructed from memory afterward.

Once service was restored, the informal consensus in the channel was that the pool size should be tuned properly at some point, the kind of statement that, in my experience, quietly evaporates once the incident channel goes quiet and everyone moves to the next thing. I wrote it up as a specific follow-up item with a description precise enough to act on, assigned myself as the owner even though I hadn't diagnosed the original issue, since owning the follow-through was something I could do regardless of tenure, and put a deadline a couple of weeks out. When that deadline arrived I actually did the work, with help from the engineer who'd diagnosed it originally, and confirmed the new pool configuration in a load test before calling it closed, rather than just marking the ticket done because the deadline had arrived.

Trade-offs and pitfalls

The trap for someone new is treating "not my fault, not my system" as license to fade into the background during the incident, which reads as disengagement even though it feels like appropriate humility. The other trap is overcorrecting into false confidence, claiming understanding you don't have to seem capable, which actively slows the incident down. On follow-through, the common failure is treating "we should fix this properly" as if saying it out loud during the incident retrospective counts as doing it; without an assigned owner and a deadline someone checks, it becomes exactly the kind of debt that resurfaces as the same incident months later.

Direct answer

I decide who to pull in based on where the evidence points, not on organizational courtesy, and I'd rather pull in one extra team too early and be wrong than wait for certainty and be right too late. Looking back at a specific case, I judged one escalation right and one slightly late, and the late one is the more instructive story.

Structured elaboration

• Deciding who, across teams: escalation isn't "who owns this officially," it's "who has the context or access I don't." I look at the symptom (which system, which layer) and pull in whoever's expertise the current evidence points toward, even if the retrospective later shows it wasn't actually their code.
• Deciding when, under time pressure: I use a rough personal threshold: if I can't form a credible hypothesis within a defined short window, or if the blast radius (how many users or systems are affected) is growing while I investigate, that's the signal to escalate rather than keep digging alone. Waiting for certainty before escalating is itself a decision, just a slower and riskier one.
• The cost asymmetry that should drive the call: escalating and being wrong costs someone else a few minutes of attention. Not escalating and being wrong costs extended user impact. That asymmetry means the bar for escalating should be lower than it instinctively feels under pressure, since the instinct is usually not wanting to page (send an automated on-call alert to) someone for something you might solve yourself.
• Judging it afterward: right, too early, or too late should be assessed against what was knowable at the time, not against what turned out to be true. Pulling in a team that turned out to be unaffected isn't automatically "too early" if the evidence available at that moment reasonably pointed there.

Worked example

During an incident where a service was returning errors for a subset of requests, I initially suspected our own service's recent deploy and pulled in that team's on-call within the first few minutes, which in hindsight was the right call: they were able to quickly confirm or rule out the deploy as cause, and ruling it out fast redirected the investigation instead of costing time. Error rates kept climbing while the deploy theory was being ruled out, and the pattern started looking like it correlated with a specific upstream dependency, a shared caching layer another team owned that stored temporary results so services didn't have to repeat expensive work. I hesitated on pulling that team in for a while, partly because the correlation wasn't yet conclusive and partly, honestly, because I didn't want to page a second team on a hunch that might turn out wrong. When I finally did escalate, they found a change on their side within a few minutes that matched the timeline closely.

Looking back, that second escalation was too late by my own standard: the evidence pointing toward the caching layer had been strong enough to justify pulling that team in noticeably earlier than I did, and the time I spent second-guessing the correlation extended the outage without producing better evidence than what I already had. The lesson wasn't "always escalate instantly," since the first escalation showed that fast, targeted escalation on reasonable evidence works well. It was that my hesitation on the second one came from worrying about being wrong in front of another team, not from the evidence actually being weaker.

Trade-offs and pitfalls

The senior-discriminating mistake here isn't failing to escalate at all, it's the quieter version: escalating on the confident hunch immediately but hesitating on the second, less certain one, because social discomfort about being wrong outweighs the actual cost math in the moment. The trade-off worth naming explicitly is that over-escalating has a real cost too. Constant low-confidence pages erode a team's willingness to respond quickly the next time, so the goal isn't to escalate on everything, but to calibrate the bar honestly to the evidence rather than to your own comfort with looking uncertain.

Direct answer

Shared blame with a flaky test doesn't reduce my share of it to zero: I still merged the change and benefited from the green checkmark without questioning it, so in the moment I own the regression fully, not fifty percent of it. In the weeks after, "the test was flaky" only becomes a legitimate part of the story once I've actually done something about the test, not just cited it as a mitigating factor.

Structured elaboration

• In the moment: state clearly that my change caused the regression, without leading with the test's flakiness as a defense. Mentioning the test as context is fine once the ownership is unambiguous; leading with it reads as shifting blame even if that's not the intent.
• Resisting the instinct to relitigate blame during the incident itself: the incident isn't the time to debate how much of this is really the test's fault. That conversation happens afterward, calmly, when it can actually produce a fix rather than defensiveness.
• In the weeks after: two separate threads, not one. First, whatever personal habit or check would have caught this regardless of the test, for example whether I actually exercised the changed code path locally rather than relying entirely on the automated build passing. Second, fixing or removing the specific flaky test, since a test that's known to be unreliable and still gates merges is a real system problem, not just this one incident's excuse.
• Owning the systemic piece without avoiding personal responsibility: pushing for the flaky test to be fixed is legitimate and worth doing, but doing it should read as making sure this can't happen to the next person either, not as retroactively lowering my own share of what happened.

Worked example

I merged a change after the continuous integration (CI) build, the automated pipeline that builds and tests every change before merge, passed. The test covering the exact code path I'd changed was known among the team to fail intermittently for unrelated timing reasons, so a passing run wasn't strong evidence the change was actually safe, and this time it happened to pass despite a real regression in my change. The bug reached production and caused visible errors for a subset of users within the hour.

In the incident channel, I stated plainly that my merge caused it, described what the regression actually was, and didn't lead with the test's flakiness as my first sentence, even though I mentioned it once it was relevant to explaining why the automated build hadn't caught it. I rolled back the change immediately rather than trying to hot-fix it live, since a full revert was the fastest safe path back to a known-good state.

In the weeks after, I did two concrete things rather than treating the postmortem discussion as sufficient on its own. First, for my own habit, I started actually running the specific test suite for any code path I touch locally before relying on the automated build as the sole gate, since a passing build had quietly become my only signal of safety even on paths I knew had a flaky test. Second, I picked up the fix for the flaky test itself, tracing its intermittent failure to a timing assumption that didn't hold under parallel test execution, in other words a race condition (a bug where the outcome depends on the unpredictable order or timing of two things happening at once), and rewrote it to remove that race condition rather than just adding a retry, a common shortcut that hides flakiness instead of fixing it. I confirmed the fix by running the rewritten test many times in a loop locally with no failures, where the old version had failed intermittently under the same loop.

Trade-offs and pitfalls

The tempting shortcut is to let "the test was flaky" quietly do more work in the story than it should, using it to soften how much of this was actually a personal miss. The other common shortcut, once you do own the flaky test as a systemic issue, is patching it with a retry rather than actually fixing the underlying race condition, which makes the test look reliable again without making it trustworthy again; the next real regression on that code path could just as easily slip through the same way. Genuine ownership here means doing the less convenient fix, the actual race condition, rather than the one that makes the symptom go away fastest.