Free guide

IDS issue solving: identify, discuss, solve — a worked walkthrough

The issue-solving block is where a weekly leadership meeting earns its keep: roughly an hour spent turning problems into decisions and owned to-dos. This guide walks through the identify–discuss–solve method step by step, with a full worked example, a sample issues list, and the mistakes that turn it into an hour of talking.

IDS (Identify, Discuss, Solve) is the issue-solving method popularized by the Entrepreneurial Operating System® (EOS®). Enginely is independent and not affiliated with or endorsed by EOS Worldwide, LLC; the method is described here for teams running this style of meeting.

Why issue solving is the heart of the meeting

In a well-run 90-minute weekly meeting, the first half hour is fast reporting: scorecard, quarterly priorities, headlines, last week's to-dos. Anything off track is not discussed — it is dropped onto the issues list. The remaining hour is spent solving those issues. That ratio is deliberate. Most meetings spend 90% of their time on updates and 10% on problems; this format flips it.

An "issue" is anything that needs the team's attention: a problem, an obstacle, an opportunity, a decision that needs making, or an idea worth testing. If it keeps a number, a priority, or a person from being where they should be, it belongs on the list.

The three steps

1. Identify — find the real issue

The issue as written on the list is usually a symptom. "Leads are down" is a symptom. The goal of this step is to get to the root cause in a sentence or two. The person who raised it states it plainly; the team asks short, clarifying questions — "since when?", "compared to what?", "what changed?" — until someone can say "the real issue is…" and the room agrees.

This is usually the longest step, and it should be. Once the real issue is clear, the solution is often obvious. Teams that skip identify spend 20 minutes solving the wrong problem.

2. Discuss — everyone says it once

With the real issue named, each person contributes what they know: facts, options, concerns, what they have seen work elsewhere. The rule is to say it once. Repeating a point louder, or circling back to relitigate, is the single biggest time sink in issue solving. The facilitator's job here is to notice when the discussion has stopped producing new information — usually far sooner than people think.

3. Solve — a decision, an owner, a date

An issue is solved when it ends in one of three ways: a decision the team commits to; a to-do with an owner and a due date (usually within seven days); or an explicit decision that it is not actually an issue and can be dropped. Anything else — "let's keep an eye on it", "we should think about that" — is not solved and will be back next week. When consensus is not reached, the leader decides; the team leaves united behind the decision even if not everyone agreed.

Worked example: "Leads are down"

Here is how one issue moves through the three steps in a real-feeling meeting (made-up data). The scorecard shows new qualified leads at 22 and 19 against a goal of ≥ 25, two weeks running, so Marcus (marketing) dropped it to the issues list.

  1. Identify (6 minutes). Marcus: "Leads have missed goal two weeks in a row." Sarah asks whether traffic is down. It isn't — website visits are flat. Priya asks whether it is all lead sources. It turns out paid search is fine; the drop is entirely from the demo-request form. Jordan asks what changed. The pricing page was redesigned three weeks ago and the demo button moved below the plan cards. Real issue: the pricing-page redesign buried the demo request button.
  2. Discuss (4 minutes). Priya says demo requests convert best of any source. Marcus says the designer can move the button back in a day. Derek asks whether they know it is the button and not seasonal; Marcus has the form's conversion rate — it halved the week the page changed.
  3. Solve (1 minute). Decision: restore the demo button above the plan cards now, and test the new layout properly later. To-dos: "Marcus — move the demo button back and confirm it's live by Thursday" and "Marcus — report demo-form conversion next week." The issue is marked solved.

Eleven minutes, one decision, two dated to-dos. Next week the scorecard will show whether it worked; if not, it comes back as a new issue with better information.

Sample issues list

A healthy weekly issues list for a leadership team might look like this before the meeting (made-up data). Owner is whoever raised it; the team prioritizes before solving.

#IssueRaised bySource
1New qualified leads below goal two weeks runningMarcusScorecard
2AE hiring rock off track — only 3 qualified candidatesPriyaPriority
3Weekend support response times slipping past 12 hoursAishaScorecard
4Partner API rate limits blocking two integrationsJordanHeadline
5Hiring plan vs. budget mismatch for Q4DerekFinance
6Largest customer asking for a custom SLASarahOpportunity
7Two to-dos missed three weeks in a rowSarahTo-dos
8Should we attend the regional trade show in November?MarcusDecision
9Onboarding checklist out of date after the product updateJordanProcess
10Receivables over 60 days above goalDerekScorecard

Prioritize before you solve

Never solve issues in the order they were written down. Before starting, the team quickly picks the top three — the issues that, if solved, would matter most this week. Then work them in order, one at a time, to completion. When the three are done, pick the next three. It is normal to get through only a handful in a meeting; the rest carry to next week, and some will have solved themselves or turned out to be symptoms of an issue you already fixed.

In the list above, a team might start with #2 (a quarterly priority at risk), #1 (revenue pipeline), and #3 (customers feeling it right now), and leave the trade-show decision for later.

Tip: keep issues in the meeting, not in side conversations. An issue solved in a hallway without the team never reaches the to-do list, and the same problem turns up again two weeks later with half the context.

Common issue-solving mistakes

How Enginely supports the issue-solving block

In Enginely, anything off track in the first half of the meeting — a scorecard number, a quarterly priority, a missed to-do — can be dropped onto the issues list with one click. During the issues segment the section timer keeps the block honest, each issue is solved in place, and solving one prompts for the follow-up to-do with an owner, so the decision leaves the meeting as a commitment. Solved issues and new to-dos go into the end-of-meeting summary email.

If you are running the meeting on paper for now, the free toolkit on the weekly meeting agenda page includes a printable agenda, a scorecard and priorities tracker, and a facilitator slide deck with an issues slide. For the numbers that feed the list, see the scorecard template; for the quarterly priorities, the rocks template.

Run it live

Spend your meeting solving, not reporting.

Enginely keeps the reporting half fast and routes everything off track into a timed issue-solving block with owned follow-ups. Free for up to 10 people.

Frequently asked questions

What does IDS stand for?

Identify, Discuss, Solve — a three-step method for working through issues in a team meeting, popularized by EOS®. Identify the real root issue, let everyone contribute once, then end with a decision or a to-do with an owner and date.

How long should IDS take in a weekly meeting?

In a 90-minute weekly meeting, the issue-solving block is usually about 60 minutes. Individual issues often take 5 to 15 minutes once the team gets practiced at identifying the real issue quickly.

How do you prioritize an issues list?

Before solving anything, the team picks the top three issues that would matter most if solved this week, then works them one at a time to completion before choosing the next three. Never work the list in the order it was written.

When is an issue considered solved?

When it ends in a decision the team commits to, a to-do with an owner and a due date, or an explicit agreement that it is not really an issue and can be dropped. "Let's keep an eye on it" does not count.

What if the team cannot agree on a solution?

After everyone has contributed once, the leader decides. The team commits to the decision even if not everyone agreed, and the issue comes back only if new information appears.

What kinds of things belong on the issues list?

Anything that needs the team's attention: problems, obstacles, off-track numbers or priorities, decisions to make, opportunities, and ideas worth discussing.

Is Enginely an official EOS® tool?

No. Enginely is an independent product and is not affiliated with or endorsed by EOS Worldwide, LLC. It supports the same style of weekly meeting and issue solving many teams already run.