When the Printer Problem Wasn't About the Printer: Why Problem Management Really Fails

The Déjà Vu That Every IT Professional Recognizes

"Not this again."

Tessa stared at her screen in second-line support, looking at a pattern that would make any IT professional's heart sink. Five tickets. Same error. All marked "resolved." All back within weeks.

The printing problem that wouldn't die.

If you've worked in IT for more than a year, you know this story. Different system, same frustration. The technical fix works perfectly—until it doesn't. The Problem ticket gets closed with confidence—until it reopens with embarrassment.

Sound familiar? You're experiencing one of the most common failures in IT service management.

The Problem Management Paradox: Perfect Process, Persistent Problems

Here's what made this case particularly maddening: everything had been done correctly.

✅ Service Desk logged incidents properly
✅ Problems were linked to root cause analysis
✅ Infrastructure team deployed the documented fix
✅ Problem ticket was closed with proper documentation
✅ Workarounds were published and accessible

Yet every few weeks, the same departments called with the same issue: HR couldn't print contracts, Legal couldn't print briefs, Procurement couldn't print purchase orders.

The Business Impact Nobody Measured

While IT celebrated technical victories, something else was happening in the organization:

• Trust erosion: Teams quietly lost confidence in IT's ability to solve persistent issues
• Shadow IT growth: Departments started using consumer tools and manual workarounds
• Productivity drain: Time wasted on repetitive troubleshooting and explanations
• Reputation damage: IT became seen as reactive rather than proactive

No major incident occurred. No executive escalation happened. But the real cost—organizational confidence—was bleeding away slowly.

The Root Cause Behind the Root Cause: Why Technical Fixes Don't Stick

The breakthrough came when someone asked a different question. Instead of "What's wrong with the printer?" they asked "What's wrong with how we're solving printer problems?"

The problem wasn't living in the printer drivers. It was living in the spaces between teams.

The Meeting That Changed Everything: From Blame to Understanding

Instead of another technical deep-dive, leadership tried something radical: they brought everyone into the same room to tell their story.

Not to assign blame. Not to review logs. Just to listen.

What Each Team Experienced

Service Desk: "We kept escalating but felt like our updates disappeared into a void. No feedback, no timeline, no way to give users real answers."
Infrastructure Team: "We fixed the driver issue and confirmed the deployment worked. From our metrics, the problem was solved."
Application Support: "Honestly, we didn't even know it had come back. We were never looped into the ongoing issues."
Business Representative: "The technical details don't matter to us. What matters is that our deadlines get missed, and IT seems surprised every time we mention the same problem."

The Moment of Clarity

In that room, something shifted. The technical complexity evaporated, and the real issue became clear:

No one felt responsible for the pattern.

Everyone owned their piece of the process, but nobody owned the outcome. The problem wasn't about printer drivers—it was about attention, ownership, and follow-through.

The Simple Solution That Actually Worked

After the meeting, the approach changed completely:

1. End-to-End Ownership
Instead of assigning another Problem Manager, a service lead walked through the entire user experience from symptom to resolution.

2. Real-World Validation
The fix was tested with actual users in their real environment, not just validated through system monitoring.

3. Dependency Mapping
All the connection points between teams were identified and communication protocols established.

4. Narrative Documentation
The Problem ticket was rewritten as a story—what went wrong, why it mattered, and how the solution addressed the full experience.

5. Shared Accountability
Multiple teams took joint ownership of monitoring for recurrence and user satisfaction.

The result? The problem didn't return.

Why This Approach Works: The Psychology of Persistent Problems

This success revealed something important about Problem Management: technical accuracy isn't the same as organizational resolution.

The Three Levels of Problem Solving

Level 1: Symptom Management

• Fix the immediate technical issue
• Close the ticket
• Move to the next problem

Level 2: Root Cause Analysis

• Identify underlying technical causes
• Implement systematic fixes
• Document for future reference

Level 3: Organizational Resolution (Where most teams stop)

• Address communication gaps
• Ensure shared accountability
• Validate user experience end-to-end
• Build sustainable monitoring

Most Problem Management stops at Level 2. But persistent problems live at Level 3.

The Framework: Building Problem Management That Prevents Recurrence

Based on this experience, here's the proven approach for tackling recurring problems:

Step 1: Map the Human System, Not Just the Technical System

• Who touches this problem from start to finish?
• Where do handoffs happen?
• What assumptions exist between teams?

Step 2: Listen Before You Analyze

• Gather perspectives from all stakeholders
• Understand business impact, not just technical symptoms
• Identify emotional and trust factors

Step 3: Own the Pattern, Not Just the Incident

• Assign accountability for user experience
• Create feedback loops between technical teams and business users
• Monitor for satisfaction, not just system metrics

Step 4: Validate in the Real World

• Test fixes with actual users in their environment
• Confirm resolution from the user's perspective
• Establish ongoing monitoring with business stakeholders

Step 5: Document the Story, Not Just the Steps

• Explain why this problem mattered
• Describe what was learned about team collaboration
• Make the organizational knowledge visible

The Cultural Shift: From Compliance to Conversation

The most important insight from this experience: recurring problems are rarely technical problems in disguise.

They're organizational problems wearing technical masks.

The symptoms appear in systems, but the causes live in:

• Assumptions about what "fixed" means
• Habits around handoffs and communication
• Responsibility gaps between technical and business teams
• Silence where collaboration should happen

Beyond the Process: Making Problem Management Human

If you're frustrated with problems that keep coming back despite "perfect" technical solutions, consider this:

Ask Different Questions

• Instead of "Is the fix deployed?" ask "Is the user experience actually improved?"
• Instead of "Who owns this problem?" ask "Who owns this outcome?"
• Instead of "What broke?" ask "What pattern are we missing?"

Create Different Conversations

• Bring technical and business stakeholders together regularly
• Focus on shared understanding, not just shared information
• Make organizational learning as important as technical learning

Measure Different Things

• Track user confidence, not just system availability
• Monitor collaboration quality, not just process compliance
• Value prevention over reaction

The Bottom Line: Problem Management Is Relationship Management

The printer problem taught a crucial lesson: you can't solve organizational problems with purely technical solutions.

The turning point wasn't a better process or smarter technology. It was a better conversation—one that acknowledged the human system running alongside the technical system.

When teams understand each other's perspectives, share accountability for outcomes, and communicate openly about what's working (and what isn't), problems stop recurring not because the technology is perfect, but because the people are connected.

Your Turn: Breaking the Cycle of Recurring Problems

Think about the persistent problems in your environment. The ones that get "fixed" repeatedly but never really go away.

Ask yourself:

• Who experiences this problem end-to-end?
• What conversations haven't happened yet?
• Where are the assumption gaps between teams?
• What would shared accountability look like?

Sometimes the most powerful solutions are also the simplest: bringing people together to listen, understand, and take collective ownership of outcomes.

About Problem Management Culture: This approach draws inspiration from the ABC of ICT framework (Attitude, Behavior, Culture), which recognizes that sustainable IT solutions require attention to human factors alongside technical ones. The best Problem Management isn't just about fixing things—it's about building the organizational capacity to prevent problems from recurring.