I wake up on Monday, roll over to see where I've left my work laptop lying on the bed the night before, and groggily open it up. After a few minutes of bright screens and start up sound effects I peer at my calendar and find a wall of back to back meetings spamming my entire week. I have a new engineer that recently joined my team who I need to onboard, two other seniors pinging me on slack about some production questions, some architectural diagrams I need to create, 20 pull requests waiting for me to review from 5 different teams, and actual code I need to write and deliver before the week ends. When will I get time to do any of those things with a calendar filled with meetings? I quickly scan the subject line of all these meeting invites and as expected they're related to items we're not working on in our current sprint. Some are dealing with upcoming work, others with things that don't even involve my team. So I smile quietly to myself and decline them all.

We've all been part of teams where our calendars are constantly flooded with meetings scheduled to talk about some requirement that's coming up in a future sprint. I'm here to tell you this is unnecessary and, in fact, detrimental to the bottom line of the company and mental health of the engineers.

It starts with the bad habit of scheduling numerous meetings to talk about topics for things the team will be working in a future sprint or to answer questions on how we'll solve for upcoming problem x, y, or z. These meetings tend to go on for 30 - 60 minutes and some go for hours. Most of the time no decision is made regarding the original topic.

The only things that get accomplished are taking an inventory of open questions and side tracking into detailed discussions on some small aspect of the original topic. This is problematic because as these meetings pile up and the weekend rolls around every one will forget the details of the discussion. So, new meetings need to be set up to rehash what was already discussed because no one remembers where they left off or what was said in the previous meeting.

This is exhausting for the engineers and damaging for the company. Engineers can become unmotivated and feel like their time is not appreciated. The time they spend attending these meetings is time they are being pulled away from higher value items. This doesn't make business sense either.

Writing code, and most engineering tasks, require concentration and prolonged focus. Any distractions are felt immensely and, on average, cost engineers 15-20 minutes to regain their previous level of focus. Meetings scheduled in the middle of a work day are the enemies of focus. Engineers will usually stop doing any meaningful work 15 minutes before a meeting in anticipation of losing focus during a critical moment.

Imagine being in the middle of solving a complex problem that has several steps and requires you to remember numerous facts. If you get distracted you'll probably have to start again from the beginning. Ramping up to a state of flow takes another 15-20 minutes after meetings have ended causing engineers to lose additional time trying to get back to an efficient state.

Additionally, most engineers feel meetings are a waste of their time. Either, because the information discussed is irrelevant to them or because the discussions don't answer their actual questions. Engineers know what problems they have and what questions they need to ask. They don't need someone trying to predict these questions, setting up a meeting to address them, and then realizing they've made no progress on their actual problems.

Business people are highly risk averse and like to reduce it as much as possible so they try to anticipate potential issues and solve for them but most of the time the issues they've imagined are not the issues the engineers are facing. My advice, if you're a business person, is to let the engineers drive the conversations and ask their questions. It will be more efficient and save everyone time.

Which brings me to my next point, you don't need a meeting for most things. Most meeting topics can be resolved in an email or chat message. That's what email chains and group chats are for. This removes the aspect of forced participation. How many meetings have you been to where 20 or more people are in the call but only 2 or 3 actively participate?

This is not say that all meetings should be eliminated but setting up a call should not be the first option to resolving issues.

We need to keep "delivering value" as our top priority.

A product owner is a business person, or in some rare cases an actual customer, who manages the priority of items that need to be delivered. These items have some value associated with them. Product owners are usually experts in their field and can answer any domain level questions the engineers may have. If they can't answer these questions they should know where to go and find these answers; like another domain expert or some domain reference.

A product owner's main job is to prioritize the items in the backlog in order of value; higher valued items go at the top. This means that all other items in the backlog are of less value than the top item. Delivering the highest value items first should be the most profitable decision for the company. At the start of a sprint the engineers will take on and begin work on the highest value items; ie the items at the top of the list.

If an engineer from the team is pulled into a meeting to discuss an item that they're not currently working on in their sprint it means they are shifting from a higher value item to something of lower value. This meeting is actually a loss for the company because of three reasons. One, nothing gets delivered during a discussion. Two, it costs the company money to pay engineering and product people to attend meetings. Three, the delivery of the higher value item is delayed.

The reality is that at any time these lower valued items can become deprioritized and the loss becomes even greater as time and resources were spent for something that will no longer be delivered. Since the team can only deliver the workload they've taken on in the current sprint it doesn't make sense to plan for much longer than this as they can't deliver more value than a sprint worth's of work at a time.

Backlog refinement and sprint planning meetings exist to address any other open questions the team may have which should spur the product owner to either find answers, reprioritize the backlog, or completely remove unnecessary items. These two meetings should be enough to clarify what the team will be working on in the current iteration. If these two meetings are not enough then those items are not ready to be worked on and the product owner needs to choose something else as the top priority.

So, go ahead and decline those meetings and if anyone asks you why you're not attending ask them whether they want you to stop working on a higher value item to discuss a lower value item. If they say this meeting is about an item of higher priority tell them to talk to the product owner so they can reprioritize the backlog and switch out a lower value item in the current sprint.