When I think back over 20-plus years of being responsible for technology inside operating businesses, the problems that cost the most rarely looked like outages.
Outages are loud. Everyone knows the system is down, someone owns the fix, and there’s a clear moment when it’s over.
The expensive problems were quieter. Every system was up. Every team was working. And the work still wasn’t moving the way anyone expected.
It took me a while to learn where to look for those.
The seams, not the systems
Most operations run on a set of applications that each do their own job reasonably well. One tracks customers or patients. One is the operational system of record. Finance has its platform. Somewhere there’s a document system, a portal or two, and a set of spreadsheets that exist because something important didn’t fit anywhere else.
Work doesn’t live in any one of them. It moves across them — and across the teams that use them.
That movement is where I’ve found most of the friction. Not inside the applications, but in the seams between them.
Four places I’ve learned to look
1. Where work changes shape. Every time information crosses from one system or team to another, it gets translated — re-keyed, reformatted, summarized, interpreted. A document becomes a set of fields. One system’s code becomes another system’s category. Each translation is a chance for delay, for error, or for a question that has to travel back upstream. The more times a piece of work changes shape, the more places it can quietly slow down.
2. Where the same fact lives in more than one place. An address. A status. An eligibility answer. A due date. When the same fact is stored in several systems, sooner or later they disagree, and someone has to decide which one is right. That reconciliation is real work, and it rarely appears in anyone’s job description.
3. Where the data arrives after the decision. Many organizations have plenty of data. The problem is timing. The report that explains last month doesn’t help the supervisor deciding what to work on this morning. When operational data moves on a reporting schedule instead of the operation’s schedule, people fill the gap by asking around — and asking around doesn’t scale.
4. Where an exception belongs to two teams. Routine work usually has a clear path. Exceptions don’t. When a problem sits across a system boundary or a team boundary, it’s easy for everyone to reasonably assume someone else has it. The work doesn’t stop because anyone is careless. It stops because ownership of that situation was never designed.
Why another application often doesn’t fix it
When friction shows up, the natural reaction is to look for better software. Sometimes that’s the right call. But if the problem lives in the seams, a new application can add one more seam: another place for the same fact to live, another translation, another boundary for exceptions to cross.
I’ve come to believe the first question isn’t “what should we buy?” It’s “what path does this work actually take, and where does it wait?”
What I’d do first
A few principles I rely on now — most of them learned through years of operating and supporting these environments:
- Map the path of the work before choosing tools. Follow one real piece of work from the moment it enters to the moment it’s done. Note every system it touches, every team that handles it, and every place it waits.
- Decide where each important fact is authoritative. Not every system needs every piece of data. Everyone needs to know which one to trust.
- Make handoffs observable. If you can’t see where work is between teams, you’ll end up rebuilding that picture by hand — usually in a meeting.
- Move data on the operation’s clock. The people making today’s decisions need today’s information, not a monthly summary.
- Design for exceptions, not just the happy path. Decide in advance who owns the cases that don’t fit.
- Carry security and controls with the work. Every connection between systems is also a question about access, evidence and recovery. Those questions are easier to answer while designing the flow than after it’s live.
Where technology fits
Only after that does the technology conversation get useful. Connecting systems so work moves between them without being re-keyed — that’s workflow orchestration. Making data dependable and timely enough to run the operation — that’s data engineering and data orchestration. And in some places, adding AI to read, classify or summarize — where the process and data underneath are solid enough to support it.
That order matters. It’s also why I built Wiles Ridge Automations the way I did: the operating problem first, the technology second, and the systems a business already depends on treated as assets rather than obstacles.
One exercise for this week
Pick one piece of work that matters to your operation. Walk it end to end — not the way the process document describes it, but the way it actually happens.
Count how many times it changes systems. Count how many times it changes hands. Then mark where it waited, and whether anyone could have told you it was waiting.
That list is usually a better starting point than any software demo.