Stop Calling Every Old System "Legacy"

There’s a word in technology that I think we use far too casually: legacy. A system has been around for ten years? Legacy. It uses an older programming language? Legacy. The interface looks dated? Definitely legacy. Someone joins the company, sees technology they wouldn’t choose if they were starting today, and suddenly the conversation becomes, “We need to replace this.”

Maybe we do. But I think we need to be careful about confusing old technology with unhealthy technology. They aren't necessarily the same thing.

Old Doesn't Automatically Mean Broken

I've worked around technology long enough to remember plenty of platforms, programming languages, databases, operating systems, and architectural approaches that were once considered modern. Eventually, everything becomes old. That doesn't mean it stops working.

There are systems running businesses today that have been operating successfully for ten, fifteen, twenty years or longer. They process transactions, manage customers, handle complex business rules, integrate with other platforms, and generate revenue every single day. Some of them aren't pretty, and some certainly need modernization, but age alone isn't a business case for replacement.

The question shouldn't be “How old is it?” The question should be “Is it preventing us from going where we need to go?”

Sometimes Old Software Is Old Because It Works

Software that has survived for fifteen years has probably encountered an enormous number of real-world situations. Customers found edge cases. Developers fixed bugs. Business rules changed. Regulations changed. Integrations evolved. Production failures taught the organization lessons.

Multiply that by thousands of changes over many years and something interesting happens. The old system becomes more than source code. It becomes a record of what the business has learned.

The problem is that much of that knowledge may never have made it into formal documentation. It's simply in the software.

The Ugly Code Might Be Trying to Tell You Something

Every experienced developer has opened a piece of code and wondered, “Why on earth did somebody do it this way?” Sometimes the answer really is poor design. But sometimes there was a very good reason.

Maybe a major customer required something unusual. Maybe an external system behaved differently ten years ago. Maybe there was a regulatory requirement. Maybe someone discovered a production edge case at 2:00 in the morning and fixed something that prevented a serious business problem.

Years later, the comment is gone. The developer is gone. The ticket may be gone. The code remains.

That's why I get nervous when someone looks at an established platform and immediately concludes, “This is terrible. Let's rewrite it.” Before removing something we don't understand, perhaps the first question should be: “Why is it here?”

Modern Technology Can Still Produce Bad Software

We sometimes assume that replacing an older platform with modern technology automatically creates a better product. It doesn't.

You can build an unmaintainable system using the newest framework available. You can create poor architecture in the cloud. You can build technical debt with microservices. You can automate a bad process. You can create an elegant new user interface sitting on top of poorly understood business logic.

Modern tools give us tremendous capabilities, but technology doesn't compensate for weak product governance, poor architecture, inadequate testing, unclear ownership, or constantly changing priorities. A new technology stack placed inside an unhealthy development organization will eventually become somebody else's legacy platform.

So What Actually Makes a System “Legacy”?

For me, the more useful definition has very little to do with age. I'd start looking seriously at modernization when the platform is creating measurable constraints on the business.

Maybe the technology is no longer supported. Maybe security risks can no longer be reasonably mitigated. Maybe finding people who understand the technology has become increasingly difficult. Maybe integrations with modern systems are becoming impractical. Maybe the architecture prevents the company from scaling. Maybe development velocity has deteriorated to the point where meaningful product changes take far too long. Maybe operating the platform costs significantly more than a modern alternative would.

Those are business problems. “It's old” isn't.

Modernization Doesn't Have to Mean Replacement

The choice doesn't always have to be “keep everything exactly as it is” or “throw everything away and start over.” There's a lot of territory between those two extremes.

You can replace individual components, refactor high-risk areas, introduce APIs around older functionality, improve automated testing, modernize deployment processes, move appropriate workloads to newer infrastructure, improve monitoring, or gradually separate parts of a tightly coupled application.

In other words, modernize intentionally instead of replacing emotionally.

That approach isn't as exciting as announcing a completely new platform, but it can be dramatically less risky.

The Rewrite Has Its Own Technical Debt

One of the ironies of replacing an established system is that the new platform starts accumulating technical debt almost immediately. Requirements change while you're building it. Customers still need features. Business priorities change. Developers make compromises to hit deadlines.

Meanwhile, you're maintaining the existing platform and building its replacement. Now you have two systems, two sets of problems, and potentially two engineering efforts competing for resources.

This doesn't mean rewrites should never happen. Sometimes they absolutely should. It means the decision needs to be based on business constraints and technical evidence rather than frustration with the age of the existing system.

Respect the Knowledge Before You Replace the Technology

I've spent enough years in technology to appreciate new tools. I've also spent enough years in technology to respect old ones.

Before replacing an established system, understand it. Document it. Identify the business rules buried inside it. Understand the integrations. Find the edge cases. Talk to the people who have supported it. Figure out which problems actually come from the technology and which come from the processes surrounding it.

Then decide what needs to change.

Sometimes modernization means building something new. Sometimes it means replacing part of what already exists. And sometimes the smartest decision is improving the system you already have.

Old Isn't the Enemy

Technology should evolve. Platforms should improve. Organizations should continuously modernize. But modernization should have a purpose.

We shouldn't replace systems simply because they're old any more than we should keep them simply because they've always worked. Both can be emotional decisions.

The better question is: “What is preventing this platform from supporting where the business needs to go next?”

If the answer is the technology, modernize it. If the answer is architecture, address the architecture. If the answer is process, fix the process. If the answer is governance, improve governance.

And if the system is still reliable, supportable, secure, scalable, and capable of evolving, maybe calling it “legacy” says more about our perception of the technology than the actual health of the product.

Old software isn't necessarily technical debt. Sometimes it's simply software that survived.

This follows the principle in your original presentation that mature organizations use incremental modernization and targeted refactoring rather than assuming an aging platform automatically requires wholesale replacement.

Thanks,

 

Michael Cronin

Website: https://www.michaelcronin.info

LinkedIn: https://www.linkedin.com/in/michaeltcronin/details/experience/

 

Lessons From 27+ Years in Technology - Part 1 of 3

From Building Houses to Building Technology

I've spent more than 27 years working in technology, and when I look back at where it all started, I'm sometimes amazed at the path that got me here.

My career didn't actually begin in technology. Before I ever wrote code professionally, I was a carpenter building houses in the Washington, D.C. area.

At the same time, I was going to school because I wanted to break into this growing technology industry. I didn't have decades of experience. I didn't have a long list of certifications. I certainly didn't know where the career would eventually take me.

What I had was a willingness to learn, a positive attitude, and the determination to keep pushing forward until someone gave me an opportunity.

Eventually, someone did.

I started working as a Web Developer in the Washington, D.C. area, and it was quite a time to enter the industry. The dot-com boom was underway, businesses were racing to understand this relatively new thing called the Internet, and the world was preparing for Y2K.

Technology was changing incredibly quickly.

Looking back, though, one thing stands out to me about entering the industry during that time.

You weren't necessarily expected to know everything before someone was willing to give you an opportunity.

You needed some skills, of course. But you also needed the ability to learn, the willingness to work, and the persistence to figure things out when you didn't know the answer.

That last part became far more important to my career than I realized at the time.

Technology has a funny way of making today's expertise temporary. Eventually, the language changes. The platform changes. The hardware changes. The methodology changes. Something new comes along and suddenly everyone has something else to learn.

If your entire value is based on knowing a particular technology, eventually that technology is probably going to change.

But knowing how to learn, how to solve problems, and how to keep moving forward when you don't immediately know the answer has a much longer shelf life.

The carpenter who was building houses during the day while trying to find his way into technology couldn't possibly have known what the next 27+ years would bring.

I didn't know that I would eventually work across different industries, technologies, products, and leadership roles. I didn't know how many talented people I would have the opportunity to work with, learn from, mentor, lead, and eventually call friends.

I certainly couldn't have imagined cloud computing, SaaS, modern mobile technology, or artificial intelligence as we know them today.

I was simply trying to get my foot in the door.

Someone eventually opened that door.

The rest was up to me.

More than 27 years later, I think there's still an important lesson in that.

Sometimes potential isn't about everything someone already knows. Sometimes it's about their willingness to learn what they don't.

That willingness helped me move from building houses to building technology.

And as I'll talk about in Part 2, the technology never stopped changing.

Fortunately, neither did my willingness to learn.

Thanks,

 

Michael Cronin

Website: https://www.michaelcronin.info

LinkedIn: https://www.linkedin.com/in/michaeltcronin/details/experience/

 

The Most Expensive Problems Are the Ones We Keep Fixing

There is an interesting trap in IT and software development. Sometimes we get really good at fixing a problem. So good, in fact, that we stop asking why we keep having to fix it.

A ticket comes in. Someone recognizes the issue. They know exactly what SQL query to run, which service to restart, which configuration to change, or which workaround to give the user. Problem solved. Ticket closed. Everyone moves on.

Then it happens again. And again. Eventually, what started as an exception becomes routine. That is when fixing the problem can actually become more expensive than solving it.

We Often Measure the Wrong Thing

Most technology organizations measure things like response time, resolution time, ticket volume, SLA compliance, and backlog size. Those measurements are important, but there is another question we should be asking:

Why did this ticket exist in the first place?

Closing 100 tickets quickly may look great on a dashboard. Preventing 80 of those tickets from ever being created is much better.

Think of it like repeatedly putting water into a leaking bucket. At some point, instead of getting better at filling the bucket, you probably need to fix the leak.

Technology organizations aren't much different.

When the Workaround Becomes the Process

Workarounds aren't necessarily bad. Sometimes they're exactly what we need. Production is down. A customer can't work. A critical process has stopped. You get things running again first. That's responsible operations.

The problem begins when the temporary workaround quietly becomes permanent.

Someone documents the workaround. Someone else learns it. Eventually the support team knows it. Then a new employee is trained on it. Before long, the organization has created an entire business process around something that was never supposed to exist in the first place.

At that point, we've stopped treating the workaround as temporary.

We've designed around the defect.

Tribal Knowledge Can Hide the Real Cost

This becomes even more dangerous when experienced employees make recurring problems look easy.

You've probably heard something like, “Oh, when that happens, just ask John. He knows how to fix it.”

That might sound reassuring, but what happens when John is on vacation? What happens when John leaves the company? More importantly, why does John need to keep fixing it?

Good people often compensate for bad processes. Because they're good at it, the organization sometimes doesn't realize how broken the underlying process actually is.

Every Repeat Has a Cost

One recurring problem might only take 15 minutes to resolve. That doesn't sound significant. But suppose it happens four times a week. That's an hour a week, or roughly 50 hours over the course of a year.

Now multiply that across several employees, environments, customers, or systems.

That still doesn't account for interruptions, context switching, investigation time, customer frustration, QA, management attention, or the opportunity cost of what those people could have been doing instead.

Suddenly, the little 15-minute problem isn't so little anymore.

Recurring problems compound.

The Ticket Should Leave Something Behind

This is why I believe a support or production ticket should produce more than a resolution. Whenever possible, it should leave behind knowledge.

What happened? What was the root cause? How was it diagnosed? What evidence confirmed the problem? What was done to correct it?

And most importantly: What would prevent this from happening again?

Sometimes the answer will be a code change. Sometimes it will be architecture or configuration. Sometimes it will be documentation, monitoring, training, or a better business process.

And sometimes the answer will simply be that fixing it permanently isn't worth the investment. That's okay too. The important thing is that we made that decision intentionally instead of allowing a workaround to become permanent simply because nobody questioned it.

Don't Confuse Activity With Progress

There is something satisfying about closing tickets. You can see the queue getting smaller. You can measure it. You can report it.

But activity and progress aren't always the same thing.

A team that closes 1,000 recurring tickets isn't necessarily performing better than a team that identifies the root causes and prevents 500 of those tickets from ever being created.

One team became better at fixing problems. The other became better at eliminating them.

That's an important distinction.

The Goal Isn't Zero Problems

Software will have defects. Infrastructure will fail. People will make mistakes. Requirements will change. Unexpected things will happen.

That's technology.

The goal isn't to create an environment where nothing ever goes wrong. The goal is to make sure we're learning from the things that do.

Because the most expensive problem isn't always the catastrophic outage everyone remembers. Sometimes it's the tiny problem everyone has learned to live with.

The one we've fixed hundreds of times. The one everyone knows the workaround for. The one nobody stops to question anymore.

Sometimes the most expensive problems are the ones we've become really good at fixing.

Thanks,

 

Michael Cronin

Website: https://www.michaelcronin.info

LinkedIn: https://www.linkedin.com/in/michaeltcronin/details/experience/

 

I've said this before, and I think it is worth repeating: I am a big believer in AI.

I use it. I see tremendous value in it. I believe it is going to fundamentally change how we develop software, operate businesses, support customers, analyze information, and make decisions.

But there is an important difference between using AI as a tool and allowing AI to operate unchecked. That distinction becomes even more important as AI moves beyond simply answering questions and begins taking actions on our behalf.

AI Hallucinations Are Different When Actions Are Involved
We have all seen examples where an AI confidently provides an answer that simply isn’t correct. That is generally referred to as an AI hallucination.

When AI is being used as a research assistant or a thought partner, the consequences can often be managed. A person reviews the response, recognizes something doesn’t look right, verifies the information, and corrects it. That human review is an important part of the process.

But what happens when AI is no longer just recommending what should happen? What happens when it can actually do it?

Imagine an AI system that can modify a database, deploy code, change a firewall rule, disable a user account, send communications to customers, approve a transaction, or modify production infrastructure.

Now a hallucination isn’t simply a wrong answer on a screen. It can become a wrong action.

The Problem Gets Bigger as AI Gets More Access
There is an old principle in IT security called least privilege. You give a person or system only the access necessary to perform its job. There is a reason we have followed that principle for decades.

We learned, sometimes painfully, that convenience and security do not always point in the same direction. The same thinking needs to apply to AI.

If an AI agent has access to email, databases, source code, production environments, financial systems, customer information, and administrative tools, we should be asking some very traditional IT questions:

What does it actually need access to? What actions can it perform without approval? What requires human authorization? What gets logged? Can its actions be reversed? Who is accountable when something goes wrong?

These aren’t new questions. We have been asking them about users, administrators, applications, APIs, and service accounts for decades. AI shouldn’t suddenly be exempt from those same controls.

Human-in-the-Loop Should Not Be Considered a Weakness
There seems to be a race toward making AI completely autonomous. I understand why. The more AI can accomplish without human involvement, the greater the potential efficiency.

But efficiency should not automatically override control.

For high-impact decisions, having a human approve an AI-generated action may be exactly the right architecture. AI can analyze thousands of records. AI can identify patterns. AI can recommend an action. AI can prepare the change. And then a qualified person can review it and say, “Yes, execute.”

That extra step may add a few seconds or minutes to the process. It may also prevent hours, days, or millions of dollars of damage.

Trust, But Verify
That phrase existed long before artificial intelligence, but it may be one of the most important principles we carry forward into the AI era.

AI does not need to be perfect to be incredibly valuable. People aren’t perfect either. That is why mature organizations build controls around important processes.

We use peer reviews. We use change management. We separate development from production. We use approval workflows. We maintain audit logs. We test before deployment. We back things up. We limit administrative access.

AI should fit into those disciplines rather than bypass them.

The Future Should Be AI With Governance, Not AI Without Humans
I don’t believe the answer is slowing down AI adoption. I believe the answer is becoming smarter about how we adopt it.

AI should eliminate repetitive work, accelerate analysis, help developers build better software, help leaders make better-informed decisions, and allow organizations to accomplish things that previously required enormous amounts of time.

But capability and authority are two different things.

Just because an AI system can perform an action doesn’t mean it should always have the authority to perform that action without oversight.

The companies that ultimately get the most value from AI may not be the ones that simply give it the most access. They may be the ones that build the best guardrails around it.

Because the goal shouldn’t be to remove humans from every process. The goal should be to combine what AI does exceptionally well with the judgment, accountability, and experience that people bring to the table.

AI is an extraordinary tool. But like every powerful tool we have introduced into technology over the years, its value will ultimately depend on how responsibly we choose to use it.

Thanks,

 

Michael Cronin

Website: https://www.michaelcronin.info

LinkedIn: https://www.linkedin.com/in/michaeltcronin/details/experience/

 

Writing Code Is Not the Same as Building a SaaS Product

One of the biggest misconceptions in software development is that if someone can write code, they can build a software product. They are not the same thing.

A junior developer may be perfectly capable of taking a requirement and turning it into working code. A senior developer starts asking different questions. What happens when this fails? What happens when 10 users become 10,000? How will we support it? How will we monitor it? How do we upgrade it without breaking customers? What happens to the data? Is it secure? And perhaps most importantly: are we solving the right problem in the first place?

That difference becomes even more important when we talk about websites versus true SaaS applications.

A Website and a SaaS Application Are Different Things

Today, there are fantastic tools that allow someone to create a professional-looking website remarkably quickly. AI has made that even easier. But a good-looking interface is only the front door. A true SaaS application has an entire building behind it.

There are databases, APIs, authentication, authorization, security, logging, monitoring, backups, integrations, deployment pipelines, performance considerations, data retention, disaster recovery, scalability, and ongoing support.

Then comes another layer that is sometimes forgotten entirely: the business. Who is the customer? What problem are we solving? How does the customer actually use the product? What happens when their workflow doesn't match the workflow the development team imagined? And how do we continue improving the product without creating so much technical debt that every future change becomes harder than the last?

Junior Developers Build Features. Senior Developers Think About Consequences.

That isn't meant as criticism of junior developers. Everyone starts somewhere, and good junior developers can become outstanding senior engineers. The difference is often experience.

After you have lived through enough production outages, database problems, failed deployments, security incidents, performance problems, and seemingly "simple" changes that unexpectedly affected something else, you start thinking differently.

Instead of asking, "How do I make this work?" you begin asking, "How do I make this work reliably, securely, sustainably, and at scale?"

That is a very different question.

And Then There Is Product Thinking

Some of the best developers I've worked with don't immediately start coding when you give them a problem. They ask questions.

Why are we doing this? Who needs it? What are they doing today? What problem are we actually trying to solve? Is there already something in the platform that does this? What happens six months from now when the business changes?

Sometimes the best technical decision is not writing more code at all.

That kind of thinking is especially important in SaaS because every shortcut eventually becomes somebody's problem. It might become the support team's problem. It might become an infrastructure problem. It might become a security problem. Or it might become technical debt that the development team spends years trying to unwind.

AI Makes This Distinction Even More Important

AI can now generate remarkably good code. It can build interfaces, APIs, database structures, and even entire applications faster than many of us would have imagined a few years ago. I think that's a tremendous opportunity.

But generating code and engineering a sustainable product are still different things.

AI can help us build faster. Experience helps us understand what should be built, how it should be built, and what could go wrong after we build it.

That is why I don't believe the future belongs simply to the person who can write the most code. It belongs to people who understand systems, customers, operations, and consequences—and who can bring all of those things together.

Because ultimately, the goal isn't to build software that works during the demo.

The goal is to build software that still works when the demo is long forgotten and thousands of customers depend on it.

Thanks,

 

Michael Cronin

Website: https://www.michaelcronin.info

LinkedIn: https://www.linkedin.com/in/michaeltcronin/details/experience/

 

We Spent 20 Years Locking Down Users. Now We're Giving the Keys to AI.

Let me start by making something very clear: I am a huge believer in AI. I use it, I see tremendous value in it, and I think tools like ChatGPT, Claude, Copilot and whatever comes next are going to fundamentally improve how we work.

AI can make people faster, eliminate repetitive work, help us analyze problems, write software, research ideas, improve customer service and automate processes that have frustrated businesses for years. The argument I'm making isn't that AI is bad. The argument is that something this powerful shouldn't be unchecked.

For the last 20-plus years, IT organizations have spent enormous amounts of time limiting what users, applications and systems are allowed to do. We removed local administrator rights, implemented MFA, restricted Remote Desktop, created firewall rules, segmented networks, introduced conditional access, built privileged accounts and implemented change control.

Behind nearly all of those decisions was one very old security principle: Give someone only the access they actually need. Least privilege.

But now something interesting is happening. After spending decades locking everything down, we're beginning to hand increasingly powerful access to AI.

AI Is No Longer Just Answering Questions

When ChatGPT and Claude first appeared, most people interacted with them primarily as assistants. Ask a question, get an answer. Write an email, summarize a document, analyze some code or brainstorm an idea.

We're quickly moving beyond that. AI is becoming agentic. Instead of simply telling us what to do, we're increasingly allowing AI to do things for us.

Give AI access to email. Then calendars. Then OneDrive or Google Drive. Then GitHub. Then the CRM. Then the browser. Then local files, APIs and business applications.

Every one of those connections makes AI more useful, and that's a good thing. But every connection also gives AI more authority.

At some point, AI isn't simply another application. It's another identity inside the business, and potentially a very powerful one.

We've Seen This Movie Before

Anyone who has worked in IT long enough remembers when Remote Desktop was primarily viewed as a convenience. Why drive somewhere when you can remotely connect to the computer?

Remote access wasn't bad technology. It was incredibly useful technology. The problem came when powerful remote access was deployed without adequate controls. Attackers learned to exploit poorly secured remote access for compromised systems, ransomware, credential theft and lateral movement.

The lesson wasn't "Stop using remote access." The lesson was "Powerful capabilities require appropriate controls."

So we adapted. VPNs, MFA, firewalls, conditional access, network segmentation, privileged access management and logging. We didn't abandon the technology. We learned how to use it responsibly.

AI deserves exactly the same approach.

The More AI Can Do, the More Governance Matters

Imagine an AI agent with access to your email, files, source code, customer database, CRM, accounting system, browser, internal applications and APIs.

Now ask yourself: If this were a human employee, would I give one person unrestricted access to all of this?

Probably not.

That doesn't mean we shouldn't connect AI to these systems. There are enormous productivity benefits in doing so. But access should be intentional.

If AI needs to read something, does it also need permission to modify it? If it needs to prepare an email, does it automatically need permission to send it? If it analyzes financial information, does it need authority to execute a transaction? If it examines production systems, does it need permission to make production changes?

Those aren't arguments against AI. They're the same access-control questions IT has been asking for decades.

Shadow IT Is Becoming Shadow AI

There's also a much more immediate challenge. While executives and IT departments debate which enterprise AI platforms they should approve, employees are already using AI.

Someone uploads an Excel spreadsheet to a personal AI account. Someone pastes company information into an AI assistant. A developer installs an AI coding tool. Someone connects an AI assistant to cloud storage. Someone else gives an AI agent access to their browser.

We've dealt with Shadow IT for decades. Now we're beginning to deal with Shadow AI.

Simply banning AI probably isn't the answer. If a technology genuinely makes people more productive, people will find ways to use it. Organizations should instead provide employees with approved, secure ways to use these tools.

Governance should enable AI, not prevent it.

Use AI Aggressively. Govern It Intelligently.

There are two extremes. One organization says, "AI is too dangerous. Nobody can use it." Another says, "AI is amazing. Connect it to everything."

Neither approach makes much sense.

The better answer is somewhere in the middle: Use AI aggressively, but govern it intelligently.

Give employees access to approved AI platforms. Protect corporate information. Apply least privilege. Require human approval for consequential actions. Log what AI systems access and change. Review integrations before connecting AI to critical systems. And don't give an AI system authority simply because giving it that authority is convenient.

We've traditionally managed identities for employees, administrators, contractors, applications, service accounts and devices. Now we're adding another: AI agents.

What systems can the AI access? What information can it read? What can it modify? What actions can it perform? Who authorized those permissions? Can those permissions be revoked? Can we determine what it did afterward?

Those aren't anti-AI questions. They're responsible IT governance questions.

Don't Fear AI. Manage It.

AI has enormous potential, and I believe businesses that embrace it intelligently will have a significant advantage over those that don't.

But embracing AI doesn't mean abandoning decades of good IT practices.

Least privilege still matters. Separation of duties still matters. Change control

Thanks,

 

Michael Cronin

Website: https://www.michaelcronin.info

LinkedIn: https://www.linkedin.com/in/michaeltcronin/details/experience/

 

When Did the Workaround Become the Process?

Every organization has workarounds. A spreadsheet someone created because the system doesn't quite do what the business needs. A service that gets restarted every Monday morning. A report that requires someone to manually combine data from three different systems. A support team that knows exactly what to tell users when a particular error appears. A Product team that has learned not to touch a certain part of the application because "it's always been temperamental."

Individually, none of these things seem particularly alarming. Sometimes a workaround is exactly what you need. Something breaks, the business needs to keep moving, and smart people figure out another way to get the job done. That's a good thing.

The problem starts when nobody comes back and asks: Why are we still doing it this way?

Temporary Has a Way of Becoming Permanent

I've seen this happen countless times throughout my career. Someone creates a temporary process because a system can't handle something. It works. Six months later, people are still doing it. A year later, it's documented. Two years later, a new employee is trained on it.

Eventually, nobody remembers why the workaround exists. It's simply part of the job. And then someone suggests changing it.

The response? "We've always done it this way."

That's when technical debt becomes operational debt. We've taken something that was originally intended to get us through a problem and quietly turned it into a permanent business process.

The Spreadsheet Isn't Necessarily the Problem

Spreadsheets are a great example. I've heard plenty of technology people complain about businesses running important processes through Excel. But Excel isn't necessarily the problem.

The interesting question is: Why did someone need to create the spreadsheet?

Maybe the application didn't provide the information they needed. Maybe two systems couldn't communicate. Maybe the official process took 20 steps and someone figured out how to accomplish the same thing in five. Maybe Product never understood how people actually used the system.

That spreadsheet may be telling you something important. Instead of immediately asking, "How do we get rid of this spreadsheet?" we should probably ask: "What problem did this spreadsheet solve?"

That's a very different conversation.

Your Users Are Often Designing Solutions for You

People are remarkably good at adapting. Give someone a difficult process and eventually they'll figure out an easier way to do it. They'll build spreadsheets, create templates, copy information between systems, develop shortcuts, write instructions for each other, and even learn which buttons they're not supposed to click.

From an IT or Product perspective, it's easy to look at these behaviors and say users aren't following the process. Sometimes that's true.

But sometimes users are telling us something much more valuable: The process isn't following the business.

Those workarounds can become some of the best requirements gathering you'll ever do. Instead of asking users what feature they want next, watch what they're already doing outside the system. There's usually a reason.

The Cost Is Bigger Than the Extra Steps

A workaround that takes five extra minutes doesn't sound particularly serious. But multiply those five minutes across 50 employees, several times a week, for several years. Now it starts getting expensive.

And labor isn't the only cost. Manual processes introduce mistakes. Spreadsheets create multiple versions of the truth. Tribal knowledge creates dependencies on particular employees. Repeated system problems consume support resources. Temporary integrations become permanent architecture.

Eventually, the organization spends a surprising amount of time and money maintaining things nobody intentionally designed. That's the hidden cost of accepting friction as normal.

This Is Where Leadership Matters

Technology and Product leaders shouldn't eliminate every workaround. That's neither practical nor necessary. The job is to recognize which workarounds are telling us something about the health of the organization.

When I see a recurring manual process, support ticket, production incident, or customer complaint, I start asking questions: Why does this exist? How often does it happen? How many people are affected? What does it cost us? What would have to change to eliminate it?

And perhaps the most important question: If we were designing this process today, would we intentionally design it this way?

If the answer is no, then "we've always done it this way" probably isn't a very good reason to keep doing it.

Workarounds Are Useful. Until They're Not.

There will always be temporary fixes, and there should be. Businesses can't stop every time tech

Thanks,

 

Michael Cronin

Website: https://www.michaelcronin.info

LinkedIn: https://www.linkedin.com/in/michaeltcronin/details/experience/