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/
