IDS: Identify, Discuss, Solve — The 60 Minutes That Drive Execution
Every leadership team has a list of problems they've been "discussing" for months. IDS is the protocol that forces those problems into resolution — one concrete action at a time.
Open your team's Slack right now. Scroll back three months. Find the message where someone flagged a problem — a partner underperforming, a client complaining about delivery inconsistency, a pricing issue that kept coming up in proposals. Now ask yourself: was that problem actually resolved, or did it just stop being mentioned?
In most service businesses, the answer is the second one. Problems don't get solved. They get discussed until people get tired of discussing them, then they sink below the surface — still causing damage, just quieter about it.
Gino Wickman designed IDS — Identify, Discuss, Solve — as the antidote to this specific disease. It's a problem-solving protocol built into the weekly Level 10 Meeting, occupying the final sixty minutes. And it works because it does something that most meeting cultures actively resist: it forces closure.
Not "let's revisit this next week." Not "I'll think about it." A specific person commits to a specific action by a specific date. Every time. No exceptions.
Why Most Teams Confuse Discussion with Progress
There's a seductive feeling that comes from a "good discussion." Everyone had their say. Different perspectives were shared. The team feels aligned. The meeting felt productive. And then nothing changes.
This isn't a failure of intelligence or commitment. It's a structural failure. Most meetings don't have a mechanism that converts discussion into action. They have agendas, sure. They have time blocks. But when a difficult issue comes up — the kind that requires someone to do something uncomfortable, like confront an underperforming partner or change a pricing policy that isn't working — the natural instinct is to defer.
"Let's get more data." "Let's see how next month plays out." "Let's schedule a separate meeting to deep-dive on this." Each of these sounds reasonable. Each of them is a mechanism for avoidance.
IDS eliminates avoidance by design. Once an issue enters the protocol, it doesn't leave without a to-do attached to it.
The protocol is deceptively simple. Three steps. But each step has specific disciplines that most teams get wrong on their first dozen attempts.
Step One: Identify the Root Cause
Symptoms Lie. Dig Deeper.
The issue list going into IDS might say: "Partner X hasn't delivered an engagement in 90 days." That's a symptom. It's observable. It's measurable. But it tells you nothing about what to actually do.
Identification means peeling back the layers. Why hasn't Partner X delivered? Possibilities multiply fast:
Pipeline problem. They have no prospects. They don't know how to generate leads. They're relying on the ecosystem to hand them opportunities and the ecosystem hasn't delivered.
Confidence problem. They have prospects but can't close. They're uncomfortable with the sales conversation, particularly the pricing discussion. They discount to avoid rejection, and the discounted deals aren't worth delivering.
Positioning problem. They're too broadly positioned. Their message is "I help companies with strategy," which means nobody thinks of them for anything specific. Prospects can't connect their pain to this partner's expertise.
Engagement problem. They've mentally checked out. The methodology doesn't excite them anymore. They're collecting their certification credential but not investing energy in the ecosystem.
Each of these root causes requires a completely different response. Sales coaching. Positioning workshop. A diagnostic conversation about commitment. If you skip identification and jump straight to "someone should call Partner X," you'll address the symptom while the root cause continues to rot.
The discipline of identification usually takes two to five minutes per issue. Ask one question repeatedly: "Why?" Not aggressively. Curiously. "Partner X hasn't delivered in 90 days." Why? "Their pipeline is empty." Why? "They haven't attended the last two sales training sessions and their LinkedIn hasn't been updated since certification." Now you have something actionable.
"The issue on the list is almost never the actual issue. It's the visible consequence of something deeper. Your job in IDS is to find the deeper thing."
One common mistake: letting the person closest to the issue control the identification. If Partner X's account manager is asked "why haven't they delivered?", the answer will often be protective — "they've been busy with other commitments" or "the market is slow in their region." These aren't root causes. They're explanations designed to avoid an uncomfortable truth. Fresh eyes from other team members often find the real cause faster.
Step Two: Discuss — But Only Once
The Anti-Tangent Protocol
Once the root cause is identified, the team discusses it. Every perspective matters. The operations lead might see something the sales lead doesn't. The person running partner support might have context from private conversations. Discussion surfaces information that no single person holds.
But discussion has a lethal tendency: it expands. One issue branches into three related issues. A conversation about Partner X's pipeline becomes a debate about whether the entire sales methodology needs overhauling. Someone mentions that the problem "reminds them of" something they saw at a conference, and suddenly the discussion has traveled three time zones from the original issue.
Wickman's rule is absolute: discuss the issue fully, but discuss it once. If the discussion surfaces a related-but-different problem, that new problem goes on the issues list for prioritization. It doesn't get solved in the current thread.
The facilitator's job during Discussion is traffic control. Three interventions they need to make repeatedly:
"That sounds like a separate issue. Let's add it to the list." This is the most common intervention. It validates the observation while protecting the current discussion from hijacking.
"We've heard from three people. Does anyone have a genuinely different perspective?" This prevents the echo chamber where five people say the same thing in slightly different words, mistaking agreement for thoroughness.
"Are we ready to solve this?" This is the transition prompt. Most teams won't make it voluntarily — there's always one more angle to consider, one more context to share. The facilitator has to call the turn.
A healthy discussion for a typical issue lasts five to ten minutes. If you're spending twenty minutes discussing a single issue, either the root cause wasn't properly identified (go back to step one) or the issue is actually multiple issues disguised as one (split it and reprioritize).
Step Three: Solve with a To-Do
Who Does What by When
The solve step is where most meeting cultures fail completely. They've done the hard work — identified the root cause, discussed it thoroughly — and then they produce a "solution" like: "We should improve our partner onboarding." That's not a solution. That's a sentiment.
A proper IDS solve has three components, and all three are non-negotiable:
Who. A single person. Not "the team." Not "operations." One human being who is accountable for this action item. If two people share responsibility, nobody is responsible.
What. A specific, verifiable action. Not "look into the partner onboarding issue." Instead: "Review the last three partner onboarding surveys, identify the top two pain points, and propose a fix." That's verifiable. Next week, it's either done or it isn't.
When. A deadline — almost always "by next week's L10." The seven-day cycle is the natural heartbeat of IDS. Longer deadlines create drift. If the action genuinely requires more than a week, break it into a first step that can be completed in seven days.
Some issues are bigger than a single to-do. A strategic issue like "our certification pricing isn't competitive" might require market research, competitor analysis, and financial modeling before a decision can be made. In that case, the IDS solve isn't "fix the pricing." The solve is: "Run competitive pricing analysis across five comparable certifications and present findings at next week's L10." That keeps the seven-day cycle intact while progressing toward the larger solution.
The solve step also includes a decision that teams find surprisingly hard: dropping issues. Some items on the list aren't actually important — they felt urgent when someone raised them, but after identification and discussion, the team realizes they're noise. "This isn't worth solving right now" is a valid resolution. Cross it off and move on.
The Compound Effect of Weekly Resolution
Here's the math that makes IDS transformative. If your team resolves five issues per week through IDS — modest by most L10 standards — that's 260 resolved issues per year. Not 260 items discussed. Not 260 topics raised. Two hundred and sixty problems that entered the meeting with no owner and left with a specific person doing a specific thing by a specific date.
In service businesses without this discipline, those same 260 issues would circulate endlessly. Some would eventually resolve themselves. Some would get handled reactively when they became crises. Many would simply accumulate, creating the organizational sludge that makes everything slower and harder than it needs to be.
The compound effect works in two directions. First, problems shrink because they're caught early. A pricing erosion that's been happening for two weeks is a small fix. A pricing erosion that's been happening for six months requires a strategic overhaul. Second, the team's problem-solving capacity grows. The more you practice IDS, the faster you get at identification. Teams that have been running L10s for a year can often move through the entire protocol in under five minutes per issue — root cause identified, discussion completed, to-do assigned.
But the most powerful effect is cultural. When a team knows that every issue they raise will be addressed — not next quarter, not when someone gets around to it, but this week — they raise issues earlier. The partner who notices a quality problem in a colleague's delivery mentions it on Tuesday instead of hoping it resolves on its own. The sales lead who sees a concerning pipeline trend flags it immediately instead of waiting until the revenue miss is obvious.
IDS doesn't just solve problems. It creates an organization where problems want to be found — because being found is the fastest path to being fixed.