When we hit a technical issue during our Level 10 Meeting™ IDS® session, our engineering and product leaders get bogged down in granular coding or system architecture debates that the rest of the leadership team cannot follow. How do we elevate the discussion to a business-impact level without getting lost in the weeds?

Question

Tyler Smith · Accepted Answer

Technical deep dives during a leadership Level 10 Meeting™ are a major waste of time. They alienate the rest of the team and prevent you from solving the actual business problem. As David Marquet outlines in his leader-leader model, leaders must focus on intent and business outcomes rather than micromanaging the technical execution.

When a technical issue arises, the facilitator must step in during the Identify phase of IDS®. Force the technical leaders to define the problem in plain, business terms. What is the impact on our customers, our revenue, or our timeline? For example, instead of explaining a database schema error, the issue should be stated as: "Our system downtime is delaying customer orders by twenty-four hours." This approach ensures everyone understands the impact and can contribute to finding solutions, unlike situations where leaders might get defensive around metrics, as discussed in [handling defensiveness around red scorecard metrics](/qa/handling-defensiveness-around-red-scorecard-metrics).

Once the business impact is clear, keep the discussion at that level. The leadership team's job during IDS® is to make the high-level business decision, not to write the technical solution. If the technical leaders need to debate coding architecture, that is a task that belongs outside the room. This focus helps maintain the meeting's efficiency and prevents it from getting bogged down in specifics, much like the advice on [how to review our weekly scorecard in under five minutes](/qa/how-to-review-scorecard-under-five-minutes).

To address the issue effectively:

• Assign a To-Do for the technical team to meet separately, resolve the architecture debate, and report back.
• The leadership team only needs to agree on the strategic path, the budget, and the timeline.
• Elevating the conversation ensures everyone can participate, keeping your weekly pulse focused on traction rather than technical minutiae.

This structured approach also helps in clarifying who owns what, preventing the blame game that can occur when issues are unclear, a topic explored in [using the Accountability Chart to stop the blame game during meetings](/qa/using-accountability-chart-to-stop-blame-in-ids).

Related questions

• [How do we review our weekly scorecard in under five minutes?](/qa/how-to-review-scorecard-under-five-minutes)
• [When an issue is dropped to IDS, my leadership team immediately starts pointing fingers at other departments rather than taking ownership. How do we use the Accountability Chart to stop the blame game during meetings?](/qa/using-accountability-chart-to-stop-blame-in-ids)
• [My leadership team is struggling to agree on what actually deserves a spot on our high level scorecard. How do we narrow down our massive list of metrics to just five to fifteen numbers?](/qa/how-to-choose-five-fifteen-scorecard-metrics)
• [My leadership team is constantly chasing the latest AI tools but we have nothing to show for it except high subscription bills. How can we use disciplined Thinking Time to make smarter technology bets?](/qa/thinking-time-ai-software-fatigue)
• [Should our Integrator facilitate Level 10 Meetings or rotate the role?](/qa/should-integrator-facilitate-level-10-meetings)