Dear Dr. Yeahbut …

We have too many meetings.

I’m sure I’m not the first person to gripe about this, but if I’m not, why does it keep on happening? More important, what can I do about it? I need to do actual work, but easily half of every week goes into meetings. Help!

– Burnt

Dear Burnt …

Not all meetings are created equal, so there’s no one answer. In even numbers there are four types of meeting: Status, decision-making, information-sharing, and team working sessions. One at a time:

Status Meetings

These are weekly meetings of project team members and only project team members. Each team member reports on whether the tasks they were supposed to start started, the tasks they were supposed to finish actually finished, and, if not, what their plan is to get back on track.

Project status meetings are essential project-management tools. No, they aren’t an efficient way to collect task status information for the PM’s project status reports. They’re essential because they’re the most effective way to apply peer pressure to sub-par-performing team members.

If you’re on the invitation list for more than two weekly status meetings the problem isn’t that you have too many meetings. It’s that you’re assigned to too many projects. That’s an even harder problem to solve, but it’s a different problem.

Get out of meetings free card: You don’t get one. Project status meetings aren’t optional, even for team members who started and finished their tasks on time. These team members are, after all, the ones that exert the most and most effective peer pressure.

Decision-making meetings

There are, you might recall, five ways to make a decision: Authoritarian (I make it); Consultative (I collect informed opinions before making it); Consensus (we don’t all agree with the decision but do all agree to it); Democratic (we vote, the majority wins, and the minority pretends to accept it); and Delegated (someone else gets to make it).

Of these, the only decision style that calls for a meeting is consensus – the most expensive way to make decisions, delivering the second-lowest-quality results (voting is even worse). For most decisions, consultation strikes the best balance between quality and efficiency. Leaders should make it their go-to, reserving consensus for situations where stakeholder buy-in matters more than anything else.

Get out of meetings free card: If it’s your meeting, don’t have it. Consult or delegate the decision instead.

If you’re one of the invitees, politely decline the invitation and suggest a 15-minute one-on-one consultative call instead.

Information-sharing meetings

When managers were less buffeted by information, the conveners of information-sharing meetings asked, “Who needs to know about this?”

As most managers are buried in information, this quaint notion from days gone by has, or at least should have been supplanted by a different question: “Who can’t function effectively without this information?”

One more point about information-sharing meetings: Attendees are prone to try to turn them into decision-making meetings, on the grounds that “Why are you telling me this if you don’t want my opinion about it?”

Get out of meetings free card: If you’re the convener, ask yourself what it is about this information that requires a meeting and not just an internal blog post with a comments section for any back-and-forth that’s called for.

If you’re on the invitation list, ask if you won’t end up just as well informed by reading the meeting notes.

Team working sessions

Well, if the team really is getting work done then this counts as time you’re spending getting work done.

Get out of meetings free card: Even when teams met in 3D in a whiteboard-equipped room, working sessions should have been limited to seven participants. Limit web-conferenced meetings to five. If you’re the convener, adhere to these limits. If you’re invited and don’t need to add your voice to the proceedings, brief another participant … one you trust … with your perspective, and let the convener know you’ll accept the results.

Bob’s last word: Layered on top of this brief meeting taxonomy is a meta-purpose, which is that meetings are where team members get to know each other, building trust and shared purpose as they do.

Getting work done is transactional. It’s what can be tracked, and what pays the bills.

But relationships do matter. Leaders who ignore them find the teams they lead gradually enter a long, slow slide into dysfunction.

So along with discontinuing meetings that shouldn’t ever be scheduled, wise leaders find ways to replace their relationship-management meta-purpose.

“Who are you going to believe?” Groucho Marx famously asked, “Me or your own eyes?”

The Groucho Question came to mind as I read an intriguing, if conspiracy-oriented opinion piece by James Schmitz Jr., a senior economist at the Federal Reserve Bank of Minneapolis. Schmitz’s contention is that home-building is trapped in 19th century technologies and methods that have prevented productivity increases in that sector for a matter of decades. (“Homebuilding must modernize,” StarTribune, 5/2/2021).

His solution: “Rather than manufacturing homes in factories, they are constructed outside, with a centuries-old technology sometimes called the “stick-built” method.”

He’s the “Me” part of the Groucho-ism. As one who consults on and writes about matters of organizational effectiveness, I found his contention appealing.

As the owners of a downtown condominium who, by HOA mandate had been required to have our balcony door replaced … twice; the first replacement having been problematic … my wife and I recently had the opportunity to see Schmitz’s theory applied in actual reality (and isn’t it strange to live in an era where I have to specify which reality I’m writing about).

We were Groucho’s “… or your own eyes,” as we watched two clearly expert individuals remove the offending door panels and replace them with (presumably) more serviceable ones. To get the job done they had to deal with perhaps six situations that required significant expertise and ingenuity.

It occurred to me that while the door panels had been manufactured in a factory – they were the result of a well-defined process – their installation was clearly and unavoidably a practice.

Why this matters to you: Here in KJR reality we’ve frequently discussed the difference between processes and practices; processes being how work gets done in factories, with their repeatable, predictable steps; practices being how work gets done in hospitals and law offices, where no two cases are ever exactly alike and work must be adapted to each specific situation.

We consultants frequently advise clients to turn case-by-case kinds of work into metaphorical factories so they can perfect their techniques and get results that are more repeatable and predictable. I’ve been guilty of this myself, although I hope with enough qualifiers that I haven’t overpromised the ease and simplicity of the result.

The differences between process and practice aren’t “mere” semantics, not that there’s anything truly mere about semantics in the first place. It’s also fair to say that to the extent it’s possible to redefine how work gets done so it’s less of a craft or practice and more of a manufacturing-like process, defect rates and incremental costs will, in most cases, decrease.

It’s just easier said than done. To turn any craft or process into a factory-like process, a key aspect of the transformation is to view each step in the work as responsible for reducing the variability or, looking through the other end of the telescope, increasing the predictability of what those responsible for the next step in the work will face.

If you’re building a house that means getting started by (based on my extraordinarily limited understanding of the trade) clearing and grading the lot, laying the foundation, and fixing variations in ground compressibility to avoid surprises when pouring the slab and laying cinder block.

When building an application it means (among other things) clearly defining the architecture and coding standards, writing consistent user stories, and determining interdependencies to avoid surprises when, depending on the application architecture, coding each module, service, microservice, or what-have you.

Bob’s last word: When we envision a factory we envision a conveyor belt that carries identical items to each step in the work.

When we envision most of what IT does for a living … or when we envision building a house … we don’t envision anything remotely like that.

Bob’s sales pitch: Looking for help improving the practice of improving business practices and processes? Here’s where to contact me so we can start a conversation.