Reaching Peak Meeting Efficiency

Meetings are a critical tool for building a diverse, high-performance team with shared values

Steven Sinofsky
Learning By Shipping

--

There over 7 million Google and 13,000 Giphy search results for “hate meetings”. There are almost as many for “love meetings” but that is just irony.

Beyond that there are countless posts on time and money wasted in meetings — ”This Company Spent 300,000 Hours a Year in Pointless Meetings” was a headline recently. The Muse reported on study results that 35–50% of work time is in meetings and 67% of meetings are “failures”. We’ve all computed the financial cost to the company of a meeting we hated. Ugh.

I’ve endured a lot of bad meetings in my time. I’ve led bad meetings and attended bad meetings. I’ve tried to fix meetings. I’ve broken meetings. This post is about why meetings really are important to getting things done, even with incredibly divergent views on that fact, and why meetings so often go sideways or worse.

By and large meetings come and go and most of us just accept them as part of doing collaborative work in a company. Like AutoCorrect, once in a while a meeting backfires to such a degree that it just sets off a stream of emotions about how horrible meetings can be and what a huge waste of time all meetings have become. Some react by attempting to define when/how/if to have meetings as if there is a secret that has eluded most everyone for 100 years.

In the course of building a company the most important tool you have to create a culture of shared values is communication and meetings are critical to communication.

When you bring together a team of talented and diverse individuals, the only way they will come to operate as a team is by spending time talking, listening, and understanding the perspective individuals bring to contribute to a larger whole. Unless everyone hired shares the same background and experiences, there’s no way a group of people can converge to a high-performance team without meeting, sharing, and learning together. No amount of ping-pong, email, or shared docs can substitute for meeting.

This essay does not contain the magical PowerPoint template for how to run an effective meeting, nor does it espouse a system for deciding how, when, or why to meet. I’ve seen every type of agenda, preparation, tracking, issue-list, decision-making tool, template (whether using Word, Excel, Powerpoint, or Outlook). Call me skeptical. In my experience the best tool for meetings is scheduling time to have them in the first place and then to be present. The rest are just distractions to the real goals of sharing, building, deciding.

Meetings in this post refers to internal to a company or focused on the internal workings of a company, primarily the most common meetings of small groups. External meetings with (potential) customers, partners, investors, press, and so on are rather different. The last section of the post discusses 1:1s and broader team meetings as well.

Let’s Be Honest About Meetings…

Before I come to the defense of meetings, we should be honest with ourselves about meetings and some nearly universal truths.

  • No one likes meetings except the person who called the meeting. This is just a given, but it is important to remember that you too will someday call a meeting that no one will like.
  • No meeting ever made it through an agenda. If you’re meeting has n > 1 agenda items to work through you will not make it past the first couple. If your agenda for an entire meeting is just one item, then reconsider “world peace” as an agenda. The physics of meetings are such that the first agenda item you talk about (which half the time might not even be item 1) will expand to fill all available time.
  • Very few opinions/minds will change at a meeting in real-time. Expecting people to come around to your point of view in the meeting is almost never a winning approach. That said, it is reasonable to assume most everyone is rational and will come around to share a rational point of view if you spend time with them outside the meeting.
  • If you’re at a meeting and everyone is looking at their phones most of the time, then the next step is to reconsider the meeting and approach not to ban phones from meetings. Or maybe just don’t worry about it because meetings are just like real life where people look at their phones. As far as laptops, they are tools of work and people want to look things up or take notes, but just be sure to commit to participating (reminder, everyone can tell if you’re doing something other than taking notes).
  • If you’re at a meeting and the room isn’t big enough to fit everyone, then the next step is to reconsider the attendees and approach and not to get a bigger room.
  • If you’re at a meeting and the presenter is using slides with static representations of data, then it is a given that the discussion will require dynamic views, slices, and dices of the data. Don’t present pictures of data, rather be prepared and willing to share live data.
  • If you’re at a meeting and you present the group with two potential solutions to a problem, you will leave the meeting with a third potential solution to investigate and that idea will have the best attributes of each of the two proposed solution and magically none of the tradeoffs. I mean seriously, why didn’t you think of proposing the lower cost and faster time to market solution in the first place! Also, if you’re presenting to your boss no matter how many alternatives you present at least one new one will be synthesized at the meeting, but the boss is the one who can relieve the team of one or more constraints.
  • Important things never really happen at a meetings. If something does happen it is right at the end when everyone has to pee and half the people are out the door. The biggest mistake people make is thinking the meeting is the peak moment or end of a long process, when in reality meetings are steps along the way to collaborating and converging.
  • If you believe that you reached a decision on a really contentious topic in a meeting and jumped to “close” at the very end of the time, then one can probably say with certainty the decision will be revisited shortly. Chances are someone with key input wasn’t present or didn’t get a chance to contribute and will find a way to either re-open the decision or provide information to someone who will.
  • Nothing good ever came from voting at a meeting. Just don’t ever vote. Companies are not democracies, and you also do not want to memorialize winning and losing “sides” of an issue. If a person’s position isn’t clear, ask questions, but cornering them only raises the stakes and reduces accountability.
  • There is no process to be discovered that makes meetings “effective”. Having good meetings is about a culture and team that recognizes their value. Once you begin to overlay a formal meeting (or pre-/post-meeting) “process” there is probably little hope that meetings will become more effective, but a high likelihood that meetings will become a little bit more grating to most people.
  • If you hate meetings and choose to ban all meetings, you will almost certainly find the pendulum will swing back as meetings get added back one by one, and usually with a vengeance.
  • If you make it difficult for people to meet with you, they probably won’t meet with you. That can be good or bad, but probably some of both. Conversely, if you make it easy for people to meet with you, they probably will meet with you. That too can be good or bad, for each of you individually.
  • Meetings should not create more work. No one shows up to a meeting without a backlog or a bunch of available resources, so if you’re meetings are designed to find things for everyone to do they are likely to be miserable. If you think meetings are about piling up action items and follow-ups, then realize that you’re slowing down the organization to work at a meeting’s pace, not a work pace (as you discuss follow-up at the next meeting). This is the massive dysfunction IBM got into with the infamous “Management Committee”.
  • Engineers in particular hate meetings and stereotypically view them as a waste of time. If there’s one thing to consider it is that the worst thing for an engineer is reworking/rewriting something because of a miscue, failed explanation, “misunderstanding”, “new data”, or “change of mind”. Meetings are the best way to try prevent all of these things and participating is essential. So, engineers stop hating meetings on principle.
  • When you don’t know what to do, don’t call a meeting. Stereotypically (according to asking engineers) when product managers don’t know what to do they call meetings. The worst thing you can do is waste everyone’s time meandering towards a problem, not a solution. If you don’t know what to do, spend some time formulating a problem and proposals by walking and talking.
  • If you want to build a strong and collaborative culture then meetings are the most important “tool” you have so finding a way to make meetings worthwhile is arguably the most critical step you can take after hiring. Whether an email culture, a slack culture, or voice call culture, meetings are critical to bringing together and focusing the team.

But Meetings Are Important

I really like @pg’s 2009 post on Maker’s Schedule, Manager’s Schedule. It is absolutely correct and a great way to view time management in general. Read it and internalize it.

I believe, however, the post might be interpreted too literally and used in a way that could cause difficulty in a growing company rather than to clarify reality.

“Maker time”, aka engineer time, is the most valuable resource in any product effort and everything should always be done to treat engineer time as the precious resource it is and to make it as effective as it can be, especially in an early stage [tech] company when the company is effectively one collective coding brain. Amen.

That said, meetings are just as important for engineers as they are for “managers” or “marketing” or “sales” or “execs” or any other functional part (function means job function like eng, marketing, product, sales) of a company. Often engineers can miss the importance because striving for efficiency causes a certain blind spot relative to the larger opportunity of meeting.

The shortest way I can say this is that the most important thing in growing a company or team is to of course focus on getting things done, but the only way to get the right things done is by having meetings, by talking. There is no doubt that a group of people not meeting will get a lot of stuff done. It can be said with equal confidence, however, that by not meeting the stuff that will get done will lack cohesiveness, quality, and a shared set of values — the wrong stuff. The most expensive thing a growing company can do is get the wrong stuff done. This risk is magnified the larger the team, but clearly starts with just a couple of people.

The question is how to get the right stuff done. The answer is by talking, listening, and discussing. Those together are the ingredients for a shared understanding and with a shared understanding the micro-decisions that everyone makes every day whether writing code, creating positioning, deploying a build, designing an experience, and so on.

Talking, listening, discussing should not be thought of as “soft skills” or worse a “waste of time”. Call it talking or call it meeting, but no matter how good each member of the team is at the “hard skills” of their discipline, I am confident even the best are not psychic. That’s why teams need to have meetings.

Where meetings are generally misunderstood is that the effort to make them efficient, goal-oriented, and conclusive is exactly what shuts down discussion, causes people to think about what to say next rather than listen, and generally prevents collaboration.

We tend to think of meetings themselves as the main event, when in reality meetings should be the practice sessions. Instead of thinking about meetings as the regular season, think of meetings as practice drills or warm-ups. The real main event comes when you’re actually committing work to the screen. If you have done enough drills with your teammates then there’s a really good chance you know how they will react, how they can help, and how the work you’re committing will impact the overall “game”.

And since no one thinks they are above practice, we can agree no one is above meetings.

Since no one likes to redo work or revisit plans unnecessarily, we can agree that the best tool to avoid that is to use talking and listing—meetings—to get to and remain on the same page.

The reality of a company beyond the seed stage is that failing to communicate and collaborate result in massive inefficiencies and rework. And nothing upsets anyone more than having to redo work unnecessarily. In fact, people will spend countless hours debating whether to redo something rather than just a short time redoing just to make that point (reworking shipped code also introduces bugs, I get that). While it is common to view this as an engineering problem because code is expensive, to someone in marketing redoing messaging or redirecting a vendor for an event are each equally costly.

Bringing this back to manager schedule versus maker schedule, one important consideration is that everyone at every level in a company is a maker in something. Every single job function has work products that are created. Even CEOs and execs need to have specific work products that they create on their own and do not pass along or “vend out” to others. For a fun description of hiring out people to do your own work, see Michael Kinsley’s Ode to Managers which is the best post on what managers do I have read.

Meetings Come In Many Types

Some meeting or time management systems attempt to force a classification of meetings before having a meeting. You decide what a meeting is for and from that decision the length of meeting, the format, the preparation, attendees, and more just follow. Given that I think most meeting should be lightly unstructured, it is no surprise I put little faith in meeting “systems”.

There are, however, ways to classify meetings. The most useful reason to classify meetings is so that you have some idea as an attendee or as an organizer as to why everyone is sitting at a table burning hours. Once you recognize why a meeting is happening, it is much easier to participate as well as to reach a Zen state of meeting attendance.

Each of the following meetings types is offered along with an approach that focuses on sharing, calibrating, and informing rather than trying to reach approval or decide something.

  • Stand-up. The stand-up is either the most sacred or least liked meeting in organizations. While mostly used in engineering, it has come to be used across disciplines or for a whole company. My view is that the stand-up is entirely a culture and operational workflow tool and not precisely a “meeting” (or substitute) and in many organizations the kanban board, github, trello or other tools can serve this purpose. A whole-company standup is less a meeting and more announcements (sometimes with q&a). That said, if attendance or participation in the stand-up is waning then it is worth considering if the team has reached an operational level where the stand-up is too granular for the scale and you want to aggregate it and/or add an additional level of scale. The strict time limits (by design) on the stand-up format limits the opportunity to grow cultural alignment or shared context, which I believe are the key benefits of meetings. The core challenge with stand-ups are that those predisposed to not wanting to meet count the stand-up as a required meeting and thus limit the overall budget for meetings that can help a company scale and build more complex and inter-dependent products.
  • Status and Business Updates. The bread and butter of meetings when one or more members of the team update everyone else. Instead of repeating what most people already know or can learn from Slack, use the time to share exceptions. These are the most difficult meetings to keep interesting for every attendee and require careful planning and effort to make them useful.
  • Team Organization (manager 1:1, skip level, team, e-staff). In my view these are absolutely the most important meetings and represent those meetings up/down the org chart and across the team between functional peers. I believe these connections are the heart and soul of how a company functions and what it can accomplish. Yet, amazingly, these are the meetings most likely to get rescheduled, skipped, or not even booked in the first place. The key ingredients to these meetings: no agenda, no pressure, no specific goal, but rather a focus on open lines of communication, sharing, and listening. That’s why I love them.
  • Workgroup or the “without” meeting. The workgroup is the set of people that are day to day working on a project, but without their common manager, which is why I call it the “without” meeting. Most always this meeting is like a staff meeting for a manager, but without the manager. I had never heard of this until one day I walked by a conference room and I thought it was a staff meeting I was missing and stuck my confused head in. I was told to go away because this is the “without Steven” meeting. I totally felt left out, but was educated and came to realize the incredible value such a meeting has in terms of building a collaborative culture among people working on a single project. I can almost bet your company does not do a “without CEO” meeting but would strongly encourage it, as well as (if you are at the right scale) encourage a “without” meeting for the product, engineering, marketing, and other functional organizations. This is the most important suggestion in this post 🤓
  • Proposal Introduction. In this type of meeting there’s usually a presentation from one or more people that starts off with “Problem Statement” then presents “Goals” (and hopefully no slides on “Non-Goals” 🤯) and offers a one or more proposed solutions. If you’re dealing with a big new project or problem, the first meeting about the topic should be entirely about learning as much as you can from everyone else about their stake in the outcome. As frustrating as it sounds, listening early gives you the most information possible to develop a solution taking into account what is on everyone’s mind.
  • Approving Decisions. Through some series of steps a choice about what to do has been “made” and this meeting is (theoretically) supposed to close with a validation of that choice. If you’ve done the work to understand the views of stakeholders and the broad range of views on the team, then your organization should not need an approval meeting. If you haven’t done the work but think having a meeting to reach agreement will work, chances are you’ll find yourself back at the proposal stage.
  • Learning and Exploring. This meeting involves some set of people sharing what they have learned about a topic (competitors, diagnosing a product or org failure, milestone postmortem, etc.) and sharing. These can be the most valuable times for teams to learn and grow together. If you’re reporting on customers or an event/conference, make the report-out “come to life” with images, artifacts, anecdotes that go beyond bullets and facts. If you’re talking about a competitor, then spend the time on a demonstration of the product rather than talking. In all cases, present learning beyond the facts and share the impact or how the facts fit in a broader context.
  • Process and Procedures. Something new needs to get done and the first step is to outline how this will happen. This meeting goes through the process and procedures for getting the work done. These meetings are always incredibly difficult because some set of people are going to be determined to prove that the new process doesn’t work or is worse than the old one. The reason these meetings most often fail is twofold. First, there’s a really good chance that the person in the back of the room bringing the buzzsaw to the new process is actually right—that just means the meeting was premature and the legwork wasn’t done. Second, there’s also a good chance that any new process is supposed to improve some things and just “change” some others but change is different not necessarily worse—making sure people know this is part of the legwork before you get to the meeting.
  • Escalation. Two parts of a company, whether in the same functional area or not, cannot agree on some topic and choose to meet with the manager with oversight over both teams. Why do they disagree? Almost always this is about a tradeoff that impacts functional areas unevenly or puts some work in conflict with OKRs, resources, or role definitions. This type of escalation can make the manager feel great about deciding (and perhaps too often shine in the glow of being the boss) while at the same time creates opportunity for much more dysfunction. It is almost never the case that escalation works—the choice was framed incorrectly or defensively, the goals were unclear, or the change in plans just made listening difficult. It is far more likely that escalation creates a culture of winners and losers, and also a culture of disempowered managers. Strong leaders should push back on teams calling meetings for this purpose and get the resolution to happen between peers. Managers should always look inward when faced with escalation and decide if the overall framework or plan were adequate tools to resolve the dilemma.
  • An “ask”. Some people believe that the best way to get something done is to send email and ask. The problem is that if you know the person doesn’t want to do that and the person knows you know that, the mail goes unanswered. So the next step is to have a meeting with the hopes of asking in-person and getting a different answer via a squeeze play. Meetings that are expressly about asking to do something almost never work. The seeds for an “ask” need to be planted much earlier and flow from much more shared context. This is a key reason why asks (and escalations) almost always fail as meeting topics.
  • Introduction, get to know. “Do you have 30 minutes so I can pick your brain?”…“Are you free for coffee?” These are likely the most spoken words in Silicon Valley and probably the most blogged about. Employees new to a company dread sending out invite after invite just to learn and map out their new organization. Managers rarely do enough to get to know new people, especially when they are a step removed organizationally. SV is great at playing the long game and that is what these are about. PS: Please don’t say “pick your brain”…it’s just 🤮.
  • Training and Development. There are specific skills that need to be taught in an interactive manner. Every company has meetings like this whether it is to roll out the new benefits package or to take on important company culture issues like diversity and inclusion. In a big company these meetings become “classes” such as manager training. There are always those that dislike these intensely, but they are important opportunities because generally you are put in situations with people you do not normally meet with. The only reason I ever enjoyed training meetings in my career was because I would end up in a group exercise with a sales person from the other side of the world who disliked the class as much as I did.
  • Kickoffs and offsites. These meetings are often hours to full day “events” focused on the start of a process — quarterly sales kickoff, new product cycle, launch readiness, etc. People view these meetings unevenly, participating in fits and starts or viewing the content as a distribution of quality. The best of these meetings focus on participation by structure/format rather than hours of slides and single speakers. Liven them up. For recurring events like this, gather feedback after (via anonymous survey and also 1:1s) and iterate. Let people know you will improve.
  • Crisis. When there is a crisis there will be meetings, and these are incredibly important. The good news is everyone wants to go to these meetings, but the bad news is that this is a meeting where you have to make sure of two things. First, they need to have exactly the right people in the meeting, but not more. Second, communication from this meeting needs to be perfect because during a time of crisis everyone is on pins and needles waiting. A crisis period for a company is when many “normal” rules are thrown out and companies assume a much more command-and-control operating model (See @bhorowtiz’s wartime versus peacetime). The biggest mistake companies make with respect to crisis meetings is declaring too many things a crisis in order to use or justify a command-and-control approach.

Patterns of Meeting Dysfunction

Meetings suck for a lot of reasons, but the least of which is because they take time. Meetings primarily suck because of a fairly common set of human behaviors that are especially dysfunctional in a meeting context.

Below are some of the most common dysfunctions. These are listed because the best suggestion for good meetings is to counter dysfunction while it is happening and see if collaboration can be put back on track in real-time. The general rule of providing feedback that is actionable at the time it is happening applies to meetings too.

It is worth noting that some of these dysfunctions can become “weaponized” in large organizations where these anti-collaboration skills are used to prevent moving in a direction one does not agree with. Leaders need to recognize and act when someone is derailing a meeting, though in a strong culture peers should be able to call out such behavior as well.

This is a long list, and at the same time it is hardly complete! I might add more based on discussions and learning.

  • Failing to hear from all present. The most obvious problem with most meetings is also the easiest to fix. Whether it is a regular staff meeting or a big company-wide Q&A or a decision-making meeting, it always seems like the same people talk and the same people never seem to talk. Maybe they are quiet. Maybe they don’t think they have anything to add. Maybe they better listeners than talkers. Maybe they are interrupted all the time. Maybe they are remote and on a call. No matter what, they are at the company to contribute not just sit at meetings silently. Best practice: Everyone can tell who is talking or not. So everyone has a chance to use their floor time to seek contributions from those that have just been listening. The best way to do this is ask a specific question and seek their expertise, rather than just “do you have anything to add”. In particular, the leader of a meeting should make sure perspectives from functional areas are surfaced. If some are interrupting with some frequency, the room owes them that feedback. Honestly, it is also okay to let someone know, politely, he has done his fair share of contributing.
  • Mostly talking, little listening. Just as common as not hearing from some people is a meeting where there is just too little listening all around. What happens when you put a bunch of high-energy, high-velocity, fast-thinkers in a meeting can too often be a lot of talking without enough listening. Even when participants aren’t talking they are preparing what they will say next even if it is not a response and more about adding to what they previously said. This “Type A” meeting is all too common in our environment and one that leaves many frustrated. Best practice: Make a rule that if you take the floor, what you say must build on what the previous person said. Make a rule that before stating opposition to a point, the speaker needs to restate/express their interpretation of that point. Make a rule that if someone wants to take the discussion to a whole other direction the room must grant permission to do so. These are all “meeting participation skills” that can be taught. I’ve actually found this resource Teaching the Case Method very helpful in thinking about how to facilitate meetings, offsites, and group discussions.
  • Reading data off slides (especially out of date data). By far the most frustrating type of meeting is when the leader is just reading data off slides. Everyone reads at different speeds and some in the room already know the data (perhaps even better). Questions about the data can’t be answered by static slides and then after a few minutes everyone is frustrated because you can’t really take any actions because you lack a shared understanding of data. Best practice: Summarize what the data said in words and percentages, but be prepared to back that up with live views of the data.
  • Fake data. How often are you in a meeting and someone produces a “data point” or a “customer”—anecdata—that attempts to refute the point someone else is making. The whole room is then left wondering where the reality is? In short order the meeting becomes a discussion comparing anecdotes or intuition. I once went to a budget meeting where the boss didn’t know how much was spent on some marketing item and then made up a number and used that to decide to cut a big program after we spent 20 minutes debating that made up number. Everyone left wondering why we didn’t just cut the program. Best practice: Don’t try to counter someone’s point of view with “customers are saying” or make up a number unless you can back it up.
  • Whiteboards. I believe whiteboards are an evil presence in meetings. Whiteboards are a tool used by a certain type of person to “take over” a meeting. Simply going to the board and picking up a pen changes the whole dynamic of meeting ownership, agenda, control and creates a power-dynamic that is pretty hostile to collaboration. The worst part of whiteboards is that some people just don’t have the ego or personality to go to a whiteboard so they will never contribute that way. The real problem is that whatever gets written on a whiteboard can have more weight than what is said by others or than it deserves simply because it was “written”. I’ve seen whole product positioning statements upended because someone stood up at a whiteboard and rearranged the 3x3 and bullied everyone by controlling the board. Best practice: Don’t let someone run to the whiteboard unless they are truly drawing a picture that everyone needs to see, as long as they sit down quickly. If you want to track action items or notes on a board then someone should volunteer to do that without ceding their right to participate. In a brainstorming offsite, easels and whiteboards are great if the person writing is participating and everyone is able to add to the notes.
  • Meeting notes. Early in my career I was taught to “own the notes” as a way of managing a meeting—be the person that takes notes and distributes them after the meeting. It only took one time to be on the receiving end of a notetaker with an agenda who had a habit of removing context, recording selectively, and worse editorializing in the notes. Best practice: If you want to have “team notes” then it is important to be clear about the point of view and use of those (especially if distributed outside the meeting). At the same time, everyone should feel good about sharing their notes because people to take away different things.
  • Surprises. No one likes surprises (well unless they are good, but no one really has happy surprises in a meeting). Meetings (not 1:1s) are not a time to spring news on the rest of the team, especially if specific people are falling short of goals. If the bug count is high or there’s a production problem, make sure the right people know in advance that things will be discussed so they are prepared for a discussion. Best practice: Don’t break important news to key stakeholders in a group setting, even the most sensitive changes in a company (15 minutes of notice is still better than a surprise.
  • Hijacking agenda. While it is true that most meetings struggle to stick to an agenda or at least completing an agenda, you don’t want to be the cause of these challenges. While whatever you might want to talk about is no doubt important, you don’t know if everyone will share that priority. Best practice: Submit agenda items the day before a meeting but if something comes up in real-time then at least wait until the first priorities are covered.
  • Around the table, but too slowly. A common practice, and one I would say is a good one, is to use meeting time for each attendee to offer an update. These are truly critical to team building and collaboration. Teams need to develop a rhythm as to how this works—with what level of detail and granularity should someone speak. Some people like to tell stories (me) whereas other people like to rattle off data. With just 10 people in the room, the bulk of an hour can be taken up inadvertently by this process. Best practice: Around the table is a best practice, but it takes time for a team to establish the best way to do this—spend the effort.
  • Unclear if “what happens in a meeting, stays in a meeting”. Even in the most open of companies, many meetings are designed to be co-workers at some “level” discussing sensitive topics, particularly around people and performance, organization, or communicating any significant change. Things can go haywire if the wrong information is communicated or at the wrong time, especially from a “senior staff” type of meeting. Just a reminder, but if the e-staff breaks a normal pattern by meeting off site or pulling the shades, everyone will know something is going on out of hte ordinary. Best practice: Don’t forget to be clear on the rules of a meeting, and reinforce them at sensitive times.
  • Meeting “squirrel”. Sometimes the discussion is going well and good discussions are happening, and then out of “nowhere” a whole new topic is introduced or some other significant “redirection”. This lack of meeting attention span is quite common, particularly with executives. Best practice: Don’t just say “we need to get back on track” since that cuts people off, rather first consider if the newly introduced topic is more critical at that time to discuss and deliberately change gears as a team.
  • Boss holding court. This is a boss/manager dysfunction. Do you ever get the feeling that the manager leading a meeting is running it like everyone in the room is on hold waiting to be called on or summoned to provide information valuable to the boss? No one is really sure the topic or agenda, or perhaps even the goal of the information. Sometimes this dysfunction is just a feeling that the boss needs an audience and is just using the meeting to have one while thinking out loud. Best practice: Bosses and managers, please don’t hold court. You will have to recognize you are doing so because unfortunately your team probably won’t be able to tell you (this type of leader doesn’t often get corrective feedback in a timely or direct manner). The biggest sign/symptom of this type of dysfunction is that you view the purpose of the meeting to inform you or to create your work-product. There are other, more directed, ways than using a whole group process.
  • Hidden Agenda. Sometimes in collaborative meetings where the goal is to reach consensus on a topic (add/cut a feature, planning date) variables are introduced that seem to have a second-order impact on the decision being made. Is there a genuine interest/critical nature to that variable or was it introduced specifically to indirectly drive an outcome? Best practice: Consider if new data or additional consideration is in fact new before feeling something is political and seek that opinion from the team along the lines of “do we really need to make this a factor in our choice at this time?”
  • Lack of preparation. When you’re the clear owner of a meeting and will be driving the conversation there are two important steps to follow. First, have all the supporting materials lined up and ready to go on time (including projecting, live data, etc.). Second, do the pre-meeting background conversations to avoid other potential pitfalls such as surprises or distractions. Best practice: Be prepared. ⚜️
  • Some but not all functional areas represented. In any meeting aiming to be a step towards consensus about major company events (kick off, release, launch, first public outing, etc.) it is critically important that all functional areas have representation. The number one reason for the outcome of a meeting failing to “stick” is the lack of perspective or, more usually, just support from all the parts of a team. Best practice: Routinely include all critical job functions in project-wide meetings to avoid this happening. It takes a village.
  • Mismatch in seniority or criticality. One of the more sensitive areas of meeting dynamics is attendance of the “right” people. Most of the time mistakes along these lines happen by over-achieving and making a meeting too big. Balancing an org chart view with a responsibility view along with a projects view is always challenging. Awkward situations arise for example, when discussing talent or management challenges or making inter-project resource trade-offs if the table has a mismatch in management responsibility or “importance” of various projects. Best practice: Keep an eye out to make sure meetings do not put people in awkward situations because of seniority or mission-critical nature of projects.
  • Factions. Sometimes meetings are called in order to bring together opposing sides of some issue, and it is necessary. It takes a very special meeting approach to work through any topic that is divisive to the point of having factions. Generally meetings called to resolve factions are called too soon before everyone is equally informed, or they are called too late when positions have been solidified. Best practice: Work to pre-empt polarizing situations by making sure information/data/experience gets shared sooner rather than later. If you reach the state of polarization recognize you will need to spend significant time to reach a consensus.
  • Voting on important topics. Invariably, in an effort to put an end to meeting(s) or discussion, someone calls for a vote on an important topic. My experience has been that voting (other than unanimous) almost always ends badly—people never forget being on the wrong side of a vote. More importantly, voting has a way of removing all accountability for any group decision. Best practice: If you really have to decide something, then hear out a broad range of opinions and then break so the decider can both gather more input and also talk to people 1:1. Then reconvene (not 10 minutes later, but a day or two) and talk through the decision and rationale so everyone is versed in the why, and also accountable. Intel first called this “disagree and commit” which is also popular in Amazon literature.
  • Escalate, bypass, or undo decision. As CEO or multi-level manager, it is not uncommon to be asked to have a meeting that seems a bit out of place but you accept. You find out that the meeting is essentially an “ask” to override something that the team is doing. Best practice: The first thing is to make sure to listen, but clearly not decide. Second, meet and listen to the people who are indirectly being asked to change. Third, offer them the “new data” (new to you) and see if they considered it. Then conclude with the people responsible going back to the point of escalation, without your involvement. Whatever you do, don’t override the management chain/process or you just disempower the team and reward bypassing any existing org or process.
  • Isolating the choice — the false choice. One of the main culprits for frustrating meetings is that the team is meeting to debate and decide over some specific topic, but in practice the leader of the meeting has distilled the choice down to something that is free of context or tradeoffs. “We’re having a meeting to decide pricing the new product” but the features of the new product have not been decided. “We’re going to decide the mechanism for moving code to production” but there is not yet agreement on the frequency of doing so or the enterprise management strategy. Almost always these meetings are viewed as “missing the big picture” by others. In essence the meeting is happening to decide something that can’t actually be decided. Best practice: It is easy to grind meetings to a halt by reminding people that the decision is free to required context or is happening too soon. A better approach is to catch this before the meeting happens. The organizer has the responsibility to do legwork to understand this and attendees should talk (in person) to the organizer once the meeting request/invite shows up.
  • Meeting thinking it’s a performance review. Sometimes those participating in a meeting are uneasy about stating crazy ideas or concerns, or even just afraid to “look dumb” because there’s a feeling that participating in a meeting is the equivalent of a performance review. This is not just their responsibility, but the CEO/leader/manager creates a high-stakes environment that might contribute to those feelings. Best practice: Managers leading meetings need to make sure everyone is aware that collaboration also means contributing ideas that won’t fly, making logic mistakes, or otherwise saying dumb things. Two good sayings are “if you don’t say something dumb, you won’t get invited back” and “some of the smartest people we know say some of the dumbest things” (both credit billg). Over time, it creates moments where after a comment when the person realizes what they said someone will remind them they are invited back 🤣.
  • Giving cultural feedback in front of a group. With enough meetings and time, eventually someone at a meeting will handle something inappropriately. They might bully someone, say something inappropriate, make what they believe to be a joke, interrupt repeatedly, repeatedly pushing an unpopular position (I’ve seen it all), or something all too (terribly) routine like men interrupting women. At those moments it is almost always clear to others in the room. Management coaching says to give feedback at that moment for it to be effective. There’s a right way and wrong way to do that. Best practice: If you (as manager, peer, concerned or victim) want to give feedback ask for a break and to speak to the instigator outside the room. Then have a civil conversation explaining how the action is not consistent with getting the best work out of you/team or compatible with the values of the company/society. When reconvening the instigator needs to fully take accountability in the room for their behavior. If this isn’t working or possible, then you will need to bring in the right manager to make that happen.
  • Managing one person in front of a group. One of the most difficult times in a meeting is when the manager-managed relationship is put on display at the meeting, and it is especially difficult when that is done in the context of either less-than-positive feedback or asking for something to be done that someone clearly doesn’t agree with. Since everyone has a manager (this holds for board meetings too), this is a common issue which can be summed up as “no one likes being managed in front of a group”. In particular, no one wants to look like they “lost” or that they are doing the wrong thing. Best practice: Eventually everyone has to do something they might not really agree with or buy in to. Oh well. But given that, just don’t manage the situation, the ask, the redirection, etc. in front of a group of that person’s peers.
  • Presumptive close. You’re in a meeting and having a good discussion on a complex topic impacting many at the company. Then sort of suddenly the person responsible for the area being talked about seems to take control and say “sounds like we’ve got an answer” and thinks it is time to move on. This might be well-intentioned and aimed at saving circular or repetitive discussion. It also might be an attempt to cut off discussion right when it was going to get interesting. Best practice: Always ask, genuinely, if everyone has been heard then ask permission to begin to close down a discussion.
  • Ending by agreeing to disagree. One of the biggest myths in management of high-performance teams is you can just end discussion by “agreeing to disagree”. That really isn’t a thing. You don’t discuss something for hours and then just say “ok you’re right”. Nevertheless, eventually you have to finalize pricing, positioning, release date, or push something to production and you might have a different view. Moving forward is not just up to everyone who “won” but also to those that “lost” in the meeting. Best practice: If things don’t go your way then you have to take the initiative and close the discussion down by showing your support, understanding how to articulate the choice the team made, and being the best advocate for that choice. You can’t leave the meeting telling people you lost or they are wrong, or you “disagree, but”. Yes it seems wrong that you have to exit with your chin up. Conversely, no gloating from the “winners”.

Peak Meeting Function

The thing is that most people say they don’t want to have meetings. Most say “oh that meeting could have been handled with an email or slack message”. They might be right. But that is only if you take the meeting literally. Meetings mean so much more to a company than conveying information or deciding.

Meetings are literally how cultures are formed, values expressed, and companies made.

Different people have different ways of learning, creating, and ultimately deciding. For a team to function such that the output is greater than the individual efforts summed, people need to align, communicate, and collaborate. People need to be on the same page and share the same values. For most everyone that means they need to have forums to talk, and if they don’t want to talk at the very least they need forums to hear others.

The most important things I know that make meetings effective is a very short list. The reason this list is not about how to have a meeting, how to decide things, or how to be accountable is because meetings do not happen in a vacuum or some academic bubble. Meetings happen to get work done. Meetings are about collaborating. Collaborating is about communicating.

To communicate you need a baseline upon which that communication takes place. The very best foundation I’ve found is to have a plan. A plan is four things:

  • Shared goals
  • Agreed schedule
  • Consistent participation
  • Predictable processes

Together these represent a plan. That’s it. Everything else are details that can be left to the people actually doing the work. The reason meetings can be effective when you have these is because of two factors.

First, everything you are meeting about is relative to these factors and you’re not revisiting them every time you talk. Everyone knows concretely why you are there. A plan is the actionable level of detail that explains what everyone is doing over the next month, quarter, years.

Second, when something new comes along or a problem arises it will be relative to this foundation and so any changes are not one-off decisions but changes to a plan that can’t be viewed in isolation. A change in goals, schedule, processes or values can only be made as a trade-off against what exists not as something to do in addition or in contradiction to the plan, but as a deliberate trade-off against a plan. Making decisions outside the context of a plan is a waste of time…it is just talking.

Establishing the above three are combinations of, yes, meetings and decisions by fiat. Let’s go through them.

  • Shared work/output goals. Every work product in a company should have goals and those goals should be concrete, actionable by those doing the work, and communicated. These are the goals of the work or the output of the team, not the goals of the company overall. The engineering team has feature and quality goals. The marketing team has positioning, pricing, content goals. Sales has quotas. These goals define really what people are marching towards every day. When everyone has goals and they are shared there’s never any confusion about why or what people are doing. Goals are the “what” of meetings.
  • Agreed project schedule. All work has a schedule. In practice, after you know what you want to do the single biggest force multiplier in getting things done and collaborating is a shared schedule. The reason having shared schedule is so important is because the schedule is the ultimate project constraint after resources (or budget). Once a group collaborating shared a schedule then all meetings have the same sense of urgency and same ability to prioritize what to do and when. The schedule is the “when” context of meetings.
  • Consistent meeting participation. The first step in having any meeting is deciding who participates. For the vast majority of meetings this will be either manager meeting with reports or peers across disciplines. This important step is deciding and sticking to the algorithm for meeting attendance. Having this in place means no one is ever confused about where to be and when and people don’t feel left out. This is the “who” of meetings.
  • Predictable processes and values. No matter what functional area of a company is represented, the role of process and values play a critical role in the meeting process. Predictable terminology, tools, and steps in getting things done make for a common language, which streamlines meetings. Processes and values are the “how” of meetings.

I would add that there are two very concrete tactics about meetings that I have found to be the most important.

  • Start and end on time. It doesn’t matter what time management system you use or how long you think a meeting should be (25, 50, 60, 120 minutes) just start and end on time. Anything longer than hour, let people take breaks. Don’t sit in the dark for long. Be civil.
  • Schedule carefully. You know what takes more time than going to meetings? Scheduling meetings. Schedule meetings and stick to the scheduled time or cancel the meeting, that’s it. It is that simple. In particular if you called the meeting, especially if you’re the boss, just resist all attempts to move things around. There’s a point in company scale (or org scale) when people turn over managing their own schedule to Administrative Assistants. It is at that point that the managers (not the AA doing their job) think it is fine to move things around and do so without really factoring in the ripple effect, especially for those without support. Rhythm is a huge contributor to organizational efficacy, don’t destroy it by thinking it is ok to just move things around a bit.

Personal Note

The best meetings I remember are the ones where our team got a little closer and more connected and I remember that “feeling” more than I remember the specifics of what we talked about.

A team making, marketing, or selling a product is as much a team as any sports, military, or performing troupe. These types of teams “meet” to practice and rehearse. In business too often we think meetings need to be new or decide, but in reality spending time together just makes a better team.

The more you know about what and how people think, the more the micro choices you make day in and day out (without meetings) will likely be done in unison. High performance teams don’t really need to meet, but every high-performance team I know seems to have a brain-wave connection across the team. That connection comes from talking, listening, talking, and listening. That can only happen in meetings.

As a young programmer I too read The Fountainhead and know that the best work is done by people with principles. Freedom and creativity come from within, your own standards, depending on nothing and no one. “I do not recognize anyone’s right to one minute of my life. Nor to any part of my energy.” And so on…it seems when it comes to meetings people just want to be left alone.

What I would say to Roark is that software and products at scale are not really done by one person, even if one person has a vision. To execute that vision requires a team. Teams require collaboration and execution. And the only way to do that is in meetings.

I skipped a lot of meetings and at the same time was given a lot of grief for spending too much time meeting with the team. Everyone has their own style and every company its own culture, but to I wanted to share what I found most valuable in executing at scale:

  • 1:1s. I was “religious” about weekly, one-hour meetings with direct reports and counter-parts in marketing. In startups this is viewed as a lot traditionally. I would push back on that and say it is not and most would be more coordinated spending the time. The difficulty is that you can’t do that until there is an e-staff or management structure that scales.
  • Skip Level (blog post). Once you have an e-staff and leaders (Eng, Marketing, Sales, Product) having one skip level 1:1s with frequency is super important. It is even more important for companies as they scale so the CEO and the new e-staff leaders are properly connected to the work.
  • “Without”. Described earlier is the “without” meeting, which I think on any project the most important execution-oriented meeting. It removes the pressure of working things out in front of the boss. I love this meeting and strongly encourage it.
  • All/Team. Startups are generally fantastic about all-company meetings. This is critical to connecting the “goals” to the broader company and for everyone to be able to connect their work products to the broader execution context in the company.
  • Ad hoc chats. For most all of my time as a manager going back to 1990 I made sure that I never scheduled more than about 40% of my time in meetings (less earlier). Once I stopped writing code or specs, I made sure that 60% of my time was literally ad hoc and having conversations with as many people as possible when I wasn’t just doing my own individual work. I can’t over-state the importance of MBWA managing by walking around” made popular by the likes of Hewlett, Packard, and Grove.

The contents or agenda for each of these was far less important than allocating the time to talk, to listen, to discuss. I always knew the best decisions were made simply because we had spent time together to get on the same page in broader goals, team values, and shared understanding of how work should be done.

Author’s note. This is a very long post. Why? I wrote this to be a one-stop-shop for meetings figuring the internet is filled with snappy short posts on meeting effectiveness. I thought having an archive of a few decades of meeting experience, dysfunction, and best practices would be a unique contribution. Please you are encouraged to take this in over time and to copy/paste some tips. 🙏

--

--