A lot of operational pain gets misdiagnosed as a tooling problem or a headcount problem.

At small scale, experienced people can often bridge the gaps. They remember the exceptions, know which signals matter, spot what needs doing next, and carry a lot of context in their heads.

That works for a while.

But as volume, variation, and operational pressure increase, that model starts to break. What looked manageable with smart people and a few workarounds becomes fragile, inconsistent, and hard to scale.

That is usually the point where better screens alone stop being enough.

The real shift is making the workflow itself clearer:

what state something is in
why it is there
what actions are valid
what should likely happen next

What’s changed for me is the design starting point.

I’m thinking less about how to help humans carry more workflow complexity, and more about how to structure workflows so the system itself can understand, guide, and gradually absorb more of that load.

I’ve started applying that thinking in a greenfield project first, where it’s easier to design the workflow explicitly from day one rather than layer it into years of existing logic — then gradually bring those lessons back into the monolith, with all of its structural and legacy debt.

That shift in mindset is starting to change how I think about operational software more broadly.

That is where the real leverage starts.