Getting out of Meeting Hell: As a mid-level manager

Please have a look at the introduction for background, for applicable disclaimers, and for information about the specific environments this series talks about.

This part of this series is for you if you are a manager at any level of your organization except the very top. In other words, you have reports, but you also report to someone. And as such you may be stuck in meeting hell in two ways:

1. With your own team, that is to say, yourself and the people reporting to you.
2. With your management peers, in other words, the people that manage other teams and report to the same director, VP, or whatever other fancy titles your company might use.

And I’ll cover both of those angles, but before I do, I should note that you, of course, have one option to improve your personal situation that is also available to your reports: Leave. It’s not the only option you have, and it may not be your first option, but an option it is. And, for your personal development, taking on a management role in a company that does distributed work and asynchronous communications right might be an excellent career move.

If you are a conscientious manager and you feel a sense of responsibility and obligation to your team, and this makes you hesitate to consider the option to leave, then that reflects nobly on your character but know this: that responsibility is contingent on everyone’s employment in one organization, and it ends the day your employment contract (or theirs) terminates. That may sound harsh, but that’s the breaks of the game, and you shouldn’t let that hold you up, if leaving is the objectively most sensible option for you. There’s no use burning out over an exaggerated sense of duty.

In addition, I’d posit that you should leave your company if it employs or promotes employee surveillance, keeps voodoo “meeting engagement metrics”, or engages in otherwise harmful or toxic behavior. I’d argue that in those cases you should also make sure your direct reports know why you’re leaving, to the extent that your contractual obligations allow you to tell them.¹

However, if you’ve chosen not to leave your current organization, and you want to actually do the hard work for making work better for yourself and your distributed team, here is your paramount obligation:

Learn.

If there’s anything that the coronavirus pandemic has shown about organizations making the (admittedly abrupt) transition from localized to distributed work, it’s this: it’s a challenge for managers much more than for non-manager employees. You have to make a conscious effort to learn how distributed work works, and how you manage a distributed team.

But, chances are that you won’t be limited to watching talks or listening to podcasts or reading articles (you might have read this one before you landed here). Instead, it’s not unlikely that if you’re doing software or technology development, some of the people on your team are already well versed in distributed collaboration and asynchronous communications. Yes, I am of course talking about open source contributors. It absolutely does not matter what kind of open source software some on your team have worked or helped out on, or whether it’s in any way related to the products your company builds. Everyone who’s ever landed a pull request probably has had to learn more about distributed, async communications than any office dweller did who never has. Find those people. Talk to them. Learn from them.

You’ll also have peers in the industry, outside your company. Managers who’ve already done the work. They can’t do the learning for you, but they can you show a few tricks of the trade.

And I’ll give you one, straight away: in a company stuck in Meeting Hell, you change things for your team first, and don’t even think about people at or above your level. I would not advise taking your ideas up the chain without the confidence of knowing that what you are suggesting works in your team. Mid-level management is unfortunately often full of “great idea, but it’ll never work here” or “that might sound nice, but I’m afraid it doesn’t fit our culture.” You want to run silent, run deep (if you permit me a strained metaphor). When your team lands its first great big success, that’s when you casually want to drop something like “we did this on one meeting a week.”

So, how can you get there? Here are a few ideas.

• Eliminate daily standups.

• Limit yourself to one scheduled team meeting a week. Keep it to approximately one hour, give or take a few minutes. Schedule it near the start of the work week (meaning, in most countries, on Monday).

• Have an agenda for your team meeting (and all other meetings) that is available in a collaboratively editable document, cross-referencing all open tasks. Have this agenda in a place where everyone can find it, and have it ready no later than 15 minutes prior to the meeting.

• During the meeting, transform the agenda into your meeting notes. This is something a collaboratively editable document (like a wiki page or Google Doc) makes easy. Appoint a responsible note-taker or scribe, whose job it is to compile the meeting notes, edit minor glitches and errors, and then let you know the notes are ready for consumption. You may decide that everyone who is in the meeting can co-edit the notes, and this can be very beneficial to make sure that even the quiet voices are heard. But it’s the scribe’s responsibility to bring them into good shape, and it’s your responsibility as the team lead to make sure they’re truthful and accurate.

• Spend the first 15-20 minutes of the weekly meeting on non-work topics. Ask something like “how was your weekend” or “how are things going in your part of the world” or anything else that you can think of that helps you feel the mood of your team. These things don’t go on the meeting record. Always accept when people don’t want to give an answer. They may have many reasons, none of which are necessarily your business. Trust that they’ll share whatever they’re comfortable sharing, even if some weeks that’s nothing.

• Learn to keep each other appraised of your relative progress and status via a simple, central coordination facility, such as a virtual Kanban board.

• Learn to write to be understood, and encourage your team to do the same.

• Do not attempt to get back to people “immediately”, and do not expect people to get back to you promptly. A reasonable default expectation for reply times is 24 hours. If you need an answer faster, you can always send an email (or better still, a comment on a card or ticket) with a request like “if I could get this by 1600 UTC today, that’d be excellent.” Bonus points if you add why you need that information quickly, as in “… so I can put this together with Kim’s performance data and make a decision on which load balancing strategy we’ll use, which Alex needs to know by tomorrow.”

• Establish a convention for marking things as urgent, when needed. The word URGENT, included in capital letters in an email subject or a chat message, usually works well. Only use this if things are on fire.² Never use the urgency marker just by itself. (That’s a naked ping on steroids.) Also, when someone legitimately uses the marker in communication with you, honour it. When someone uses it for something other than a legitimate reason, take them to task.

• Get used to referring back to written communication, such as ticket comments or the record of a meeting, weeks or months later. This is not “pulling out the receipts” or “quoting chapter and verse” at someone. It simply serves to establish that yes, we have a written record of just about everything, and there is no need to keep these things stored in our heads under a banner saying “must not forget” (the latter being a major contributor to personal stress).

• Don’t attempt to hide your own mistakes and misjudgements. They’re on the record. That makes them a learning opportunity.

• Gradually establish firm communication rules with your team. Many of these won’t need to be autocratically decreed, because they just make sense and people tend to intuitively agree on them (like the just-mentioned URGENT marker and the circumstances under which to use them). Then, make sure you stick to them. Stick to them yourself, and correct others who break them.³

Importantly, let your team know that you’re working on getting them all out of meeting hell. Don’t sugarcoat things if you’re struggling while swimming against the company tide, at least temporarily. If they know you’re actively striving to make their work situation better, more productive and healthier it may well make the difference between them leaving and staying on board.

Finally, keep an eye on corporate policy and the messages you get from company leadership. If they’re obviously stuck in 1995, you might as well go and update your CV. If the people at the top do make an effort to implement distributed and async friendly policies, however, then things may not change overnight, but there’s hope that change they will, and your effort will not be for naught.