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/

 

When Does Customer Service Start Breaking Your SaaS Product?

One of the easiest things for a software company to say is “Yes, we can do that.”

A good customer asks for a feature. Sales wants to close an important deal. An existing client has a workflow that’s just a little different from everyone else’s. The request makes its way to Product and Engineering, everyone talks it through, and eventually someone says, “It’s not ideal, but we can make it work.”

So we do. And in isolation, that decision may make perfect sense. The problem usually isn’t that decision. It’s the next 50 decisions just like it.

Customer Focus Is a Good Thing

I want to be clear about something upfront: listening to customers is not the problem. Great products are built by understanding the people who actually use them. Some of the best product ideas I’ve encountered didn’t originate in a conference room. They came from customers doing real work and discovering something the software didn’t handle particularly well.

That feedback is invaluable. But there is an important difference between learning from customers and building a different product for every customer. Those two things can look surprisingly similar in the beginning, but over time they lead to very different places.

“Just This Once”

Imagine Customer A needs a slightly different workflow, so we add an exception. Customer B needs a different approval process, so we add another. Customer C has a special reporting requirement. Customer D wants a field to behave differently. We can handle all of those.

Pretty soon, however, the platform starts accumulating logic that effectively says: If Customer A, do this. If Customer B, do that. Unless Feature X is enabled. Except when Workflow Y applies. But only when they’re using Integration Z.

At some point, you’re no longer developing a platform. You’re maintaining a collection of exceptions.

And nobody intentionally designed it that way. It happened one perfectly reasonable decision at a time.

Sales Probably Isn’t Trying to Break the Product

This is where these conversations sometimes become unnecessarily adversarial. Engineering blames Sales. Sales blames Product. Product blames Engineering. Support blames everyone.

That usually isn’t particularly helpful. Sales is trying to win business. Product is trying to satisfy customers. Engineering is trying to deliver what the business needs. Support is trying to keep customers happy. Everyone may be doing exactly what the organization has asked them to do.

The real problem is that nobody owns the cumulative effect of all those individual decisions. That’s a governance problem, not a people problem.

Customization Has a Compounding Cost

The first customer-specific feature might be inexpensive. The second probably is too. But every exception creates another path through the system, and that path has to be understood, tested, supported, documented, maintained, and considered every time something else changes.

This is where the economics become deceptive. A customization that takes a developer two days to build does not necessarily cost the company two days. The organization might have to support that decision for the next ten years.

Every future developer touching that area now has another condition to understand. Every QA cycle has another scenario to validate. Every production issue has another possible cause. Every architectural decision has another dependency.

The cost isn’t just building the exception. It’s carrying it.

Eventually, Everyone Becomes Afraid to Change Things

This is one of the clearest signs that customization has gotten out of control. A developer proposes changing something fundamental, and somebody asks:

“Do we know which customers depend on this?”

Someone thinks Customer X uses it. Someone else remembers Customer Y had something similar three years ago. Nobody is completely certain.

So the safest decision becomes: Don’t change it.

That’s how innovation starts slowing down. Not because the developers aren’t capable. Not because Product doesn’t have ideas. Not because leadership stopped caring. The organization has simply accumulated so many exceptions that the cost of understanding change has become greater than the perceived benefit of making it.

Configuration Is Different

Mature platforms eventually learn an important lesson: customers need flexibility, but flexibility doesn’t always require custom code.

That’s where configuration becomes incredibly powerful. Instead of saying, “We’ll modify the application for your workflow,” the conversation becomes, “How can we make the workflow configurable?”

Instead of building five customer-specific versions of something, we build one capability with well-defined options. That might mean feature flags, rules engines, configurable workflows, templates, permissions, business rules, APIs, metadata, or something entirely different depending on the product.

The exact implementation isn’t the important part. The principle is: move variation out of custom code and into intentional platform capabilities whenever practical.

The customer still gets flexibility, but the platform remains a platform.

Sometimes You Should Still Say Yes

None of this means every customer-specific request should be rejected. Business isn’t that simple. A major customer may have a legitimate requirement that justifies customization. A regulatory requirement may demand it. A strategic customer might expose a use case that eventually benefits the entire market.

Sometimes the correct business decision absolutely is “Yes. Build it.”

But that decision should be intentional. The organization should understand whether it is creating a product capability or a customer exception. Those aren’t necessarily the same investment.

Product Governance Matters

This is why healthy SaaS organizations need strong product and technical governance. Someone needs to ask questions beyond “Can we build this?”

Of course we can build it. That’s rarely the interesting question.

The better questions are: Should we build it? Is this solving a customer problem or one customer’s implementation problem? Will other customers benefit from it? Can it become a configurable capability instead of custom logic? What long-term support obligation are we creating? Does this move the platform forward, or make it harder to move forward later?

Those conversations aren’t bureaucracy. They’re how you protect the future of the product.

The Customer Who Pays for the Feature Isn’t the Only Customer Paying for It

This may be the most important part. When excessive customization makes a platform harder to maintain, every customer eventually pays.

They pay through slower releases, more bugs, longer support cycles, and new capabilities that take increasingly longer to develop. Eventually, the organization accumulates so much complexity that somebody walks into a meeting and says:

“We need to rewrite this thing.”

Sound familiar?

Build a Platform, Not a Collection of Exceptions

A mature product organization doesn’t stop listening to customers. It gets better at listening.

Instead of asking only, “What does this customer want us to build?” it starts asking:

“What is this customer teaching us about what the platform needs to become?”

That is a very different conversation. One produces another customization. The other produces product strategy.

Over enough years, that distinction can determine whether you’re building a scalable SaaS platform — or maintaining hundreds of customer-specific exceptions held together by increasingly nervous developers.

Thanks,

 

Michael Cronin

Website: https://www.michaelcronin.info

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

 

Your SaaS Platform Probably Doesn't Need a Rewrite. It Needs to Grow Up.

 

There is a moment in the life of many successful software products when someone finally says it: "We need to rewrite this thing."

 

The developers are frustrated. Releases are getting harder. Bugs seem to appear in places nobody expected. Customers have workflows nobody completely understands anymore. There are integrations nobody wants to touch.

 

Someone inevitably looks at the old platform and says:

• "If we could just start over..."
• I've seen this story before.
• And sometimes a rewrite really is necessary.
• But quite often, the technology isn't the real problem.

The organization has simply outgrown the way it builds and manages software.

 

Success Creates Its Own Technical Debt

We normally talk about technical debt as though someone did something wrong.

 

That's not always fair.

 

Some technical debt is simply the cost of moving quickly. 

 

A company gets a new customer who needs something immediately. A developer creates a workaround. Sales lands another major customer with slightly different requirements. Another exception gets added.

 

• The company grows.
• Revenue grows.
• The platform grows.
• And everyone celebrates as they should.
• But something else has been growing quietly in the background.

Complexity.

 

• The temporary workaround becomes permanent.
• The exception becomes a feature.
• The feature gets another exception.

Before long, nobody remembers exactly why certain things work the way they do. They just know changing them might break something.

 

That's when healthy growth debt can begin turning into dangerous operational debt.

 

The Financial Statements May Not Warn You

 

This is where things become particularly interesting from a leadership perspective.

 

• A software company can look financially healthy while its technology platform is becoming increasingly unhealthy.
• Revenue may still be growing.
• EBITDA may look good.
• Customer churn may remain low.
• Yet inside the organization, something very different is happening.
• Release cycles are getting longer.
• Developers are becoming increasingly cautious about deployments.
• More engineering capacity is spent fixing problems instead of creating capabilities.
• Customer-specific workarounds multiply.
• New developers take longer to become productive.

And the product roadmap gradually changes from:

 

• What should we build next?

to:

• What can we safely change without breaking something?

 

Those are two very different companies.

 

Low churn doesn't necessarily mean customers love your product, either. Sometimes customers remain because switching platforms is difficult, expensive, or disruptive.

Stable revenue can hide an enormous amount of operational fragility.

 

The Most Dangerous Phrase May Be "Don't Touch That"

 

Several warning signs show a platform drifting from innovation into maintenance mode.

• One of my favorites is deployment anxiety.
• Everyone knows that part of the system.
• Maybe only one developer understands it.
• Maybe nobody completely understands it.
• Eventually the institutional knowledge becomes:  Don't touch that unless you absolutely must.

That's not just technical debt anymore.   That's organizational risk.

Another warning sign is constant firefighting.

1. Engineering teams become extremely busy while accomplishing surprisingly little strategic work.
2. Everyone is working.
3. Everyone is solving problems.
4. Everyone is exhausted.
5. But the platform isn't really moving forward.

Activity and progress aren't the same thing.

 

Then Someone Suggests the Rewrite

• At this point, a complete rewrite starts sounding incredibly attractive.
• New architecture.
• New framework.
• Clean database.
• Modern APIs.
• No legacy code.
• No ugly compromises.
• A fresh start.

I understand the appeal.

 

The problem is that your old application contains something incredibly valuable that rarely appears in an architecture diagram:  years of accumulated business knowledge.

 

• Every strange conditional statement may exist because five years ago a customer discovered an edge case.
• Every unusual workflow may represent a business requirement somebody forgot to document.
• Every integration may contain lessons learned through years of production failures and fixes.
• That ugly old platform isn't merely code.
• It is institutional memory expressed in software.
• When you rewrite it, you aren't simply replacing technology.
• You're attempting to rediscover years, sometimes decades, of business knowledge.
• And while you're doing that, you still have customers using the old system.
• Now you have two platforms to maintain.

Meanwhile, feature development slows because your best people are rebuilding capabilities customers already have.

 

That's an expensive way to discover that the old software wasn't the only problem.

 

You Can't Rewrite an Organizational Problem

 

This is the part I believe technology and business leaders sometimes overlook.

 

Suppose the original platform suffered from:

• weak product governance,
• constantly changing priorities,
• inadequate QA,
• unclear architectural ownership,
• customer-specific customization,
• interrupt-driven development, and
• no dedicated capacity for modernization.
  
  

Now imagine building a brand-new platform...     

using the same organization and processes.

• Question: What do we think is going to happen?
• Answer:  Eventually you'll have a beautiful new codebase carrying many of the same problems as the old one.

Because you replaced the technology without changing the system that produced it.

 

A rewrite is not automatically a transformation.

 

Mature Platforms Evolve

 

The alternative isn't ignoring technical debt.  Quite the opposite.

• Healthy technology organizations treat modernization as part of operating the business.
• They continuously refactor high-risk areas.
• They automate testing and deployment.
• They establish architectural standards.
• They create clear ownership.
• They invest in observability.
• And perhaps most importantly, they resist solving every customer's problem with another piece of custom code.
• Whenever possible, mature platforms become configurable rather than customized.
• That's a subtle distinction with enormous consequences.
• Customization says: We'll change the software for you.
• Configuration says: We designed the platform so it can adapt to you.

One scales.  The other eventually becomes a collection of exceptions pretending to be a product.

 

Engineering Needs Room to Improve the Engine

 

There is also an uncomfortable economic reality here.

 

If 100% of engineering capacity is allocated to customer requests, features, and production problems, then effectively 0% is being invested in the future health of the platform.

 

Eventually, that bill comes due.

 

Organizations need intentional modernization capacity.

• Not someday.
• Not "when things slow down."
• Because things rarely slow down.

Technical leadership must deliberately balance innovation, stability, and modernization.

 

That means sometimes saying:  "We're going to spend engineering capacity improving something the customer may never directly see."

 

• Better deployment pipelines.
• Automated testing.
• Architecture improvements.
• Monitoring.
• Refactoring.
• Standardization.

Those things aren't distractions from product development.

 

They are what make continued product development possible.

 

Technical Debt Eventually Becomes Financial Debt

 

This is where the technology conversation becomes a business conversation.

 

Technical debt doesn't remain technical forever.

 

Eventually, it appears somewhere on the financial side of the organization.

 

• Higher support costs.
• Longer development cycles.
• More engineers required to deliver the same amount of functionality.
• Slower customer onboarding.
• Increasing infrastructure costs.
• Reduced innovation.
• Missed opportunities.
• Margin compression.

Eventually, the company realizes it isn't simply maintaining software.

 

• It's paying interest on years of deferred decisions.
• The Question Leaders Should Be Asking

So instead of immediately asking: "Should we rewrite the platform?"

 

I think leadership teams should start with several different questions. 

 

1. What operational risks are currently hidden beneath stable revenue?
2. Are we scaling our architecture or simply scaling our workarounds?
3. How much engineering capacity is going toward innovation versus maintenance?
4. Are we building a platform, or are we maintaining hundreds of customer-specific exceptions?

And perhaps the most important question: If we built the entire platform again tomorrow but kept the same leadership structure, priorities, processes, and engineering practices, would we eventually end up right back where we are today?

 

If the answer is yes, the problem probably isn't the codebase.

 

Technology platforms don't become sustainable because they're new.

 

They become sustainable because the organizations responsible for them develop the discipline to continuously evolve them.

 

The goal shouldn't be to build software that never becomes old.  That's impossible.

 

The goal is to build an organization capable of helping its technology grow old gracefully while continuously making it better.

 

Thanks,

 

Michael Cronin

Website: https://www.michaelcronin.info

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