I learned something permanent in my first programming job that most executives are missing today: you don’t touch the system until you understand the system.
When you worked on mainframes in the 80s and 90s, this wasn’t philosophy—it was discipline. Those machines ran everything. Banking transactions. Payroll for thousands. Supply chains. One mistake could cost millions or shut down operations entirely.
So before you changed a single line of CICS code, you mapped dependencies. You documented workflows. You talked to the people actually using the system—not just the managers who thought they knew what was happening. You understood the processes before you touched the technology.
This discipline has disappeared, and it’s costing some companies everything.
What Happens When You Stop First
Organizations that take inventory before buying technology make fundamentally different decisions:
They discover the real problem isn’t technology at all. Half the time, you find out the issue is a training gap, an unclear approval chain, or two departments using different definitions for the same term. A $200,000 software purchase becomes a $5,000 process documentation project.
They buy solutions that actually fit. When you map your current workflows first, you stop falling for demos that showcase features you’ll never use. You ask better questions. You recognize when a vendor is selling you their roadmap instead of your solution.
They get adoption that actually sticks. People resist new technology when it disrupts processes they’ve perfected over years. But when you involve them in the assessment phase, they become advocates instead of resistors. They see their input reflected in the solution.
They avoid expensive do-overs. I’ve watched companies spend six figures on CRM systems they abandon within 18 months because nobody stopped to ask: “How do our salespeople actually work? What do they need to see at point of sale? Who else touches this customer data?” The technology wasn’t wrong—it just didn’t match the reality of how humans were operating.
What Happens When You Don’t
The cost of skipping assessment isn’t just wasted money—it’s compounded damage:
You layer dysfunction. Bad processes don’t disappear when you automate them. They just happen faster and at greater scale. That approval bottleneck you had with email? Now it’s a bottleneck in your $300,000 project management system, except you’ve locked in a three-year contract.
You create shadow systems. When official technology doesn’t match how people actually work, they build workarounds. Spreadsheets. Shared drives. Text message chains. Now you’ve got the expensive system nobody uses AND the chaotic alternatives you can’t control.
You lose organizational trust. Every failed technology implementation makes the next one harder. People stop believing leadership understands their work. They stop participating in future initiatives. You’ve bought yourself cultural debt that takes years to repair.
You make decisions in the dark. Without baseline metrics from your current state, you can’t measure if the new technology actually improved anything. Vendors promise 30% efficiency gains, but you have no idea what you’re currently spending on the process, so you’ll never know if you got what you paid for.
The Mainframe Mindset for Modern Leaders
Here’s what that early training taught me that still applies today:
Respect the system that’s running. Even if it looks messy or outdated, it’s keeping your business operational right now. Before you disrupt it, understand why it evolved this way. There’s usually logic buried in there, even if it’s not documented.
Talk to the people closest to the work. The executive summary version of how things operate is almost always wrong. The people doing the daily work know where the friction is, where the workarounds are, where the risk actually lives.
Document before you disrupt. You need a baseline. Not just for comparison later, but because the act of mapping current state reveals dependencies and complications you couldn’t see from the surface.
Test your assumptions. In mainframe work, we had dev environments and UAT and staged rollouts because the cost of being wrong was too high. Somehow in the cloud era, companies think they can skip all that and just flip the switch.
This isn’t about being slow or risk-averse. It’s about being expensive exactly once instead of being expensive twice—first on the wrong solution, then on the right one after you’ve learned the hard way.
The S.T.O.P. Method™ Framework
This is why I built my consulting practice around one principle: Selecting Technology while Optimizing Processes.
You can’t do one without the other. And you have to optimize processes first—not after you’ve already committed to the technology.
When organizations bring me in before they buy, we map three things:
- Who actually touches this process and what do they need it to do
- What’s the measurable cost of the current state
- What constraints and dependencies exist that the vendor doesn’t know about
Then—and only then—do we look at technology options. And suddenly the decision becomes obvious.
The mainframe era forced this discipline because the stakes were visible and immediate. Today’s stakes are just as high—they’re just distributed across cloud costs, subscription waste, and failed implementations that leaders write off as “change management issues.”
It’s not a change management issue. It’s a didn’t-stop-to-understand-first issue.
And unlike the mainframe days, you don’t have to figure this out alone. You just need someone who remembers that technology serves the process—not the other way around.
Marlin Williams spent 30+ years in technology leadership, starting as a mainframe programmer and progressing to C-suite roles including Deputy CIO for the City of Detroit and Chief Program Officer at TechTown Detroit. She now helps organizations avoid expensive technology mistakes through her S.T.O.P. Method™ consulting methodology at Marlin Williams Enterprises.