Solve issues, don't just discuss them. Identify, discuss, solve.

Identify happens before the meeting

"What problem are we actually solving?" is the first question, and answering it well is part art, part science. The honest truth is that most of this work happens before anyone sits down. Whoever runs the meeting — the integrator — has to groom the issues list ahead of time: read each item first, clarify the wording, and make sure it's framed so the whole team knows what problem it's pointing at. You train the team to put issues on the list, but you don't let raw, half-formed items go straight into discussion.

That last distinction is one people miss constantly. Some items on the list are genuine problems to solve; others are just someone communicating information to the team. They need completely different handling — an update gets an acknowledgment and maybe an initial reaction, not a twenty-minute problem-solving session. Sorting the problems from the announcements before the meeting starts is unglamorous, and it's most of what makes the discussion that follows actually go somewhere.

Prioritize — solve the few that matter

You will never solve every issue in a single meeting, so don't try. The integrator can pre-prioritize the list, or the group can rank it together right before working it. This isn't hard — relative importance is usually obvious the moment you look. The root cause of an outage outranks prospects not showing up to demos, and everyone in the room knows it. Order the list by what matters most, work it from the top, and accept that the bottom items wait for next week. Solving the two issues that matter beats touching all ten and resolving none.

Discuss — productive friction, threaded carefully

The discussion itself is where the person running the meeting earns their keep, because the job is to thread a genuinely difficult needle: keep the conversation productive and moving without shutting down the honest debate that actually solves things. Some friction is good and necessary — you want people arguing the real trade-offs. But when a conversation stalls or starts circling, time-boxing it forces a decision or a deferral. And the friction has to stay professional; if a discussion gets too heated, the integrator has to step in and mediate. A good issues discussion runs hot enough to surface the truth and cool enough that people still want to be in the room. (That balance is the same muscle as making sure every voice is heard in the weekly meeting.)

Solve — and close by consent

The step that gets skipped is the actual close. It's not enough to feel like you've discussed something thoroughly; the issue has to be resolved into a decision and, usually, an owned action. And here's a small ritual that mattered more than it sounds: I almost never marked an issue closed unilaterally. I'd ask the leadership team for permission to close it — "we've solved this, are we good?" — rather than declaring it done myself.

That ask does two things. It guards against premature closure, where the loudest voice declares victory and a real problem quietly stays unsolved. And it creates a shared, explicit moment of resolution — the team agrees, out loud, that this one is handled. Closure by consent is what turns "we talked about it" into "we solved it," and it's the difference between an issue leaving the list and an issue pretending to.

Rehashing isn't always failure: the list is a register

Now the correction to the conventional wisdom, because "get the issues list to zero" is advice that sounds right and is sometimes wrong. Some issues need to be rehashed — that's just the truth. If churn shows up red every single week, it should keep coming up as an issue, week after week, until you make real progress against it. That recurrence is not a failure of the process. It is the process.

This reframe matters because teams that treat the list as a checklist start optimizing for the wrong thing — closing items to feel productive, rather than solving problems that are genuinely hard and genuinely take time. A big, structural issue like churn or a stalled growth motion won't close in a week, and pretending it has is worse than honestly carrying it. The test isn't whether an issue recurs; it's whether each time it recurs, you've moved the ball. A standing issue with steady progress is healthy. A standing issue that's discussed identically every week with nothing changing — that's the actual failure.

Beat groupthink: come with three solutions

The integrator's job through all of this is to keep the solve part of the meeting running efficiently — groomed list, clear priorities, threaded discussion, clean closes. But there's one technique I wish we'd used more than we did, and I'd push any team to adopt it for their biggest issues: prepare in advance.

For a high-priority issue — say, a churn problem you know is coming up — ask every leadership team member, ahead of the meeting, to come with three potential solutions, and have each of them present. It does two powerful things at once. It forces genuinely intentional problem-solving instead of off-the-cuff reactions in the room. And it directly counters the groupthink that quietly dominates most leadership teams, where the first strong opinion anchors everyone and the real alternatives never get voiced. Eight or nine candidate solutions on the table, each thought through in advance, is a radically better starting point than a blank discussion. That's the difference between a team that discusses its hardest problems and a team that actually solves them.