Building only after research: what 30+ engineering conversations changed
Over the past few months, I've intentionally avoided writing large amounts of code.
Instead, I've spent my time talking to engineering leaders, SREs, DevOps engineers, platform engineers, security specialists, architects, incident managers, and software engineers.
More than 30 conversations later, something interesting has happened.
The answers are remarkably consistent.
I initially thought the biggest operational problem might be monitoring or alerting.
It wasn't.
Most engineers told me modern observability is already good enough to detect problems.
The real friction begins after detection.
Different people described it in different ways:
- understanding what is actually happening
- noisy signals
- missing context
- ownership ambiguity
- communication between teams
- coordinating action
- proving the business outcome is actually correct
The wording changed.
The pattern didn't.
One SRE explained that understanding the issue often takes longer than fixing it.
An incident manager said a large portion of delays comes from aligning on what is happening, who owns it, and what actions are needed.
A distributed systems architect introduced another perspective: systems can be technically correct while still producing the wrong business outcome.
A cloud architect pointed out that teams only begin trusting automation after it repeatedly proves itself over time.
These conversations changed how I'm thinking about the product I'm building.
Instead of asking, "How can we detect incidents better?"
I'm asking:
"How can systems help people understand, coordinate, and act with confidence once something has already been detected?"
I'm documenting every interview before building because I'd rather have evidence than assumptions.
I'm curious:
If you've worked on distributed systems, DevOps, platform engineering, or infrastructure, what's one operational lesson you only learned after handling real production incidents?
The shift from "detect better" to "understand, coordinate, act with confidence" is the insight that separates tools from systems. It's why so many observability platforms accumulate features without solving the core friction - they're solving the technical detection problem which is already solved, when the expensive part is organizational: who owns it, what do we do, who do we tell. That trust-building comment about automation needing to prove itself repeatedly is critical too - teams won't delegate incident response to even perfect automation until they've watched it handle chaos successfully multiple times. Have you found patterns in which teams handle post-incident coordination best?
good artilce
The finding is sharp, and it lines up with what we circled last time (the ownership-ambiguity-at-handoff thread). "Detection is solved, the friction is everything after" is the right cut, and bigger than it sounds: the whole category optimized the wrong half. Everyone built better detection because detection is measurable and buildable. Understanding, coordinating, acting are messy and hard to productize, so they got ignored. That's where an underserved wedge lives.
But there's a trap in your own list. Look at what interviewees described: noisy signals, missing context, ownership ambiguity, cross-team communication, coordinating action. Most aren't information problems, they're coordination problems. And coordination is hard to solve with software, because the bottleneck isn't data, it's humans aligning under pressure. The graveyard of incident-response tools is full of products that surfaced more context and assumed it would fix coordination. It usually doesn't, because people already had the context, they just hadn't agreed on who acts.
So the question under your reframe: are you building something that gives information (crowded, observability already does it), or something that drives coordination and decision (rare, hard, valuable)? "Help people understand" leans information. "Help people coordinate and act with confidence" leans decision. Different products, and the second is more defensible.
To your question, the lesson I only learned from real incidents: technical resolution is often the fast part, and the expensive delay is social, waiting for the person who knows, arguing about whether to roll back, nobody owning the call. The tool that shortens that isn't more dashboards, it's whatever makes ownership and the decision unambiguous in the moment. That maps to your "ownership ambiguity" signal, chase that hardest.
Which of the seven did you hear most, unprompted? That frequency is your ranking, probably ownership or context.
I like that the conversations didn't just validate an idea—they changed the question you were trying to answer.
That's usually a stronger signal than hearing people agree with your original assumptions.
The shift from detection to understanding feels important. Teams rarely lack signals; they lack a shared, retrievable account of what happened, why it matters, and who owns the next move. One lesson I’ve seen is that incident knowledge becomes valuable only when it survives the incident and can inform the next decision—not when it disappears into chat logs and postmortem folders.
What I enjoyed most about this was watching the problem itself evolve as more conversations came in.
It almost feels like we've become very good at surfacing signals, but we're still learning how to turn those signals into shared understanding. I like that your research changed the question you were trying to answer. To me, that's one of the strongest signs that the research is uncovering something real.