If You Keep Solving the Same Problem, You’re Probably Solving the Wrong One
Trish Calhoun is a Systemic Completion Coach and founder of Put It Down, a practice that helps high-achieving professionals identify and finish the patterns keeping them stuck. Her work draws on systemic constellation methodology and nearly two decades of enterprise transformation experience.
When the same problem survives new processes, reorganizations, technology and capable people, another solution may not be what is missing. Sometimes the better move is to change how you are looking at the system long enough to see what keeps recreating the problem. How many times can you solve the same problem before you have to admit you might be solving the wrong one? I keep seeing this. In companies, in product teams, in careers, honestly, in my own life too. We identify the thing that hurts, fix it, feel better for a minute and then somehow end up back in almost the exact same place.
New process. New manager. New tool. New job. Same problem. At some point, that has to mean something.
We tend to be pretty good at fixing what is obvious. A project keeps missing dates, so we tighten the planning process. Priorities are unclear, so we create a new prioritization framework. Employees are not adopting a change, so we add more communication and training. We hate our job, so we start looking for another one.
None of those are ridiculous responses. Most of them make perfect sense, which is probably why we keep doing them. But if the same issue survives several competent people, reorganizations, process changes, new tools and a whole lot of effort, I am not sure the answer is always that we need to get better at solving it.
Maybe we have defined the problem wrong. Or maybe we are looking at it from an angle that makes the real problem almost impossible to see.
Why solving the visible problem can make things worse
One of the harder lessons I learned in product development came from an organization that kept identifying collaboration as a challenge. Teams needed to collaborate better. Functions needed more alignment. People needed to engage earlier and work across boundaries more effectively.
There was truth in that. Large product organizations need collaboration, and highly specialized work falls apart when functions retreat into their own corners. But over time, I started seeing something else. In some areas, we did not have too little collaboration. We had so much poorly bounded collaboration that it was getting in the way of the work.
People were pulled into decisions because their function touched the work, because they had useful history, because they might eventually be affected or because leaving someone out felt riskier than bringing them in. The meetings grew, decisions traveled sideways through the organization and the distinction between giving input and owning the decision became increasingly hard to see. I came to think of it as “ruinous collaboration.”
Parallel work around career ladders and role expectations helped make the pattern more visible. Once accountabilities were written down, overlaps that had been relatively easy to tolerate became much harder to ignore. Different functions sometimes believed they owned pieces of the same outcome. What had been described as a collaboration problem began to look, at least in some places, like a role and decision rights problem.
The answer was not universally “less collaboration.” Some teams needed more. Some needed clearer boundaries. Some agile teams worked perfectly well without a formal matrix defining who is responsible, accountable, consulted and informed (RACI) until conflict across roles exposed an ambiguity worth resolving. In those cases, a RACI matrix became useful not as another process artifact everyone was required to maintain, but as a way to settle a very practical question: who owns what here? There was no single answer because there rarely is one in a large organization.
Several reorganizations followed without reductions attached to them, and I was there long enough to see some groups become more efficient as accountabilities became clearer. In a few areas, I also advocated with leadership for reducing overlap where I believed the organization had created more complexity than the work itself required.
I generally believe smaller groups have an advantage when the work allows for them. As groups grow, coordination becomes work of its own. More relationships have to be managed, more boundaries negotiated and more people involved in decisions that may not require all of them. That does not mean smaller is always better, and it certainly does not give us a magic number. It means scale has a cost that needs to earn its keep.
Later, the organization went through a broader reduction, and I was part of its first wave. I appreciate the irony. I had advocated for simplification in parts of the system, and eventually my own role was simplified out of it. I still believe the underlying observation was sound.
What I took from the experience was not that collaboration is bad, RACI matrices are good, small teams are always superior or reductions make organizations faster. Any one of those conclusions would be another version of the same mistake. What I took from it was the importance of seeing what is really happening before deciding what kind of solution belongs there.
Why seeing the real problem is harder than fixing it
I think we underestimate this part. Once a problem has a name, the name starts organizing everything we see around it. Call something a collaboration problem and suddenly meetings, communication, cross-functional behavior and stakeholder engagement become the evidence we collect. Call it a productivity problem and we start measuring output. Call it resistance to change and we start looking at the people who have not adopted the change.
The diagnosis creates a frame, and then the frame becomes very good at finding evidence that supports the diagnosis. This is why I am increasingly skeptical of relying on any one way of understanding a system. Organizational charts can tell me something. A RACI matrix can tell me something else. Interviews, process maps, customer data, operating metrics and organizational history all add pieces. None of them gets to be the whole truth.
Sometimes the missing piece is visible in what people have learned to work around. The unofficial approval before the official approval. The spreadsheet someone created because two systems never worked together properly. The executive everyone knows has to be consulted even though the role technically owns nothing. The person carrying three responsibilities because they were capable enough to absorb them and nobody ever gave the work back.
Organizations get very good at compensating for themselves. Then someone leaves, the company grows, a merger happens, costs get cut or the volume becomes too large for the workaround to survive. Everyone starts asking what broke when the more useful question may be what had been quietly holding the broken thing together.
A lot of my work starts there. Not immediately solving, but seeing.
What systemic constellations can reveal
There is another way I look at systems that is less conventional. My systemic coaching work is informed by the Hellinger lineage of constellation work, adult development perspectives and organizational systemic practices, including training with Michael Spayd through Systems Within. Most of the time, I am not taking a client through a formal constellation. With consent, I may work with the system privately and then test what surfaces through questions, observation and the more traditional evidence available to us.
Sometimes a system tells you something before you can explain why you know it. I have had constellation work surface a role that seemed to have a legitimate place in an organization while the person occupying it did not. I have seen merger dynamics show up less as tension between individual leaders and more as tension between two operating systems and the people carrying them. I have seen a leader who deeply wanted to lead an organization appear so far removed from it that the distance itself became something worth exploring.
None of those observations becomes fact because it emerged in a constellation. What surfaces gives me another place to look. I want to know whether the hypothesis explains something that has been difficult to explain, what happens when I ask about it, whether the client recognizes something in it and what evidence in the structure, behavior or history supports or contradicts what I sensed.
Sometimes nothing comes of it. Other times, one question opens a part of the system nobody had been looking at because there had been no obvious reason to look there.
Clients do not always know where the question came from. Some simply think I am unusually intuitive, which is fair. The point is not whether an insight came from an organizational chart, a pattern in the data, twenty years of experience or something I noticed while reading the field. The point is whether it helps us see more of the system than we could see before. When a system has already been through three rounds of solutions without changing much, seeing something different may be considerably more valuable than generating solution number four.
How artificial intelligence is exposing problems that were already there
Artificial intelligence (AI) belongs in this conversation, although not because every organization is suddenly operating in an AI-first world. AI adoption is highly uneven across industries and functions. In many organizations, AI is still a pilot, an isolated use case or something being used by pockets of individuals rather than operating across the entire business.
Where AI is being used heavily, it is removing some constraints very quickly. Research, synthesis, documentation, early product concepts and parts of software development can move faster than they did before.
That can be useful for reasons that have little to do with productivity. If the work gets faster and the organization does not, the constraint becomes easier to see.
A team can generate six viable concepts instead of two, but someone still has to decide which one matters. Engineering can get to code faster, but someone still has to decide whether it should ship. Thousands of customer comments can be synthesized quickly, but somebody still has to know which customer matters and which problem deserves priority.
AI can increase output without clarifying ownership. It can create more options without creating priorities. It can remove effort from one part of a system and make the blockage somewhere else much more visible.
It can also help us compensate for bad systems more efficiently. We can automate a report nobody needs, summarize a meeting that should not exist or build around a process that needed redesigning long before anyone added AI to it.
So I am less interested in whether AI makes work faster than I am in what becomes visible when it does. Sometimes a new technology solves the problem you gave it. Sometimes it exposes the problem underneath it.
Before you solve the problem again, change how you look at it
If a problem keeps returning, I would spend less time asking what else you can do to it and more time changing how you are looking at it. Start by looking at the history. What have you already tried? If competent people have changed the process, the technology, the structure or the person and the same pattern keeps rebuilding itself, the recurrence deserves to become part of the diagnosis.
Then look for compensation. Who or what is making the current system possible despite the problem? Find the extra spreadsheet, the standing meeting, the unofficial approval, the person everyone calls, the manual reconciliation, the high performer who quietly carries responsibilities that belong in several places. Those workarounds show you where the system people describe and the system people experience have diverged.
Look at ownership without assuming the organization has defined it correctly. Who supplies expertise? Who performs the work? Who feels accountable for the outcome? Who believes they own it? Who has authority to decide when those perspectives conflict? Sometimes the answers line up beautifully. Sometimes you have just found the problem.
Then change lenses. Look at the structure, the relationships, the history, the incentives and what happens informally. Look at who benefits from the current arrangement and who compensates for it. If you have access to people who can see the system differently than you do, use them.
Leave some space for the thing you notice before you can defend it. What do you suspect is happening that you cannot prove yet? Do not build a reorganization around the hunch. Go look for evidence. Ask the strange question. Test the hypothesis. Let it fail if it is wrong.
Seeing more does not guarantee an easy answer. Quite often, it makes the answer less comfortable because the real problem is harder than the presenting one.
The collaboration problem may require redesigning accountabilities. The productivity problem may require leadership to make choices it has avoided. The problem of resistance to change may require acknowledging that employees have perfectly rational reasons not to trust another transformation. The career problem may not be solved by finding another version of the same job.
There is no one magical answer hiding underneath every complicated problem. Large organizations in particular should make us suspicious of anyone selling one. The same symptom can come from entirely different systems, and the same intervention can be brilliant in one part of an organization and destructive in another. That is why I care so much about the seeing.
If you have solved the same problem three different ways and it keeps coming back, I would stop before solution number four. Look at what survived the first three. Look at what people are compensating for, where the accountabilities overlap, what everyone assumes to be true and what does not quite fit the story you have been telling yourselves. Then look again from somewhere else.
Sometimes you will discover that the original diagnosis was right and you simply need a better solution. Sometimes you will find something nobody had named. Sometimes you will realize you have spent years becoming exceptionally good at solving a problem the system keeps manufacturing.
If the problem refuses to stay solved
If your organization or career keeps returning to the same problem despite competent attempts to fix it, I work with leaders, professionals and organizations to look at the system from more than one angle, identify what may be keeping the pattern in place and decide what is worth changing. If you want another set of eyes on something that refuses to stay solved, reach out.
Read more from Trish Calhoun
Trish Calhoun, Systemic Completion Coach & Founder of Put It Down
Trish Calhoun is a Systemic Completion Coach and the founder of Put It Down, a practice built on one premise: the pattern made sense once it just never got an ending. Drawing on systemic constellation work and a career spanning the U.S. Army Signal Corps, Fortune 500 R&D strategy, and enterprise transformation, she works with professionals who have done everything right and are still circling the same ground. Her method doesn't work on the individual, it works on what the individual is carrying. She writes about professional patterns, organizational systems, and the gap between self-awareness and actual change.
