Why Some EOS® Teams Talk About Issues in IDS® But Never Solve Them
I was working with a leadership team recently when a recurring delivery issue reached the top of their Issues List. The business had grown quickly. Sales was closing larger, more complex work, but Operations was missing delivery dates and margins were being squeezed by last-minute changes. The team prioritised the issue in its Level 10 Meeting® and moved straight into IDS®.
First, they Identified the real issue: The Sales Director was approving customised work and confirming delivery dates before Operations had checked capacity.
Then they Discussed the impact. Operations gave three recent examples. Finance showed the margin problem. Client Success explained what happened when the customer discovered the date was fiction with a logo attached. Nobody disagreed with the facts.
Finally, they reached Solve. “Let’s tighten up communication.” They agreed to add another field to the handover form, set up a weekly Sales and Operations catch-up, and remind the Sales team to check capacity before making promises.
The issue was about to be marked solved. Then I asked, “What have you decided Sales can no longer do?”
There was silence. Nothing had changed. Sales could still confirm a delivery date without approval. Operations still had no authority to reject the work. The Sales Director could still bypass the agreed process when a valuable deal was on the line.
Nobody in the meeting room was related. The Sales Director had simply been with the Founder since the early days, delivered a lot of revenue, and built up years of trust. That history carried weight.
The team had Identified the Issue. They had Discussed it thoroughly. They had reached the Solve step but replaced a decision with two meetings, a form, and a reminder. That's exactly how capable leadership teams talk about issues in IDS but never actually solve them.
Ninety’s Issues tool helps teams work through issues using IDS® and keep decisions visible so the work doesn’t stop when the meeting ends.
The Problem Is What Teams Call “Solved”
Most leadership teams I work with know how to IDS. They prioritise the right issue. They get below the surface. They bring the relevant facts into the meeting. They often identify the cause with impressive speed. The trouble begins when Solve becomes a polite way to end the conversation.
Everyone agrees communication needs improve. Everyone agrees accountability needs to be clearer. Everyone agrees the current situation can't continue.
The team feels aligned. The issue gets checked off the list. But nothing materially changes.
A true Solve closes the gap between what the team now understands and what the business will do differently. It may change a decision right, a behaviour, a priority, an expectation, or a consequence. It may create a To-Do, but the To-Do is not automatically the Solve.
“Sales & Operations will communicate earlier” is an intention. “Sales cannot confirm a delivery date until Operations approves capacity” is a decision. Big difference.
When an IDS meeting gets stuck, the team doesn't always need more Discussion. Sometimes it needs to stop accepting an incomplete Solve to a clear issue.
Really good leadership teams aren't issue-free. They solve issues quickly and permanently. They get clear on the cause, make the decision, assign the action, and follow through, rather than allowing the same problem to return next week under a slightly different heading.
4 Reasons Teams Don't Solve Issues
1. It requires saying who dropped the ball.
Let me start by saying that not every issue is somebody’s fault. Plenty are caused by unclear processes, poor data, a lack of accountability, or a business that has simply outgrown the way it used to work.
But sometimes the process is clear and a person has simply ignored it. That's the part teams often struggle to name.
In the opening example, the leadership team kept referring to “the Sales process.” The process was not sneaking into client meetings and promising impossible dates. A respected leader was choosing to bypass an agreed gate.
Naming the person doesn't require humiliation or blame. It just requires accuracy. The person may be a peer, a friend, the longest tenured employee, or the person who helped build the business when everybody else was still deciding whether to join it. The history is real, but it doesn't change the issue.
I see the same pattern in family businesses, only with extra voltage. A team can identify that a sibling in Sales keeps bypassing margin limits, discuss the commercial impact perfectly, then solve it with refresher training because nobody wants to decide whether the family member will be held to the same standard. The family relationship makes the decision harder, but it doesn't change what needs to be decided.
2. It means somebody’s answer is wrong.
The Discuss portion of IDS allows several perspectives to coexist. But Solve usually forces you to settle on one.
At some point, the team has to choose one course of action. That also means someone's suggestion won't be chosen and may be rejected in front of their peers.
Healthy teams are able to disagree and commit. Less healthy teams will keep discussing until the sharp edges have sanded off every option. The result is often a compromise that everybody can tolerate and nobody believes will actually work.
One leader wants to stop accepting a type of low-margin work. Another wants to increase the price. A third wants to improve the process. Instead of making a decision, the team agrees to “monitor it more closely”. In that scenario, nobody loses the argument but the business keeps losing money.
A real Solve doesn't require declaring one person clever and another person foolish. But it does require the team to choose, even when the choice means that another proposed answer wasn't the right one.
3. It costs political capital.
Leadership teams don't operate in a vacuum. People know who signs off on their Rocks®, their bonus, or their next promotion. They know whose support matters. They know which leader can make the next six months easier or more difficult.
In a founder-led business, the political cost may be especially obvious. The Founder says they want to be challenged, but the team has also watched what happens when somebody pushes too hard on a favourite idea or a long-standing relationship.
So people edit themselves. They ask another question instead of making the point. They suggest more data. They propose a review next quarter. Everyone becomes deeply interested in the process map.
The safest sentence in many leadership meetings is, “I think we need more information.” Sometimes that's true. But sometimes it means, “I know what the decision should be, but I do not want to spend the political capital required to say it.”
4. It is an enforcement commitment.
Making the decision once is only the beginning. You then have to follow through on that decision when the same pressure returns next week.
Teams will agree to almost anything in a calm meeting. The test comes when a major client wants an exception, the quarter is behind target, or a powerful leader asks, “Can we just do it this once?” That's where weak Solves collapse.
The team may have agreed that Operations must approve capacity, but will the Integrator back Operations when Sales pushes through a valuable deal anyway? Will the Founder support the rule when the customer is important? Will anybody call it out when the exception comes from a high performer?
A solve doesn't stop at the decision. It's a commitment to enforce the decision after the meeting is over. And that's often the part the team is really avoiding.

When the Solve Sounds Good but Changes Nothing
Leadership teams rarely close a difficult issue by announcing, “We have decided to avoid this.” They use solutions that sound constructive.
“We’ll communicate better.”
“The GM will have a word with him.”
“We’ll review it next quarter.”
“Let’s create a clearer process.”
“We all need to be more respectful.”
Any of those may form part of a solution, but none is automatically a Solve. A process change doesn't solve a leader choosing to ignore the process. A private conversation doesn't solve unclear accountability unless the outcome comes back to the leadership team. A review date doesn't help when the team already has enough information to decide.
This is why teams can discuss the same underlying problem under several headings.
A leader who keeps promising work the business can't deliver appears first as a capacity issue, then a forecasting issue, then a handover issue, then a customer-expectations issue.
Each issue is real. But if the same behaviour, unclear authority, or unenforced decision sits beneath all four, the team is solving the visible symptoms while leaving the real problem comfortably in its place.
Before marking an issue solved, ask:
Would this Solve prevent the same issue from happening again tomorrow?
If the answer is no, the action may still be useful. It's simply not the full Solve. Keep the real issue visible until the team has made a clear decision.
5 Questions Before You Mark an Issue Solved
Before closing an issue, ask:
-
Would we make the same decision if this person did not report to the Founder, was not the longest-serving hire, or was not our best mate outside work? If the answer changes with the relationship, status is overriding the issue.
-
Are we solving the issue or protecting the relationship from discomfort? A clear decision may feel uncomfortable. Avoidance doesn't protect the relationship. It only leaves the issue unresolved.
-
Which Seat owns this decision? Use The Accountability Chart®, not tenure, personality, hierarchy, or who speaks loudest.
-
Who hasn't said what they really think? Ask the quieter leader, the newer executive, or the person closest to the work. Silence can hide the most useful truth in the meeting.
-
What will actually change, who owns it, and by when? If the answer is “we will communicate better,” keep going. The issue has received a pleasant send-off, not a Solve.
These questions don't make IDS harsher. They just stop politeness, politics, and history from replacing the process.
Final Thought
The leadership team from the opening went back to the issue before moving on. They didn't need another form. They needed a decision.
Sales couldn't confirm customised scope or a delivery date until Operations had approved capacity. Operations had the authority to reject an incomplete handover. The Integrator would review any exceptions in the weekly meeting rather than allowing them to disappear into private conversations. The Founder also agreed not to override the decision after the meeting because a deal felt too important to lose.
The Sales Director wasn't humiliated. He was given a clear boundary, the same one the rest of the business could now rely on. That was what the first Solve had avoided.
Really good leadership teams are not the ones with the fewest issues. They're the ones that solve them quickly and permanently. And they don't prove their ability to IDS by just getting through the three steps. They prove it by making the S mean something.
Identify creates clarity about the real issue. Discuss brings the relevant facts and perspectives into the room. Solve decides what changes, who owns it, and whether the team will follow through.
The pattern looks exactly the same when a team is related by blood, but it also appears when people are bound by tenure, friendship, hierarchy, or fear.
If the same issue keeps returning in your Level 10 Meeting, don't assume your team needs more Discussion. Instead, look closely at what you called the Solve. That's often where the real issue is hiding.