Most broken systems do not announce themselves. They just make good people do weird workarounds until the workaround becomes the job.
Seven years in IT taught me that systems rarely break in one dramatic moment.
They break quietly.
A password lives in someone’s memory instead of a vault. A report depends on one person who knows which spreadsheet is the real one. A ticket gets closed because the immediate symptom stopped, but nobody owns the pattern behind it.
Then one day everyone is surprised that the process failed.
It was failing the whole time. It was just polite about it.
The system is usually telling the truth
People will often describe a system as if it is irrational.
“Why does this keep happening?”
“Why do we always have to chase that down?”
“Why does nobody know where the latest version is?”
Most of the time, the system is not being mysterious. It is telling the truth about how the work is actually designed.
If nobody owns the handoff, the handoff will fail.
If documentation is optional, memory becomes infrastructure.
If every exception becomes a private workaround, the real process disappears.
If nobody wants to decide, the oldest habit wins.
Tickets are symptoms
A ticket queue can teach you a lot if you stop treating every ticket as an isolated event.
One locked account is a locked account.
Ten locked accounts after the same workflow change is a signal.
One missing access request is annoying.
A pattern of missing access requests means the onboarding process is probably asking humans to remember something the system should make obvious.
The ticket is the visible part. The interesting work is underneath it.
What failed before the ticket existed?
The handoff is where truth leaks out
Broken systems love bad handoffs.
A person leaves a role and takes the process with them. A vendor owns one piece, internal staff owns another, and the gap between them becomes a swamp. A manager approves the idea, but nobody defines what “done” means.
That is where the work starts to leak.
Not because people are lazy. Usually they are busy, under-briefed, and carrying too many invisible dependencies.
But the result is the same: the customer, patient, employee, or next person in line feels the failure as friction.
Documentation is not paperwork
I used to think documentation was something you did after the real work.
That is wrong.
Documentation is part of the system.
Not the giant binder nobody opens. Not the 40-page artifact written to prove compliance and then abandoned. I mean the useful version:
- Who owns this?
- What triggers it?
- What does good look like?
- Where does the request go?
- What breaks if this person is out?
If those answers are not written somewhere reachable, the process is more fragile than it looks.
Business analysis is not just requirements
This is where IT work and business analysis meet.
A requirement is not just “the user needs a button.”
Sometimes the real requirement is: this team needs a decision. This process needs an owner. This report needs one source of truth. This handoff needs to stop depending on someone remembering to send a message at 4:55 p.m.
The work is not only collecting what people ask for.
The work is finding where the system lies.
It lies when the policy says one thing and the daily workaround says another.
It lies when a dashboard looks clean because the messy work happened before the data arrived.
It lies when leadership thinks the process is automated, but three people are manually holding it together in the background.
The quiet fix
The fix is not always a new platform.
Sometimes the fix is naming the owner.
Sometimes it is deleting a duplicate step.
Sometimes it is writing the boring checklist everyone assumed someone else had already written.
Sometimes it is asking, in a calm voice, “What happens when the one person who knows this is unavailable?”
That question makes fragile systems uncomfortable because it exposes the dependency they were pretending not to have.
What I learned
After enough years around tickets, outages, reports, access requests, and undocumented workflows, I stopped believing that broken systems are usually caused by one bad actor.
More often, they are caused by missing ownership, unclear handoffs, and small decisions nobody made on purpose.
That is fixable.
Not always quickly. Not always with applause. But fixable.
You start by writing down what is actually happening. Then you find the fault line. Then you make one part of the system less dependent on luck.
That is not glamorous work.
It is useful work.
— The Operator