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/

 

Your Engineering Team Is Busy. But Are They Moving the Product Forward?

There’s a strange thing that can happen inside a growing software organization.

Everyone is busy.

Developers have full backlogs. Product has more requests than it can prioritize. Support tickets keep coming. Meetings fill the calendar. Releases happen. Bugs get fixed. Customers get answers.

From the outside, the organization looks incredibly productive.

But then someone asks a deceptively simple question:

“What have we actually improved?”

And sometimes the answer is surprisingly difficult.

That’s because being busy and moving forward are not the same thing.

When 100% Capacity Produces Very Little Capacity

Most organizations want their people fully utilized. On paper, that makes sense. If you’re paying for an engineering team, why wouldn’t you want them working at capacity?

The problem is what happens when every available hour is already committed.

A production issue appears. Something moves.

A major customer escalates a request. Something else moves.

Sales needs functionality for an opportunity. Move something again.

A security issue needs attention. Another priority changes.

Pretty soon the roadmap isn’t really a roadmap anymore. It’s a constantly rearranging list of whatever is most urgent today.

The team may technically be at 100% utilization, but it has almost 0% flexibility.

And software organizations without flexibility eventually become reactive organizations.

Firefighting Feels Productive

There’s something deceptive about firefighting: it feels incredibly productive.

A critical issue comes in. People jump on a call. Developers investigate. Someone finds the problem. A fix gets deployed. Everyone celebrates.

Problem solved.

And they should. Solving production problems matters.

But if the same team spends week after week responding to emergencies, customer escalations, defects, and operational problems, something important is being crowded out.

The work that prevents tomorrow’s emergencies.

• Refactoring.
• Automation.
• Testing.
• Monitoring.
• Documentation.
• Architecture improvements.
• Developer tooling.
• Removing obsolete code.
• Simplifying complicated workflows.

None of those things usually arrive marked URGENT.

So they keep getting pushed to next sprint.

• Then next month.
• Then next quarter.

Eventually, “we’ll get to that later” becomes part of the architecture.

The Roadmap Slowly Changes

Healthy product roadmaps contain a balance of work.

There are customer capabilities, strategic investments, technical improvements, operational work, and sometimes experiments that may not produce immediate revenue but help determine where the product goes next.

• Reactive organizations gradually lose that balance.
• The roadmap becomes dominated by tactical work.
• What does Customer A need?
• What broke yesterday?
• What did Sales promise?
• What needs to ship before the next renewal?
• What problem is Support escalating?

All of those can be legitimate priorities.

But if everything is urgent, strategy eventually becomes whatever survives the interruptions.

That’s not really strategy.

It’s triage.

Deployment Anxiety Is a Warning Sign

Another symptom appears when teams become nervous about releasing software.

You hear things like:

• “Let’s wait until Monday.”
• “Who else needs to be online when we deploy this?”
• “Do we know what else this might affect?”
• Or my personal favorite:
• “Don’t touch that.”

Some caution around production systems is healthy. Nobody wants developers recklessly deploying changes.

But fear is different from discipline.

If routine changes require heroic coordination because nobody completely understands what might break, the organization has accumulated risk faster than it has accumulated confidence.

• Eventually that affects velocity.
• Changes get smaller.
• Release cycles get longer.
• Innovation slows.

And the organization begins protecting the existing system instead of improving it.

Your Best Developers Often Become the Bottleneck

There’s another pattern I’ve seen repeatedly.

As systems become more complicated, institutional knowledge concentrates around a handful of experienced people.

• Everyone knows who they are.
• When something strange happens, call Sarah.
• Before changing that module, ask John.
• Nobody deploys that service unless Mike is available.
• At first, those people look incredibly valuable — and they are.
• But the organization has also created a dangerous dependency.
• Your strongest engineers gradually become human routing tables for the platform.
• Instead of designing what comes next, they spend their time explaining what already exists.
• Instead of mentoring and improving architecture, they get pulled into every production problem.
• The better they are at solving emergencies, the more emergencies they receive.

Expertise becomes a bottleneck instead of a force multiplier.

New Developers Tell You More Than You Think

One of the best indicators of platform maturity is what happens when a new developer joins the team.

How long does it take before that person can safely make a meaningful contribution?

• A few days?
• A few weeks?
• Several months?
• Do they have documentation?
• Automated tests?
• Repeatable development environments?
• Clear architectural patterns?
• Or does onboarding consist mostly of someone saying:
• “Sit with me and I’ll explain how all of this works.”
• Complex systems naturally require time to learn. That isn’t necessarily a problem.
• But when knowledge exists primarily in people instead of systems, documentation, standards, and automation, growth becomes increasingly difficult.
• Every new developer requires more time from the developers who are already overloaded.

Now the very people you hired to increase capacity initially reduce capacity.

Modernization Cannot Be Leftover Work

This is where leadership has to make an intentional decision.

If modernization only happens when engineering “has some extra time,” it probably isn’t going to happen.

• There is always another feature.
• Another customer.
• Another bug.
• Another deadline.
• Another escalation.

Healthy organizations deliberately reserve engineering capacity for improving the platform itself.

That percentage doesn’t have to be the same for every company or every quarter. Sometimes business conditions legitimately require nearly everyone to focus on a major delivery.

But modernization needs to exist as a real priority rather than a hopeful future activity.

You cannot continuously withdraw from the technical health of a platform without eventually making deposits.

The Customer May Never See the Most Important Work

This can be difficult because some of the most valuable engineering work produces almost nothing visible to the customer.

• Customers don't necessarily see improved CI/CD pipelines.
• They don't see automated regression testing.
• They don't see refactored architecture.
• They don't see better observability.
• They don't see standardized development patterns.
• What they eventually see is the result.
• Fewer outages.
• Faster releases.
• More predictable delivery.
• Better performance.
• Fewer regressions.

And a product that can evolve without everyone holding their breath every time something changes.

That is why technical health is ultimately a product concern and a business concern, not simply an engineering concern.

Stop Measuring Productivity by How Full the Backlog Is

A full backlog doesn't tell me that an engineering organization is healthy.

• Neither does a calendar full of meetings.
• Neither does the number of tickets closed.
• Neither does having every developer allocated at 100%.
• Those things measure activity.
• Leadership needs to look beyond activity and ask whether the organization is actually increasing its ability to deliver.
• Are releases becoming easier or harder?
• Are developers spending more or less time firefighting?
• Is onboarding getting faster?
• Are recurring problems being eliminated or repeatedly fixed?
• How much engineering capacity goes toward innovation versus maintenance?
• Are we reducing complexity or simply learning to tolerate more of it?

Those questions tell us much more about the direction of the organization.

Leave Room to Move Forward

High-performing engineering organizations absolutely work hard.

• But they also create room to think.
• Room to improve.
• Room to automate.
• Room to refactor.
• Room to experiment.

And occasionally, room to question why something has been done the same way for the last ten years.

A team running at 100% capacity all the time isn't necessarily operating efficiently. It may simply have no room left to become more efficient.

The goal shouldn't be to keep engineering as busy as possible.

The goal should be to create an engineering organization capable of continuously delivering value while making the platform easier — not harder — to change tomorrow.

Because ultimately, the question isn't:

“Is everyone busy?”

It's:

“Are we moving the product forward?”

Thanks,

 

Michael Cronin

Website: https://www.michaelcronin.info

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

 

Stop Automating Bad Processes

There is a phrase I have heard throughout my career: “We need to automate this.”

Sometimes we do. But before we start talking about APIs, AI, workflow engines, integrations, databases, or writing a single line of code, I think there is a much more important question: Should we be doing this process at all?

Because automating a bad process doesn't make it a good process. It just makes the bad process run faster.

Technology Shouldn't Be the First Question

One of the mistakes I've seen organizations make repeatedly is starting with the technology. Someone identifies a manual process and immediately the conversation becomes: Can we automate this?

My first questions are usually different: Why are we doing this? What decision is the person actually making? What information do they need to make that decision? What happens before and after that decision? And perhaps most importantly, does this process still make sense?

Processes have a funny way of surviving long after the reason they were created has disappeared. Someone created a spreadsheet ten years ago. Someone else added another approval. A new regulation added another step. A manager wanted another report. A system couldn't do something, so employees invented a workaround.

Years later, nobody remembers exactly why the process works the way it does. They just know: “That's how we've always done it.”

Then somebody comes along and says: “Let's automate it.”

That is exactly when we should be careful.

A Lesson From Claims Assignment

Earlier in my career, I worked with claims-assignment processes. On the surface, the problem seemed straightforward. A claim came into the organization and someone needed to determine who should receive it.

There were rules, territories, workloads, different types of claims, and people making decisions based on all of those factors.

The easy technology answer would have been to simply reproduce what those people were already doing in software. But that wasn't really the problem we needed to solve.

The important part was understanding how the decision was actually being made. What information mattered? Which rules were real requirements? Which were simply habits? Which exceptions actually mattered? What judgment were people applying?

Once you understand those things, something interesting happens. You stop thinking about how to automate the existing steps and start thinking about how to achieve the outcome.

That's a very different problem.

Minutes, Hours...Then Seconds

The existing assignment process could take minutes of someone's actual working time, but the elapsed time could be much longer.

A claim might arrive and wait for someone to review it. That person might need additional information. They had other work ahead of it. They might be at lunch, in a meeting, helping another customer, or gone for the day.

A process requiring only a few minutes of human effort could therefore take considerably longer before the assignment actually occurred.

When we redesigned that process around the decision instead of simply reproducing the manual workflow, the assignment could happen in seconds.

That distinction is important. We didn't make someone click through the same process faster. We removed the need for most of the process.

That is where the real value of automation comes from.

Don't Automate the Clicks

This becomes even more important today because automation is becoming incredibly easy. With AI, low-code platforms, APIs, robotic process automation, and modern SaaS tools, organizations can automate processes faster than ever before.

That's wonderful. It is also dangerous, because we can now automate bad ideas faster than ever before.

Imagine an employee receives an email, downloads an attachment, opens a spreadsheet, looks up information in another system, copies several values into the spreadsheet, determines a category, emails the spreadsheet to another person, and then that person enters the information into yet another system.

You could absolutely automate all of those steps.

But perhaps the better question is: Why are there so many steps in the first place?

Maybe the information already exists. Maybe the spreadsheet shouldn't exist. Maybe the second person doesn't need to be involved. Maybe the category can be determined when the original transaction occurs. Maybe the systems should communicate directly.

Maybe most of the process can simply disappear.

That is process improvement. Automation comes afterward.

Talk to the People Doing the Work

There is another lesson here that technology teams sometimes forget: The people doing the work usually know where the problems are.

They know which screens waste their time. They know which approvals accomplish nothing. They know which spreadsheet exists because two systems don't communicate. They know which information they enter twice. They know which rules don't make sense in the real world.

If you walk into that environment with a predetermined technology solution, you will probably miss much of that knowledge.

Instead, sit with them. Watch the process. Ask why. Then ask why again.

You may discover that what management believes the process looks like and what actually happens every day are two very different things. That difference is often where the biggest opportunities live.

AI Makes This More Important, Not Less

Today, every organization is asking where AI fits. That's a reasonable question, but I think we should resist the temptation to sprinkle AI across every existing business process simply because we can.

Before asking “How can AI automate this?”, ask “What are we actually trying to accomplish?”

Then ask: “What is the simplest way to accomplish it?”

Sometimes the answer will be AI. Sometimes it will be traditional automation. Sometimes it will be an integration between two systems. Sometimes it will be changing a business rule.

And occasionally, the best technology solution will be: Delete the process entirely.

Automation Is a Multiplier

This is the principle I keep coming back to: Automation is a multiplier.

Give automation a well-designed process and it can multiply productivity, consistency, speed, and scale. Give automation a poorly designed process and it can multiply complexity, mistakes, technical debt, and cost.

So before building the workflow, buying another platform, creating another integration, or telling the AI to automate everything, spend some time understanding the work.

Talk to the people doing it. Understand the decisions being made. Challenge the assumptions behind the process. Remove the steps that don't need to exist. Simplify what remains.

Then automate it.

Because the goal isn't to automate more work.

The goal is to need less work in the first place.

Thanks,

 

Michael Cronin

Website: https://www.michaelcronin.info

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