in practice 'role' diffuses - two people share it, each feels half the pressure, which lands as neither answers. the sting of naming someone specific is exactly the point.
someone specific — not "the team", not a role. the line in the doc that reads: "if this agent does something wrong, [name] answers." written before deployment, not filled in during the post-mortem. most setups skip that line. that's the gap.
I see where you're coming from and agree with the principle of being specific about identifying what needs to happen when something goes wrong. Personally I'd prefer it not to be [name] but [role|team|runbook|process].
Specifying [name] creates key person risk, but I guess this all depends on the organizational context.
firsthand experience matters. but redesigning the process without naming who owns failure just moves the risk around.
being on the field isn't the same as having a named failure owner.
Mind sharing a bit more on what you mean by "having a named failure owner"?
fair. [role] works when the role has one clear owner. [name] is a forcing function to verify that before deployment, not after.
fair on key person risk.
in practice 'role' diffuses - two people share it, each feels half the pressure, which lands as neither answers. the sting of naming someone specific is exactly the point.
someone specific — not "the team", not a role. the line in the doc that reads: "if this agent does something wrong, [name] answers." written before deployment, not filled in during the post-mortem. most setups skip that line. that's the gap.
I see where you're coming from and agree with the principle of being specific about identifying what needs to happen when something goes wrong. Personally I'd prefer it not to be [name] but [role|team|runbook|process].
Specifying [name] creates key person risk, but I guess this all depends on the organizational context.