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?
Talking to more than 30 engineers before building probably saved you from developing features based on assumptions. The interesting part is usually not only what users request, but which problems appear repeatedly and which ones they are already trying to solve with manual workarounds. I’d love to know whether the conversations changed the product completely or simply helped you narrow the scope and choose a better starting point.
Strong pattern. One thing I’d add to the interview loop: ask each person to replay the last real incident minute by minute, then mark where trust broke down. The product shape usually shows up in those handoff moments, not in the abstract wishlist.
The part I'd keep is the line about documenting every interview before you build. While building DictaFlow, I started doing a two-minute spoken debrief right after each call. I covered what surprised me, what workaround they use today, and whether the pain came up on its own. Those unprompted mentions are usually more useful than a pile of polite agreement.
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.
This is exactly the tension I'm trying to work through.
I don't want Gnobu to become another layer that simply surfaces more incident context. If teams already have the information but still spend the first few minutes debating what it means, who should act, or whether the ownership is actually correct, then better information alone isn't enough.
The distinction I'm starting to pay more attention to is:
information → shared understanding → decision → ownership → action
The research so far seems to suggest that the expensive gap is somewhere between shared understanding and action, particularly when ownership isn't trusted.
Your point about asking what appears most often unprompted is also something I'm going back through the interviews to measure rather than assume.
So I'm going to keep testing whether ownership and decision-making are actually the strongest recurring signals before I build further around them.
"The gap between shared understanding and action, when ownership isn't trusted" is the sharpest phrase you've landed on. That last clause is everything. It's not that ownership is unclear, it's untrusted, people know who's nominally responsible and still hesitate because they don't trust the assignment holds under pressure. Far more specific and defensible than "coordination."
Why it's the richest wedge of the five: it's the one that's purely a trust/decision problem, not an information one. You can't fix it by surfacing more data, which is exactly why observability tools can't touch it and why it's underserved. Solve trusted ownership and the rest of the chain unblocks itself.
One tip re-reading the interviews: weight the emotional ones heaviest. The signal described with a war story ("we lost 40 minutes because nobody would call it") is closer to real pain than the one listed flatly. That heat is your ranking as much as raw frequency.
Nailing which signal is the true wedge before building is exactly what I spend my time on, part of the team building Hivemind, an AI strategy copilot. If you want to pressure-test the ownership-vs-context call once you've re-scored: https://hivemind.myosin.xyz
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.