Why Having More Meetings Is Not The Answer

One of the participants in my Conclusion Trap class was grappling with a persistent problem at her company: their website regularly crashed after upgrades. She believed that one of the primary drivers of the problem was poor communication between two teams. The solution was obvious—schedule additional meetings between those two teams.

Along with spending more money on technology, adding meetings to everyone’s already overburdened schedule is an example of conclusion jumping at its finest.

Fortunately, before instituting a new set of meetings, she took the time to deeply understand the situation during our class.

What do companies typically do when there’s poor communication? Schedule more meetings. But that’s another example of jumping to solutions without really understanding the root causes of the issue. Meetings are simply a Band-Aid for a systemic, structural problem.

This is precisely what my student discovered when she dove more deeply into the situation. She saw that the root cause of the poor communication was not a lack of meetings. It was that the critical teams report up through different groups. Here’s her 5 Why analysis:

No alt text provided for this image

Would more meetings have helped? Sure. (Because, you know, that’s just what everyone wants. More meetings.) But that’s another administrative burden that would just slow the company down. Better to improve the ineffective organizational structure and eliminate the need for extra meetings. Which is what the company did, and now the website doesn’t crash.

As Peter Drucker wrote, meetings are by definition a concession to deficient organization. While they’re a necessary evil, they should be rare:?

“But above all, meetings have to be the exception rather than the rule. An organization in which everybody meets all the time is an organization in which no one gets anything done. Too many meetings always bespeak poor structure of jobs and the wrong organizational components. . .?if people in an organization find themselves in meetings a quarter of their time or more -- there is time-wasting malorganization.”

Jumping to conclusions is an unavoidable part of the human condition—even more so at work, where there’s so much time pressure. But by avoiding the conclusion trap, by spending time understanding the problem before you rush to action, you can find more effective, less expensive, and more durable solutions.

Bruce Poch

Leader in Higher Education Admission Practices and Policy; Highly Experienced Higher Education and Independent School Senior Administrator

3 年

Amen!

回复
Kyle Kumpf

Boring Golfer | ?? I’m Writing a ?? About That | Operational Risk Oversight | Governance Risk Compliance | Process Improvement | Certified Enterprise Risk Professional | Project & Portfolio Management

3 年

I like this statement- “meetings are simply a Band-Aid for a systemic, structure problem.”

Ken Eakin

Author, Lean Coach, Consultant, Facilitator, Teacher, Speaker, Nice Guy

3 年

Good article Daniel Markovitz! In “knowledge work”, where the output is to some degree bespoke and unknown (eg writing a research report on a given topic; developing a software application), I usually advocate for an intense “requirements gathering” meeting. Get all the essential players in a room and don’t let them out until they are all in agreement about exactly what they want and exactly what the output is— ie define the standard! So some meetings are good because they pre-emptively avoid a lot of downstream meetings (and a billion emails) to clarify what the heck the project is about. But, of course, there are many meetings that could be handled by email and so are unnecessary. How to know the difference? As with everything, one has to think (5 Whys) about what the purpose of the meeting is and if it’s necessary— and if it could be avoided in the future. As a general rule: meet more often at the beginning of a project so you can execute swiftly throughout the rest of it. Then only brief, periodic check-ins are necessary.

回复

要查看或添加评论,请登录

Daniel Markovitz的更多文章

社区洞察

其他会员也浏览了