The Meeting That Should Have Been a Query

In a single quarter, I observed 34 recurring meetings at a 90-person organization that existed solely to compensate for absent dashboards, and 6 dashboards that existed solely to avoid conversations that needed to happen face-to-face.

When does a meeting become a database query in disguise?

A meeting becomes a database query when its primary output is a data point that could be obtained from an existing system without assembling humans in a room.

I sat through a 45-minute weekly pipeline review at a SaaS company. Twelve people attended. The format was consistent: each regional sales lead read their pipeline numbers aloud while others listened. No decisions were made. No actions were assigned. The meeting existed because the CRM dashboard was poorly configured and no one had the permissions or the skills to fix it. Forty-five minutes, 12 people, every week, for a query that should have taken 30 seconds.

I counted 34 meetings of this type across the 90-person organization. Status updates read aloud from spreadsheets. Headcount reports assembled by hand from 3 systems. Project timelines reconstructed from memory because the project management tool was 2 sprints out of date. Each meeting was a workaround for an information infrastructure failure. The total cost was 68 person-hours per week, equivalent to 1.7 full-time employees doing nothing but attending meetings that compensated for broken dashboards.

When does a dashboard become an avoidance mechanism?

A dashboard becomes an avoidance mechanism when it replaces a conversation that requires judgment, nuance, or the discomfort of delivering bad news directly.

The same organization had the opposite problem in 6 cases. The engineering team had built an elaborate release readiness dashboard that aggregated 14 metrics into a green/yellow/red status. The dashboard was technically impressive. It was also used to avoid a conversation that the VP of Engineering needed to have with the VP of Product about scope creep that was delaying 3 of 5 active projects. The dashboard showed yellow. The situation required a conversation about trade-offs that no dashboard could mediate.

I watched a product manager refresh the sprint velocity chart during a retrospective instead of addressing the fact that 2 team members had been pulled onto support escalations for 40% of the sprint. The chart showed a velocity decline. The cause was not in the chart. It was in the room.

What determines the correct communication medium?

The correct medium depends on whether the information is structured or unstructured and whether the response requires computation or judgment.

Structured information with computational responses belongs in dashboards. “How many tickets are in the backlog?” is a query. Unstructured information requiring judgment belongs in conversation. “Should we delay the release to address the performance regression?” is a discussion. The pathology I observed is bidirectional: organizations hold meetings for queries and build dashboards for discussions. Both are expensive substitutes for choosing the right medium.

The question is not whether to have meetings or dashboards. It is whether the organization has the discipline to match the medium to the message. That discipline requires naming the problem, which is itself uncomfortable, because admitting that a meeting is a workaround for a broken dashboard means admitting the dashboard is broken, and admitting that a dashboard is avoiding a conversation means admitting the conversation is overdue.