“Meetings are useless”

Do you also hear that all the time? But stepping back, that’s like saying “screwdrivers are bad”. Meetings are a tool, and they are indispensable for effective, transparent communication.

Transparency is critical if you want to build trust in your organization. I have been in situations where “coffee walks” were the norm. As a result, information was delivered to each individual slightly differently. This information asymmetry generates distrust in the organization and its leadership. As the saying goes “Trust takes years to build, seconds to break, and forever to repair”. Transparent communication is a cornerstone of building trust. Distributing information in meetings that involve all relevant stakeholders is essential if you want to build trust. A friend who works at a successful analytics company even told me that “we don’t do meetings, everything is communicated in one-on-ones”. This is a sure way to inject unnecessary politics into an organization. Meetings are a tool to direct verbal and non-verbal information flow between stakeholders.

The problem with meetings is that they are often misused and can ruin productivity, in particular amongst software engineers where long, uninterrupted stretches of time are critical. Unnecessary and inefficient meetings are common, and it is critical to understand how to wield this tool effectively.

In this post I will address key high-level aspects of successful meetings. There are specific meetings that most managers should have: one-on-ones, skip-level meetings, performance reviews, standup, architecture review etc. There is a lot to be said for each of them, and I hope to address these in separate posts.

Swiss cheese: tasty but it can kill you

An easy way to kill a software engineer’s productivity is to have their calendar look like Swiss Cheese, the kind with holes in it. Take for example a fictitious software engineer Carla: she comes in at 9 am. Starts working on a project around 9.15 am after doing some email. At 9.45 am after having immersed herself in the project she is writing code. At 10 am her Slack goes off: Stand up! It’s supposed to last for 15 minutes, but they finally wrap up at 10.40 am. Coffee anyone? After drinking her cup and socializing a bit, she’s back at her desk at 11:00 am. Clearing out more Slack messages, a few emails, OK back to the project, it’s 11.15 am now. At 12.30 pm the doorbell announces that the company lunch has arrived. Carla is back coding again at 1.30 pm. There has been no real progress yet, but the problem is becoming more clear. Oops, she’s almost late for a 2.30-3pm one-on-one with her manager. Back to code. 3.30-4.30 pm ops team meeting. 4.30-5 pm code reviews, 5-6 pm sprint planning meeting. Argg. She goes home, has some dinner, and sits down behind her laptop again at 8 pm. Finally a few uninterrupted hours, and she gets her project ready for a first code review at 11 pm.

This may sound crazy, but this type of day is not all that uncommon. “I do my real work at night” seems to be the rule rather than the exception amongst software engineers. Aside from all the time spent away from your desk, a compounding factor is that it’s nearly impossible to task switch without losing significant chunks of time when writing code. You’re juggling a lot of information in your head, and I estimate that you lose 15-30 minutes every time that you context switch into a different large task while programming. In the example above, Carla spent 4 hours behind her desk writing code, with 5 large breaks, that’s about 1.5 hours of lost time, so 2.5 hours effective working.

Minimize disruptions

As a manager, it is your job to maximize the productivity of your team. One “easy” way is to reduce distractions such as minimizing context switching or providing a distraction-free workplace for people that prefer that. Context switching is minimized when there are fewer meetings, or when meetings are aligned such that there are fewer holes in the “cheese” calendar. As a manager you should review your teams’ calendars so you can schedule meetings with the minimum amount of interruptions. This may mean for example asking some folks to come in earlier, have “meeting-free afternoons”, only do meetings on certain days of the week, or just simply be smart about when to schedule meetings. Don’t only do this for your own meetings, also educate your teams and other parts of the organization so that they do the same.

Don’t. Be. Late.

Most meetings are scheduled to last one hour because that’s the standard block of time on a calendar. Don’t do this. Instead, analyze how much time you really need. This usually works best in combination with a timed agenda which is circulated before the meeting. For example:

Meeting to discuss feature X, 9:00-9.35am

Purpose: give participants update on feature status, and gather feedback on proposed architecture.
Lead: Sarah

• 9:00-9:10 am: review feature scope and implementation proposal
• 9:10-9.30 am: gather input from participants
• 9.30-9.35 am: summarize feedback and plan next steps

The timing here is tight, and will quickly fall apart if folks are late and trickle in during the first 10 minutes. You should set a clear bar that this is not acceptable. It’s a waste of everyone’s time and expensive (in terms of dollars and morale). Starting a meeting at 9am should mean that everyone is in the room at 9 am ready to get started, and should plan on arriving a few minutes before. “Worst” case you account for 5 minutes of settling in time at the start of each meeting, but I suggest that you hold your team’s to a higher standard and respect each other’s time. Every meeting should have an owner, an agenda, and a follow up (see below). The owner should be responsible for running the meeting. This includes:

• Scheduling the meeting, while reducing schedule interruptions
• Determining participants, avoid very large meetings unless you’re simply informing people about a topic
• Setting the tone of the meeting at the start: state the purpose and what a successful outcome looks like
• Ensuring that everybody participates and has an equal opportunity to talk
• Keeping an eye on the clock, sticking to the agenda and keep the meeting moving forward
• Summarize the meeting and let everyone go in time
• Taking notes during, and send out a summary including follow up items with owners

Meeting Notes are more important than you think

The meeting lead should summarize the meeting and circulate meeting notes. They serve an important purpose:

• Documentation
• An opportunity for others to respond with more thoughts
• An opportunity for non-attendees to catch up on what was discussed
• A clear post-meeting “To-do” list with owner
• A “whiteboard capture” in case it is accidentally erased

You’ll be surprised how often people walk away from a meeting with a different understanding of what was discussed, notes can help get everyone on the same page, and give people an opportunity to correct or add nuance.

Ask for feedback, you can’t do it alone

Do you want to improve? Ask for feedback. Not only will you learn something, but you also get participants more involved in making meetings successful. You can only make meetings successful if the entire team thinking about how to improve meetings. One friend who runs a successful biotech company told me his teams started giving more meaningful feedback after they were primed about the cost of the meeting. If you have 8 people in a 1-hr meeting, at a gross rate of say $175k/employee/year that’s a ~$800 meeting, excluding wasted time caused by the interruption that the meeting caused. Discussing meeting cost helps with the basic understanding that meetings do not come free, and it’s in everyone’s interest to hold each other accountable to run the most effective and efficient meeting possible.