40+ engineering conversations changed what I think happens after detection
Over the past few months, I've been talking with SREs, DevOps engineers, cloud architects, security professionals, incident managers, engineering leaders, enterprise architects, and other people who deal with production systems.
I've now had 40+ conversations.
One thing keeps becoming harder to ignore:
Detection may not be the end of the problem. It may be where a different problem begins.
Modern systems can generate an enormous amount of information when something goes wrong.
Logs.
Metrics.
Traces.
Alerts.
Security signals.
Service dependencies.
But having more signals doesn't necessarily mean a team can act faster.
Across the conversations, I'm increasingly seeing a sequence like this:
Detection
↓
Context
↓
Ownership
↓
Coordination
↓
Action
The interesting part is what happens between those stages.
A team can detect an incident quickly but still spend time figuring out:
- What is actually happening?
- Which signals can we trust?
- What changed?
- Which system is really affected?
- Who owns the response?
- Which teams need to coordinate?
- What should happen next?
And several conversations have pointed to something particularly interesting:
Once the right owner is identified, deciding and executing the remediation often becomes much easier.
That makes me wonder whether we're sometimes measuring the wrong part of the incident.
We measure detection time.
We measure MTTR.
We measure alert volume.
We measure system availability.
But what about the time between:
"Something is wrong."
and
"We understand what is happening, we know who owns it, and we agree on what to do."
I'm starting to think that gap deserves much more attention.
I don't have a product conclusion yet.
That's actually why I'm continuing the research.
I'm trying to understand whether this is:
- primarily an observability problem,
- primarily a coordination problem,
- primarily an ownership problem,
- or a combination of all three.
For those of you who have handled real production incidents:
Where does the most expensive delay usually occur after detection?
Understanding the situation, finding the owner, coordinating the teams, or deciding what action to take?
40+ conversations is enough to start seeing patterns, but also enough for different incident types and organizations to blur together.
When you separate the conversations where the delay was genuinely expensive, are you seeing the same bottleneck recur across them, or does the dominant problem change depending on the environment?
That's a fair distinction. I'm starting to separate the conversations by role, incident context, and where the delay actually occurred rather than treating all 40+ responses as one dataset.
The interesting thing so far is that the wording changes by environment, but ownership and shared understanding keep appearing across very different roles.
I'm still testing whether that's a genuine recurring bottleneck or simply a pattern in the sample.
That’s helpful context. The distinction between a recurring bottleneck and a pattern that only appears in a specific sample is an interesting one.
I’d like to continue the conversation outside the thread. What’s the best email to reach you on?
Sure, happy to continue the conversation.
You can reach me at gnobu.research.gmail.com. It would be great to compare notes on the patterns you're seeing around ownership and incident boundaries.
Thanks! I’ve just sent it over.
Looking forward to hearing your thoughts whenever you have a chance.
From what you're describing, the most expensive delay is usually ownership — not because nobody cares, but because in complex systems nobody is completely sure who owns the boundary where the incident lives. Coordination can't start until that's resolved.
That's an interesting distinction especially the point about ownership becoming difficult at system boundaries.
When nobody is completely sure who owns that boundary, what have you seen work best in practice: a clear service-to-team mapping, an incident commander making the call, or something else?