Why the Apparent Problem is Rarely the Actual Problem

At some point in the last year, something clicked.

I had been building what felt like several separate things at once: a diagnostic advisory practice, a teaching role, a framework, and a book. They had different names, different audiences, and different deliverables, and I kept trying to organize them as separate workstreams that happened to share some DNA.

Then one day I stopped trying to separate them and looked at what they had in common.

The through-line was so obvious once I saw it that I couldn't believe it had taken me this long. Every single thing I do is basically the same move: find what the apparent problem is obscuring, figure out what is actually going on underneath it, and give it language precise enough to use.

I do it in a classroom, in a boardroom, and in an advisory engagement. Near Enemies is really just a more systematic version of the same thing. The domain changes, but the move doesn't.

It felt a little like unlocking a cheat code, not because I had figured out something new, but because I had finally named something I'd been doing for most of my career without realizing it was the same thing. Once I could see that, a lot of things that had felt disconnected suddenly weren't.

That experience, having something fuzzy become precise, is also a lot of what I've been trying to create for other people through Residy and Near Enemies. There is something incredibly useful about finally having a name for the thing you have been circling.

And that is what I mean when I say the apparent problem is rarely the actual problem. The stated problem usually isn't wrong. It just isn't the whole story.

The leader who says they need to communicate better may actually be struggling with conflict. The organization that says it has an alignment problem may be operating inside a story about itself that nobody has tested against reality in a long time. The executive who says they need to make a decision may already know what the decision is and just not want to deal with what comes next.

Those are different problems, and you can spend a tremendous amount of time working very hard on the first version without ever getting to the second. I've seen that happen a lot.

Over the past several months, I've written eleven articles about different versions of this: strength becoming armor, loyalty becoming silence, reflection becoming rumination, accountability becoming self-blame, and competence becoming indispensability.

When I started building Near Enemies, I thought the underlying mechanism was mostly about strengths crossing a line. Something good gets overused until it starts producing an outcome you didn't intend.

I still think that's part of it, but I've changed my mind a little. Or maybe I've just gotten more precise.

Increasingly, I'm interested in a different question: not just whether you've turned a strength up too high, but whether you're asking it to do a job that doesn't belong to it.

Empathy is a strength, but empathy doesn't get to decide what boundary you set. Competence is a strength, but being able to solve a problem doesn't automatically make it yours. Loyalty is a strength, but loyalty shouldn't make a decision that really belongs to judgment.

Sometimes the problem isn't the volume at all. It's jurisdiction: what gets to decide what?

I've found myself asking that question constantly lately, including in my own life.

It's also why I've always had a hard time explaining exactly what I do through Residy. It's not quite strategy, it's not traditional coaching, and it's not consulting. I've landed on diagnostic advisory, at least for now.

Usually someone comes to me with a problem they can already describe. My job is to keep asking questions until we're reasonably sure that's actually the problem.

What assumption are we treating like a fact? What are we solving for? What is driving this decision that probably shouldn't be? Whose problem is this, actually? What has jurisdiction here?

Sometimes the answer is uncomfortable, and sometimes it's almost annoyingly simple. But once we can name the actual thing, we can do something with it.

Near Enemies grew out of doing that over and over again and realizing I kept seeing versions of the same patterns. The book is where I'm trying to make the fuller argument. These articles have been a place to work some of it out in public. And Residy is where I get to find out whether any of it is actually useful when real people have real problems.

The funny thing about spending this much time naming patterns is that knowing the names does not make you immune to them.

I can see a problem and immediately start figuring out how to solve it before stopping to ask whether it is mine. I can absolutely call rumination reflection because, technically, I am thinking very hard. And I can take accountability well past the point of what I'm actually accountable for.

Apparently understanding the framework and consistently living it are two different skill sets. Work in progress.

This is the last article in this series. I started writing these partly because I wanted to explain the framework and partly because I wanted to see whether the ideas held up outside my own head. They've changed as I've written them, and my thinking has changed too.

And somewhere along the way, I accidentally figured out what my teaching, advisory work, framework, and book had in common.

So maybe the last question is the same one I increasingly start with: What is the apparent problem, and what might it be obscuring?