One of the easiest mistakes to make in technology and leadership is jumping too quickly into solution mode.

A system is slow, so we replace it.

Communication is poor, so we add another meeting.

A department is struggling, so we introduce a new process.

Users are frustrated, so we buy another application.

Sometimes those solutions work. But sometimes we spend weeks or months solving the wrong problem because we never took enough time to understand what was actually happening.

In IT, we already understand this concept technically. If a server is performing poorly, we don't normally replace it based on a feeling. We look at CPU utilization, memory, disk performance, network traffic, logs, dependencies, and recent changes.

Organizations deserve the same discipline.

A Symptom Is Not a Diagnosis

Imagine a manager saying:

Everything seems to be working, but I feel like the team could be functioning better.

That statement is useful, but it isn't a diagnosis.

The issue could be communication. It could be unclear responsibilities. Maybe departments aren't coordinating effectively. Perhaps decisions take too long, or employees don't know who has authority to make them.

There may even be nothing fundamentally wrong.

That's why the first question shouldn't be:

What should we change?

It should be:

What is actually happening?

That distinction matters.

When leadership begins with a preferred solution, it's easy to start collecting information that confirms the solution rather than information that identifies the problem.

Think Like You're Troubleshooting a System

My IT background makes me think about organizational problems much like technical troubleshooting.

If someone tells me, "The network is slow," I don't immediately replace the firewall.

I start gathering information.

  • When did the problem begin?
  • Who is affected?
  • Is it happening everywhere or only in one location?
  • What changed recently?
  • What do the logs show?
  • Can we reproduce it?
  • What does normal performance look like?

Organizational problems can be approached in much the same way.

Instead of logs and performance counters, the data may come from conversations, observations, employee feedback, performance metrics, workflows, and business results.

The objective is still the same:

Reduce assumptions and increase evidence.

One Person's Perspective Isn't Enough

Leadership observations are important, but they are still observations from one position inside the organization.

A department head might believe communication is the problem.

Employees might believe decision-making is the problem.

Another department might believe unclear ownership is creating delays.

All three perspectives can exist at the same time.

That's why good diagnosis requires multiple sources of information.

In technical troubleshooting, I wouldn't rely on one log if I could compare application logs, server metrics, network traffic, and user reports.

The same principle applies to organizations.

  • Talk to the people doing the work.
  • Look at the processes.
  • Look at the outcomes.
  • Compare what leadership believes is happening with what employees actually experience.

Patterns become much easier to see when information comes from multiple directions.

Change Creates Its Own Resistance

There's another problem leaders sometimes underestimate: simply announcing that something needs to change can affect how people behave.

Imagine being told:

We're bringing in someone to evaluate how your department operates.

Even if nothing is wrong, people may immediately wonder:

  • Why?
  • Is management unhappy?
  • Are jobs at risk?
  • Is someone being blamed?

That uncertainty can create resistance before the project even begins.

This is especially important in technology projects.

A new ERP system, SharePoint migration, security policy, automation platform, or AI initiative might make perfect sense technically. But employees don't experience those projects as architecture diagrams.

They experience them as changes to how they work.

People want to know:

  • What is changing?
  • Why are we doing it?
  • How does this affect me?
  • What am I expected to do differently?
  • What happens if something doesn't work?

Technical planning without organizational planning is one reason otherwise good technology projects struggle.

Structure Matters, but So Does Flexibility

There's a balance between having a plan and assuming you already know the answer.

You need enough structure to guide the process, but enough flexibility to follow the evidence.

Before starting an organizational improvement effort, I would want several things established:

  • What are we trying to understand?
  • Who needs to participate?
  • What information do we need?
  • How will feedback be handled?
  • What does success look like?
  • Who owns the next steps?
  • When will we evaluate the results?

Those questions don't predetermine the solution.

They create a framework for discovering it.

Don't Turn Every Problem Into a Technology Problem

This is particularly important for IT leaders.

We naturally see opportunities to automate, integrate, migrate, standardize, and modernize.

But technology can't fix every organizational problem.

A new project management platform won't fix unclear accountability.

A new communication tool won't automatically improve communication.

A new ERP won't fix a broken business process simply because the old process has been digitized.

AI won't fix bad data or unclear decision-making.

Sometimes technology is the solution.

Sometimes technology supports the solution.

And sometimes technology has almost nothing to do with the actual problem.

Knowing the difference is part of good IT leadership.

Establish a Baseline Before You Change Anything

Another lesson from technical troubleshooting applies directly to organizational change:

Know what "before" looks like.

If you make a change without establishing a baseline, it becomes difficult to determine whether the change actually helped.

Suppose the goal is to improve communication between departments.

What does "improve communication" mean?

  • Fewer missed handoffs?
  • Faster approvals?
  • Fewer escalations?
  • Shorter project delays?
  • Higher employee satisfaction?

Without some way of measuring the original condition, success becomes subjective.

Everyone leaves a workshop feeling positive, so the initiative is declared successful.

Three months later, everyone is working exactly as they did before.

Real improvement needs follow-up.

The Intervention Isn't the Finish Line

Organizations often put tremendous energy into launching change and much less energy into sustaining it.

There's a kickoff.

There's training.

There's a new process.

Everyone agrees on the next steps.

Then normal work takes over.

If the change matters, it needs reinforcement.

That might mean reviewing progress during management meetings, tracking agreed metrics, collecting additional feedback, adjusting the process, or making the new behavior part of normal operating expectations.

The question isn't simply:

Did we implement the change?

The better question is:

Did the change improve the organization, and did the improvement last?

Diagnose First. Change Second.

The more I work across technology, systems, data, and business operations, the more I see how closely technical troubleshooting and organizational development overlap.

Both require us to resist the temptation to jump immediately to an answer.

  • Observe.
  • Gather data.
  • Talk to the people involved.
  • Challenge assumptions.
  • Identify patterns.
  • Establish a baseline.
  • Then decide what needs to change.

A leader saying, "I think we can operate better," can be the beginning of something valuable.

But it shouldn't automatically become a software implementation, restructuring, workshop, new policy, or transformation project.

Sometimes the most important thing we can do before fixing a problem is spend enough time proving that we understand it.