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/

 

Your SaaS Business Can Be Profitable and Still Be Technically Unhealthy

One of the most dangerous assumptions a successful software company can make is:

“The numbers look good, so the product must be healthy.”

Revenue is growing. Customers are renewing. EBITDA looks strong. Churn is manageable. The sales pipeline looks promising.

From a financial perspective, everything appears to be working.

Meanwhile, Engineering is struggling to release changes. Support costs are creeping upward. Developers are spending more time maintaining existing functionality. Customer-specific workarounds are multiplying. Innovation is slowing down.

Both things can be true at the same time.

A software business can be financially healthy today while becoming technically unhealthy tomorrow.

Success Can Hide a Lot of Problems

When a business is struggling financially, everyone starts asking difficult questions.

When a business is growing, we tend to ask fewer of them.

That's understandable. Growth validates a lot of decisions. Customers are buying the product. They're renewing. The company is making money.

Something is clearly working.

But success can also give an organization enough financial momentum to carry technical and operational problems for a surprisingly long time.

The platform gets harder to maintain, so we add people.

Support volume increases, so we add support staff.

Development slows, so we hire more developers.

Infrastructure becomes inefficient, so we spend more on infrastructure.

Each response solves the immediate problem.

But eventually someone should ask:

Why does it keep taking more people, more money, and more effort to produce the same result?

That's where the financial conversation and the technical conversation begin to intersect.

Revenue Doesn't Measure Platform Health

Revenue tells us customers are paying us.

It doesn't tell us how difficult the product is to operate.

EBITDA tells us something important about financial performance.

It doesn't tell us whether developers are afraid to deploy on Friday afternoon.

Customer retention tells us customers are staying.

It doesn't necessarily tell us why they're staying.

That's particularly important with mature business software.

Replacing an established platform can be expensive, disruptive, and risky for a customer. Data has to move. Employees need training. Integrations need rebuilding. Business processes need changing.

Sometimes customers remain because they love your product.

Sometimes they remain because leaving is painful.

Those are not the same kind of customer loyalty.

Low churn is valuable, but low churn alone doesn't prove that a product is healthy.

Watch the Cost of Producing Revenue

One metric I think deserves more attention is the effort required to support continued growth.

Imagine revenue increases 20%.

That's great.

But what happened behind the scenes to support that growth?

Did support staffing increase 40%?

Did infrastructure costs increase 35%?

Did Engineering add people while release velocity stayed flat?

Are implementations taking longer?

Are developers spending more time maintaining customer-specific functionality?

Are production incidents becoming more frequent?

Revenue growth is important, but so is understanding what it costs the organization to produce and sustain that revenue.

Growth that continuously increases operational complexity eventually compresses margins.

And at that point, technical debt has stopped being an Engineering problem.

It has become a financial problem.

Technical Debt Behaves a Lot Like Financial Debt

I've always thought the term “technical debt” is useful because the comparison to financial debt is surprisingly accurate.

Debt isn't automatically bad.

Businesses borrow money all the time to accelerate growth. If the return on that investment exceeds the cost of the debt, taking on debt can be perfectly rational.

Technical debt can work the same way.

Maybe you need to ship something quickly to win an important customer.

Maybe you knowingly choose a simpler architecture because speed to market matters more right now.

Maybe you delay some modernization because the business has a critical opportunity.

Those can all be reasonable decisions.

The problem begins when the organization keeps borrowing and never starts paying anything back.

Eventually, you aren't just carrying the original debt.

You're paying interest on it.

In software, that interest appears as longer development cycles, increased testing requirements, more production incidents, higher support costs, slower onboarding, increased infrastructure costs, and engineers spending more time understanding old decisions.

The debt may never appear as a line item on the balance sheet.

But the company is paying for it.

Adding Developers Doesn't Always Make Development Faster

This is another place where financial and technical thinking sometimes collide.

When product delivery slows, the obvious business response is:

“We need more developers.”

Sometimes that's absolutely correct.

But adding people to an unhealthy platform doesn't automatically increase velocity.

New developers have to learn the system. Experienced developers have to train them. Institutional knowledge may exist primarily in people's heads. Development environments may be difficult to configure. Automated testing may be incomplete. Architecture may be inconsistent.

Now the experienced developers who were already overloaded have another responsibility: helping the new developers understand everything.

You increased Engineering expense.

But you didn't necessarily increase Engineering output.

That's an important distinction.

More capacity doesn't fix the friction that consumes capacity.

Sometimes the better investment isn't another developer.

It's making the existing development organization easier to scale.

Innovation Is an Asset Too

There's another cost that's much harder to see.

What isn't getting built?

A company may be profitable while competitors are improving faster.

Customers may still renew while increasingly asking when certain capabilities are coming.

Sales may still close deals while encountering more feature gaps.

Engineering may still deliver releases while spending 80% of its capacity maintaining what already exists.

None of those conditions necessarily create an immediate financial crisis.

That's what makes them dangerous.

By the time declining innovation clearly appears in revenue, the organization may already be several years behind.

The financial impact of technical stagnation often arrives long after the technical warning signs.

Don't Wait for Technology Problems to Become Financial Problems

This is why technical health belongs in executive conversations.

I'm not suggesting CEOs need to review source code or CFOs need to understand deployment pipelines.

They shouldn't.

But leadership should understand whether the technology supporting the business is becoming easier or harder to operate and evolve.

There are some useful questions executives can ask:

How much Engineering capacity is spent maintaining the existing platform versus improving it?

Are support costs growing faster than revenue?

Are releases becoming easier or harder?

Is customer onboarding becoming more standardized or more customized?

Are infrastructure costs scaling predictably with revenue?

How long does it take new developers to become productive?

Are recurring production problems actually being eliminated?

None of these questions require an executive to be deeply technical.

They require leadership to recognize that platform health is business health.

Durable EBITDA Requires Operational Maturity

Cost cutting can improve EBITDA.

Reducing Engineering investment can improve EBITDA.

Delaying modernization can improve EBITDA.

For a while.

But there's a difference between improving a financial metric and improving the underlying economics of the business.

The strongest SaaS organizations don't simply control costs.

They make the platform itself more efficient to operate, support, change, and scale.

That creates a much more durable advantage.

Engineering can deliver faster without proportionally increasing headcount.

Support can serve more customers without proportionally adding people.

Infrastructure scales predictably.

Implementations become repeatable.

Customers receive improvements faster.

That's operational leverage.

And operational leverage is ultimately what turns technical maturity into financial performance.

The Question Behind the Numbers

When leadership reviews the financial performance of a software business, the conversation naturally focuses on revenue, margins, churn, growth, and profitability.

Those numbers matter.

But I'd add another question:

What is happening underneath them?

Are we becoming more efficient as we grow?

Or are we simply throwing more people, money, infrastructure, and workarounds at increasing complexity?

Because those can produce remarkably similar financial results for a while.

The difference becomes obvious later.

One creates a business capable of scaling.

The other creates a business that eventually discovers just how expensive its success has become.

A profitable software company isn't automatically a healthy software company.

The best organizations make sure they're building both.

Thanks,

 

Michael Cronin

Website: https://www.michaelcronin.info

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

 

New Technology, Same Old Process

I've seen this happen more times than I can count.

An organization decides an old system needs to be replaced. The existing system is slow. It's difficult to maintain. People have created spreadsheets and workarounds to compensate for its limitations. Everyone agrees it's time for something new.
So the organization spends months selecting a new platform, implementing it, migrating the data, training employees, and finally going live.

And when everything is finished? They've recreated almost exactly the same process they had before.

They bought new technology. But they kept the old thinking.

“The Old System Did It This Way”

This is one of the most dangerous sentences during any modernization project: “The old system did it this way.”

That statement isn't necessarily wrong. Understanding how the existing system works is important. But it should be the beginning of the conversation, not the end of it.

The next question should be: Why did it do it that way?

Sometimes there is a very good reason. There may be a regulatory requirement, an accounting control, a customer commitment, or a legitimate business rule behind the process.

But sometimes the answer is simply: Because that's what the old system required.

And that's a very different thing.

Workarounds Have a Way of Becoming Requirements

Imagine a system implemented fifteen years ago that couldn't automatically send information between two departments.

Employees solved the problem by creating a spreadsheet. Every afternoon someone exported data from System A, cleaned it up, put it into the spreadsheet, and emailed it to another department. Someone in that department reviewed the spreadsheet and entered the information into System B.

Not ideal, but it worked.

After years of doing this, something interesting happens. The spreadsheet becomes part of the official process.

Documentation gets written around it. Employees are trained on it. Managers expect it. Maybe somebody even creates reports based on it.

Eventually the company replaces System A and System B with modern platforms that can communicate directly.

Now comes the critical question: What happens to the spreadsheet?

You would think the answer is obvious. Delete it.

But that's often not what happens.

Instead, someone adds a requirement to the new system: “We need it to generate the spreadsheet.”

Why? Because that's how we've always done it.

We have taken a workaround created because of a limitation in the old technology and turned it into a requirement for the new technology.

Requirements Need a “Why”

This is why I believe one of the most powerful questions in technology and Product Management is also one of the simplest: Why?

When someone says, “We need this report.” Why?

“We need this approval.” Why?

“We need this field.” Why?

“We need users to enter this information.” Why?

“We need the new system to work exactly like the old one.” Why?

This isn't about challenging people for the sake of challenging them. It's about understanding the business outcome behind the request.

If someone needs a report because they use three pieces of information from it to make a decision, maybe they don't actually need the report. They need those three pieces of information.

There may be a much better way to give it to them.

Don't Confuse Familiar With Good

There is also a very human element to this. People like what they know.

Even when an existing process is frustrating, employees understand it. They know its quirks. They know which buttons to push, which spreadsheets to open, and which shortcuts make it tolerable.

A new process introduces uncertainty.

So when organizations implement new technology, there can be tremendous pressure to make it behave like the system it's replacing.

That may make the transition easier, but it can also defeat much of the purpose of modernization.

Familiar doesn't necessarily mean efficient.

Sometimes the uncomfortable part of modernization isn't implementing the new technology. It's letting go of the old process.

Start With the Outcome

This connects directly to something I wrote about recently: Stop Automating Bad Processes.

Before automating something, understand what people are actually trying to accomplish. The same principle applies when replacing technology.

Don't start with: “How do we recreate what we have?”

Start with: “What are we trying to accomplish?”

Then work backward.

What information is actually required? What decisions need to be made? Who really needs to be involved? Which controls are necessary? Which steps exist only because of limitations in the old system? Which reports are actually being used? Which approvals add value? And which things are simply organizational habits?

Once you understand that, you can design the process first and choose how technology supports it second.

Modernization Isn't a Technology Project

This is where I think many modernization efforts get into trouble. They are treated primarily as technology projects.
Replace the database. Move to the cloud. Implement the SaaS platform. Rewrite the application. Build the APIs. Migrate the data.

All of those things may be necessary. But technology modernization without process modernization leaves a tremendous amount of value on the table.

If you move a bad process into the cloud, you still have a bad process.

If you rebuild an unnecessary workflow using modern APIs, it's still an unnecessary workflow.

If you use AI to automate a decision nobody needs to make anymore, you've simply created a very sophisticated way of wasting time.

New technology doesn't automatically create a better business. Better thinking does.

Before You Rebuild It, Challenge It

Whenever I look at an existing process, I like to mentally put every step into one of three buckets: Keep it. Simplify it. Eliminate it.

Some things absolutely need to remain. Some things still provide value but can be dramatically simplified. And some things exist only because they have always existed.

Those are the ones we need to be willing to eliminate.

That can be uncomfortable because eliminating a process often means questioning years of institutional knowledge. But that's exactly why modernization creates such a valuable opportunity.

You're already changing the technology. You're already disrupting the organization. You're already investing the time and money.

This is your chance to question everything surrounding it.

Otherwise, you may spend a great deal of money implementing tomorrow's technology only to recreate yesterday's business.

And that's not modernization.

That's just a newer way of doing the same old thing.

Thanks,

 

Michael Cronin

Website: https://www.michaelcronin.info

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

 

The Difference Between Fixing a Problem and Fixing the Symptom

One of the easiest traps to fall into in IT and Product is confusing making a problem go away with actually solving the problem.

A production system goes down. Get it running.
A user can't complete a transaction. Find a workaround.
A database is slow. Add resources.
Customers keep opening the same support ticket. Give them the instructions again.

All of those can be perfectly reasonable responses, especially when something is broken and people are waiting. But there's an important difference between restoring service and solving the problem.

Restoration asks: How do we get things working again?
Resolution asks: Why did this happen, and what needs to change so we don't have to do this again?

When the Workaround Becomes the Process

Imagine an application that slows down every Monday morning.

Someone discovers that restarting a service fixes it. The restart takes five minutes, performance returns to normal, and everyone gets back to work.

Problem solved, right?

Not really.

Next Monday, someone restarts it again. Then again the following Monday. Six months later, the organization has developed an operational procedure around restarting something that shouldn't need restarting in the first place.

Eventually, someone says, "That's just what we have to do on Mondays."

That's when a workaround has quietly become part of the architecture.

The actual problem might be a memory leak, an inefficient database query, a scheduled process, a resource constraint, an integration issue, or something else entirely.

Restarting the service addresses the symptom. Understanding why the service needs to be restarted addresses the problem.

The Same Thing Happens With Support

Consider a support team receiving the same question from customers over and over again.

The immediate response might be to improve the documentation. And maybe that's the right answer.

But what if customers need the documentation because the application itself is confusing?

We can write better instructions explaining how to navigate a poorly designed process, or we can ask why the process is confusing in the first place.

Both approaches might reduce today's support burden. Only one potentially eliminates tomorrow's ticket.

A good fix closes a ticket. A great fix prevents the next ticket from ever being opened.

Product Teams Fall Into the Same Trap

The same thinking applies to Product decisions.

A customer asks for a feature. Then another customer asks for something similar. Soon the request appears on the roadmap.

But before building it, there's an important question worth asking:

What problem are customers actually trying to solve?

Sometimes the feature customers request is exactly what they need. Other times, the feature request is simply evidence of a deeper problem.

Maybe an existing workflow is too complicated. Maybe information isn't available when customers need it. Maybe two systems that should communicate don't. Maybe users have created a manual workaround because the original process no longer fits how the business operates.

Building the requested feature without understanding the underlying problem can create another layer of complexity without actually improving the experience.

Sometimes the feature a customer asks for isn't the solution. It's evidence of the problem.

Our Metrics Can Encourage the Wrong Behavior

There's another reason organizations fall into symptom-driven problem-solving: fixing symptoms produces immediate, measurable results.

"We closed 247 tickets this month."
"We reduced the backlog."
"We restored production in 12 minutes."
"We delivered the requested feature."

Those aren't bad accomplishments. But they measure activity more easily than they measure improvement.

Suppose the support organization handled 100 tickets for the same issue last year. This year, someone fixes the underlying problem and only 10 tickets are created.

Ticket volume went down.

From one perspective, the support team accomplished less. From another, the organization became dramatically better.

That's why leaders need to look beyond how quickly teams respond to problems and ask how often the same problems are coming back.

Restore First. Then Investigate.

None of this means every production incident should immediately turn into a lengthy Root Cause Analysis.

When production is down and customers can't work, the priority should be clear: Get them working again.

Restore the service. Implement the workaround. Get the business moving.

But once the immediate problem is under control, don't automatically consider the job finished.

Ask why it happened. Ask whether it has happened before. Ask what would prevent it from happening again. And perhaps most importantly, ask whether the organization has unknowingly built procedures around problems that should have been eliminated years ago.

Because there is a big difference between being good at fixing things and building systems that don't constantly need fixing.

Fix the symptom when you have to. Fix the problem so you don't have to again.

Thanks,

 

Michael Cronin

Website: https://www.michaelcronin.info

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