Building a workflow without creating another workflow
Over the past few weeks, I've been researching a problem across SRE, DevOps, platform engineering, incident management, IT operations, and technical project management.
The pattern I've been hearing is fairly consistent:
Teams usually don't lack tools.
They already have monitoring, logs, incident management, ticketing, communication, deployment systems, ownership records, and documentation.
The problem is often what happens between those systems.
Something goes wrong.
A signal appears.
Then someone has to reconstruct:
- What changed?
- What is actually affected?
- Which component is involved?
- What does it depend on?
- Who owns it?
- Does the evidence support that ownership?
- What should happen next?
That reconstruction can require people to move between systems, interpret different pieces of information, and manually establish enough context to act.
Week 1: I deliberately kept the experiment small
Instead of building another large platform, I defined a simple workflow:
SIGNAL
↓
CONTEXT
↓
COMPONENT
↓
DEPENDENCY
↓
OWNERSHIP
↓
EVIDENCE
↓
ACTION
The question wasn't:
"Can I build this?"
The question was:
"Would this actually remove work?"
Week 2: I started turning the workflow into a prototype
I'm building the first version in Bubble using a completely fictional incident.
For example:
Customer checkout failures increase after a downstream service deployment.
I'm manually creating the pieces that would normally exist across different systems:
- alert
- affected service
- dependency
- deployment event
- ownership records
- conflicting evidence
The user then reconstructs the incident step by step.
One part I'm deliberately testing is ownership.
The documented owner might point to one team.
Operational evidence might suggest something different.
Instead of pretending the system knows the answer, the prototype surfaces the conflict and asks the user to review the evidence.
That's important because I'm not trying to create another system that simply declares:
"This is the owner."
I'm testing whether it can help someone understand why that ownership decision makes sense.
But there is a bigger question
I don't want to accidentally build another workflow that teams have to maintain.
The research has repeatedly raised the same adoption concerns:
Does it duplicate existing tools?
Does it create another destination?
Does someone have to manually maintain the context?
Does it add verification work?
Does it interrupt the workflow teams already use?
If the answer is yes, then the prototype may be solving one problem while creating another.
And that's useful to discover now.
What I'm actually testing
The current experiment isn't trying to prove that this is a product.
I'm trying to find out whether reconstructing context in this way can reduce the work between:
Signal → Context → Ownership → Evidence → Action
If it only makes the existing information easier to visualize, that's interesting.
If it actually reduces the time or effort required to reach a decision and take action, that's much more interesting.
And if it adds more work than it removes, that's probably the most valuable result of all.
I'd rather discover that now than build a much larger system around the wrong assumption.
What I'm looking for from other builders
If you work in SRE, DevOps, infrastructure, IT operations, incident management, or technical project management:
What would you remove from this workflow?
And more importantly:
What would convince you that it actually reduces operational work rather than simply organizing the same work differently?
This resonates: the failure mode is usually not missing software but unclear ownership at the handoff. I’ve found it helps to define one trigger, one responsible person, and one “done” artifact before adding automation. A lightweight weekly review of exceptions can keep the workflow small while still exposing where the system is leaking.
Strong framing — the trap is rebuilding Jira/PagerDuty inside Bubble. For the prototype, I’d measure a live-incident baseline: tool-hops, time-to-owner, time-to-action, with existing systems staying source of truth. If those three drop, the reconstruction view is earning its keep; if not, it’s another dashboard people ignore during the fire.
Exactly — I don't want the prototype to become a smaller version of Jira or PagerDuty inside Bubble.
Keeping the existing systems as the source of truth is an important constraint for the experiment.
The three measures you mentioned — tool-hops, time-to-owner, and time-to-action — give me a much clearer way to test whether the reconstruction view is actually earning its place.
If those don't improve, then the view probably isn't reducing enough work to justify another interface.
I have found that the smallest end-to-end test tells me more than another polished workflow. If users cannot complete the core loop manually, the extra system usually hides the friction.
That's a really important test for me.
The “another copy of context” problem is exactly what I don't want the prototype to create.
The live-incident test you mentioned is also where I think the experiment eventually needs to go: can someone move from signal → owner/action with fewer tool-hops and less back-and-forth?
If the answer is no, then making the context prettier isn't enough.
What would you consider a meaningful reduction in tool-hops or back-and-forth to call the experiment successful?
I’d remove anything that asks teams to keep another copy of their context up to date. The real proof would be a live incident where someone gets from signal to owner/action with fewer tool-hops and less back-and-forth. If it only makes the picture prettier, it’s probably another system to maintain.
I agree with that. Keeping another copy of operational context up to date would defeat the purpose.
The live-incident test is also a useful standard for me: if someone still has to make the same tool-hops and have the same back-and-forth, then the prototype hasn't really reduced the work.
That's something I want the experiment to prove rather than assume.
The interesting shift here is that you’re no longer testing whether the workflow can be built, but whether the evidence from using it justifies further commitment to the direction.
Curious where the experiment stands now — are you still primarily trying to generate that evidence, or are you starting to have enough results that the harder question is what those results actually warrant?
Still primarily generating evidence.
I don't think I have enough observations yet to decide what the direction warrants, so I'm keeping the prototype deliberately small and using it to test the underlying workflow first.
The next question for me is whether the experiment produces evidence that justifies going further — or shows that something needs to be removed or changed before I commit more to the direction.