Coachability, Feedback, and Humility Questions

Direct answer

Being called obstructive is itself feedback worth taking seriously rather than dismissing, since it may mean I have not made the risk legible to non-SRE stakeholders. I separate the criticism of my communication from the substance of the decision: quantify what exhausting the error budget actually risks, present it plainly, and then choose among adjusting the SLO, adding guardrails, or approving the release based on data rather than on who is more insistent.

Structured elaboration

Definitions. An SLO (service-level objective) sets a reliability target, for example "99.9% of requests succeed over 30 days." The error budget is the amount of allowed unreliability under that target before the budget is spent, 0.1% of requests in that example. "Exhausting the error budget" means the team is proposing to spend most or all of the remaining allowed failures on this one release.

Handling the feedback. I do not get defensive about the "obstructive" label. I ask directly what they think I am blocking and why, so I understand whether they believe the SLO itself is wrong, the guardrails are excessive, or I am simply moving too slowly procedurally. I then restate the trade-off in their language: this is not a "no," it is "here is what we are actually risking and here is what a bad outcome costs the business," which turns the conversation into one about the trade rather than about my judgment as a person.

Negotiating the trade-offs. I quantify how much of the budget is realistically at risk, what the blast radius is if it is exceeded (which customers, whether SLA penalties apply), and how time-boxed the exposure is. I bring options rather than a veto: presenting adjust-SLO, add-guardrails, and allow-release as three real choices with named costs, so stakeholders decide with full information instead of me picking unilaterally and calling it a decision.

Deciding among the three options. Adjusting the SLO is appropriate only if the current target was set without real user-impact data behind it, and the business genuinely accepts a lower reliability bar going forward, not just for this one launch; because it changes a standing contract, it usually needs sign-off beyond the feature team alone. Adding guardrails, such as a canary rollout (releasing the change to a small slice of real traffic first, to see how it behaves before rolling it out to everyone), a feature flag with a fast kill-switch, or extra on-call coverage during the launch window, is usually the best middle path when the release itself is sound but the risk is in blast radius, since it lets the launch proceed while capping the downside. Allowing the release as-is is justified only when the quantified risk is genuinely small and time-boxed with real headroom in the budget, in which case my initial caution was itself miscalibrated and worth saying so.

Worked example

Suppose the service's 30-day SLO is 99.9% success against roughly 10 million monthly requests, giving an error budget of 10,000 allowed failed requests. The team has already used 7,000 of that budget from earlier incidents this month. Load-test data projects the new feature would add roughly 2,000 more failed requests during a three-day launch window at peak load, mostly from a known timeout edge case, leaving only 1,000 requests of margin against normal month-end traffic spikes.

Options on the table: fixing the known timeout edge case pre-launch, which the load test shows would cut the projected failures to about 400, a guardrail-style fix; launching behind a feature flag to 10% of traffic first, measuring the real failure rate, then ramping up, another guardrail; or accepting the full 2,000-request risk and formally revising this month's SLO downward for the launch window, with the business explicitly signing off on that exposure. I present all three with their numbers and recommend combining the timeout fix with the gradual ramp, since together they protect the SLO without blocking the launch. The SLO-adjustment option stays on the table as the fallback if the fix cannot land in time and leadership still decides the business case justifies the exposure.

Trade-offs and pitfalls

Treating "obstructive" as purely a communication problem when the SLO is genuinely stale, or purely a technical problem when it is really a trust gap, misdiagnoses which one I actually have and wastes the negotiation. Quietly loosening guardrails to avoid conflict without ever formally renegotiating the SLO erases the reliability contract without anyone agreeing to that erosion. Guardrails add engineering time and complexity, so for a small, low-traffic feature that overhead may not be worth it; the guardrail investment should match the actual blast radius. Finally, changing the SLO under launch pressure and never revisiting it afterward lets a one-time exception quietly become the new permanent bar.

Direct answer

I take the manager's underlying concern seriously, that outcomes need consequences and the process should not feel like nothing happens after a mistake, while defending the specific mechanism, no individual blame during the review, that makes blameless postmortems actually surface the truth. I adapt the process to add real accountability where it is legitimately missing, without reintroducing blame that would make people stop reporting honestly.

Structured elaboration

Reconcile the feedback. I find out what specifically reads as "too lenient" to the manager: is it that no one seems personally accountable, that repeat incidents are not being tracked, that the review does not feel consequential. This is usually not actually a request to punish someone, it is a request for visible accountability, which a blameless process can provide without individual blame.

Defend the blameless approach through its mechanism, not just its philosophy. A blameless postmortem, a factual, no-individual-blame review of what happened and why, exists because when people expect punishment for surfacing a mistake, they hide details, self-censor timelines, or avoid reporting near-misses at all, which makes the next outage more likely, not less. The goal is to fix the system that let a competent, well-intentioned person make the error, since blaming one individual usually does not prevent a different person from hitting the same gap later.

Distinguish blameless from consequence-free. Blamelessness applies to how the postmortem investigation itself is run, it does not mean there is never any individual accountability anywhere. A pattern of repeated negligence, ignoring a known process, or a genuine performance issue is a separate management conversation, handled outside the blameless postmortem, not folded into it.

Adapt the process to meet the management need. I add explicit tracking of remediation items with named owners and deadlines, so "nothing happens afterward" becomes visibly false, a recurring review of whether fixes actually landed, and a clear escalation path for the rare case that turns out to be about individual conduct rather than a systemic gap, routed to management directly rather than folded into the blameless review.

Worked example

After an outage, the postmortem concludes the cause was a manual deploy step that skipped a safety check, performed by an on-call engineer under time pressure. The senior manager says: "no one is being held accountable, that engineer just gets a pass."

Reconciling: I ask what accountability would look like to them specifically. They say they want confidence this will not happen again and some sense that skipping steps has consequences. Defending the mechanism: "if we punish the engineer here, the next person under similar pressure has an incentive to hide that they skipped the step rather than report it, which is worse for us. The system let a careful person make this mistake under pressure, that's the actual fix target." Adapting the process: I add a tracked remediation item, automating the safety check so it cannot be skipped manually, with a named owner and a two-week deadline, plus a follow-up review to confirm it shipped and actually blocks the bypass. I also clarify with the manager: if this had instead been a case of someone repeatedly and knowingly ignoring the process despite training, that is a distinct conversation for them to have directly with that person, separate from how the postmortem itself is run.

Trade-offs and pitfalls

Capitulating and quietly naming the individual at fault in the postmortem to placate the manager undermines the psychological safety, people staying willing to report mistakes honestly without fear of punishment, that the process depends on, and teaches the whole team to hide details next time. Refusing to adapt the process at all, and treating the manager's concern as illegitimate, leaves a real gap, visible accountability, unaddressed. Adding remediation tracking and follow-up review is more process overhead, worth it because it is what actually answers the "nothing happens" complaint without compromising the blameless mechanism. Conflating "no individual blame in the postmortem" with "no individual accountability ever" is the exact distinction most likely to get lost under pressure from someone senior.

Direct answer

A manager saying to delegate more technical tasks in order to focus on strategy is feedback that the candidate has become a bottleneck, not a comment on the quality of their technical judgment, and the right reaction is to accept that framing rather than treat delegation as giving up ownership. From there: identify concrete tasks or decisions to hand off, pick who's ready to grow into each one, actively coach them through the handoff rather than disappearing once it's delegated, and track concrete signals, including throughput on the delegated work itself, that the team is absorbing the responsibility well.

Structured elaboration

React to the underlying signal, not just the instruction. The feedback usually means the candidate's time on execution-level work is the limiting factor on higher-leverage strategic work getting done. Recognizing that framing, rather than hearing it as "you're being replaced," is what makes the rest of the response constructive instead of defensive.

Take concrete delegation steps. Inventory the recurring tasks or decisions currently funneled through the candidate personally. For each one, identify a team member for whom taking it on is a genuine stretch opportunity, not just an available body. Delegate with context, not just a task handed off: explain why the task matters, define exactly what decision authority is being transferred, and set an explicit check-in cadence so the handoff doesn't become a silent abdication.

Coach through it rather than walking away. Pair closely on the first few instances, review key decisions together before stepping back, and gradually reduce oversight as the person demonstrates they've got it. Delegation that isn't coached tends to either produce a quality drop (used against the feedback the candidate was trying to act on) or quietly get pulled back once something goes slightly wrong.

Track outcomes, including a real throughput signal. Watch whether decisions in the delegated area are reaching the same quality bar without the candidate personally reviewing every one, and track something concrete like how many of those decisions per week no longer wait on the candidate's calendar at all, not just a general sense that things feel smoother. Watch whether the candidate is genuinely spending freed-up time on the strategic work the manager wanted, not just filling it with other execution work.

Worked example

An architect who has been personally reviewing every design document gets feedback that this habit is bottlenecking both the review queue and their own time for higher-level architecture strategy. Rather than treating that as a demotion of technical involvement, first-pass design review gets delegated to two senior engineers on a rotation. Each is paired with the architect on their first several reviews, walking through what to look for and why, before reviewing independently with only spot checks. The architect retains only escalation-worthy or cross-cutting reviews. Over the following months, design reviews that used to sit in the architect's queue for most of a week now turn around in a day or two, because they no longer wait on one person's calendar. The two engineers doing reviews visibly grow into architecture-adjacent judgment, and the architect now has dedicated, protected time for the roadmap work the manager's feedback was pointing at.

Trade-offs and pitfalls

Delegating only low-value busywork while keeping every meaningful decision personally reviewed doesn't actually address the feedback, even though it looks like compliance on the surface. Delegating and then disappearing, with no coaching or check-in cadence, risks a real quality drop that undermines the case for having delegated at all. The other common failure is treating delegation as a one-time act rather than an ongoing recalibration; what's appropriate to hand off changes as the team grows, and revisiting that periodically is part of taking the original feedback seriously rather than a box checked once.

Direct answer

I separate fixing the bug from evaluating the criticism, since the first is urgent and does not wait on the second. I investigate immediately to understand what actually broke, then look at what testing existed for that specific path before agreeing or disagreeing that rigor was the gap, and either way I put a concrete prevention measure in place afterward.

Structured elaboration

Immediate steps to investigate the bug. Reproduce the bug, identify the specific code path and condition that triggers it, check severity and blast radius, how many users or how much data is affected, and put a mitigation in place, a rollback, a feature flag off, a hotfix, before doing a full root cause analysis. Stopping the immediate damage comes before assigning cause.

Deciding whether to accept or push back on the testing-rigor criticism. I check what tests actually existed for the affected path. If nothing covered this exact scenario, and it is a scenario that reasonably should have been covered, a common input or a known edge case, the criticism is fair, and I say so directly. If the bug comes from a genuinely unexpected combination of conditions that would not reasonably be anticipated, or from something outside test scope entirely, a third-party API change, an infrastructure issue, a data pattern that did not exist when the feature shipped, I push back with the specific evidence rather than accepting blame that is not accurate. I try to distinguish "insufficient coverage" from "a bug slipped through despite reasonable coverage," since perfect coverage is not realistic and conflating the two teaches the wrong lesson.

Preventing similar issues in the future. I add the specific missing test case, then look one level broader: is this an isolated gap, or a whole category of scenario, for example all boundary conditions on this type of input, that is systematically under-tested. If it is a category, I prioritize closing the category, not just this one instance.

Worked example

A stakeholder reports users are seeing incorrect account balances after a batch update job runs. Immediate steps: reproduce against a copy of the affected data, find the trigger, a rounding error that only appears when a user has more than a specific number of transactions in a single batch cycle, confirm blast radius (roughly 2% of accounts cross that threshold), and ship a hotfix correcting the rounding while a full root-cause review continues.

Testing-rigor question: checking the existing tests shows there was a unit test for the rounding logic, but it only used small transaction counts, well below the threshold that triggers the bug. The specific scenario genuinely was not covered, and reasonably should have been, since batch sizes above that threshold are not unusual. I accept the criticism: "you're right, our test suite didn't cover high-volume batches for this path, that's a real gap." Prevention: I add a test case at and above the threshold, then audit the other batch-processing paths in the same module for the same class of gap, untested behavior at high transaction counts, finding and fixing two more before they cause a separate incident.

Trade-offs and pitfalls

Investigating the criticism before fixing the bug delays mitigation while the production issue is still live. Accepting all blame reflexively, to appear accountable, even when the evidence shows the gap was not really about testing rigor, hides the actual root cause and can misdirect future prevention effort. Pushing back defensively without first checking the actual test coverage risks denying a real gap. Broadening the prevention fix to a whole category of untested scenarios costs more time than patching just the one case, worth it when the category, not just the instance, is genuinely under-tested.

Direct answer

Feedback that challenges a core assumption stings more than a detail-level correction because it threatens the whole plan you've invested in, not one line of it. The discipline is separating "how much work I've put in" from "whether the assumption is actually still true," and evaluating the challenge on evidence rather than on how costly it would be to admit you're wrong.

Structured elaboration

1. Reacting personally in the moment. Name it, at least to yourself, that a core-assumption challenge feels bigger than a detail challenge because more is genuinely at stake: sunk time, a plan already communicated to others. That recognition helps you avoid conflating "this is uncomfortable" with "this is wrong."
2. Evaluating whether it's right. Go back to why you made the original assumption, what evidence or context it was based on, and ask whether the challenger has new information or is reading the same information differently. This is different from a detail-level fix, since you may need to re-derive from the assumption forward rather than patch one component.
3. What changes. Ranges from a full pivot, if the assumption really doesn't hold, to a scoped adjustment, if part of it holds and part doesn't, to a respectful, evidence-based defense of the original assumption, if it genuinely still holds. The size of the challenge doesn't automatically determine the size of the correct response.

Worked example

I proposed a caching layer built on the assumption that read traffic was overwhelmingly for recent data, that most requests hit the last 24 hours. A colleague challenged that core assumption directly, arguing a meaningful chunk of traffic was from a batch reporting job pulling much older records, which would make my cache design ineffective for a large share of real traffic. My first internal reaction was defensive, since the whole design rested on that assumption. I went back to the actual traffic logs rather than my memory of them, and the challenge held: a substantial share of read volume was from that older-data batch job, which I'd missed because I'd looked at request count by hour and hadn't separated it by data age. That changed the design meaningfully, not just a tuning parameter: I split the cache into a hot-recent tier and a separate warm tier sized for the batch job's access pattern, instead of one undifferentiated cache.

Trade-offs and pitfalls

Treating a core-assumption challenge as automatically requiring a full scrap-and-restart is as much a mistake as reflexively defending the original assumption; sometimes checking the evidence confirms the assumption was right and the challenge was based on a misunderstanding, and defending it calmly with the evidence is the correct, non-defensive response. The amount of prior investment in the original plan is not evidence about whether the assumption is true, and letting sunk cost drive the evaluation is the single most common failure mode here. Re-deriving from the challenged assumption forward, rather than only patching downstream symptoms, is what separates a genuine reassessment from a surface fix that leaves the same flawed foundation underneath.