Effectiveness anti-patterns — part 4: meeting overload

Sat, 02 May 2026 00:00:00 +0000

There are three things about meetings I had to learn the hard way as a senior engineer:

A meeting invitation is a request for one of the most expensive resources I have. It deserves more than a two-second yes.
Past three or four meetings in a day, my ability to do focused technical work does not just slow down. It starts to collapse.
When a conversation has drifted into a domain where I cannot contribute, staying in the room is not loyalty. It is often theatre, and it costs the team work that was supposed to ship.

This post is a reflection on those three things, partly nudged by Addy Osmani’s chapter on meeting overload, but grounded in my own calendar and my own mistakes.

The collapse at three or four meetings a day

A few weeks ago I looked at my calendar honestly for the first time in a while.

Three to four meetings a day. Most of them with overlapping participants. Some recurring without anyone, including me, remembering why.

The frustrating part was not the count. It was that I had said yes to almost all of them, and most of those yeses had not been thought about for more than a few seconds.

Three to four meetings does not sound like a lot. On paper it is two to three hours, maybe a third of a workday. The calendar math suggests there is plenty of room left for engineering.

For the kind of work I do, that math is misleading.

A migration plan, a DAG redesign, or a production debugging session that needs more than five minutes of context does not happen well in thirty- or forty-minute slices between calls. It needs long enough blocks for me to hold the system in my head.

Once the day is broken into six pieces by meetings, those blocks often disappear. The work shifts to evenings, gets done badly, or quietly slides to next week.

I had not decided to give that time away. I had just stopped guarding it.

A meeting invitation deserves real scrutiny

For many senior engineers I know, the default-yes behaviour does not come from insecurity.

If you own a system, missing the meeting where a decision is made about that system feels expensive. So you go.

If a partner team invites you to a sync about a topic that touches your platform, declining can look like you are not engaged. So you go.

If a more junior engineer is presenting a design and your area is involved, you want to be there to support them. So you go.

Each reason is fine in isolation. The problem is what happens when you stack them across a week.

By the end, you have spent your day representing systems, not building or improving them.

For a while I confused those two things.

The shift for me started when I began asking, before accepting, a slightly uncomfortable question.

Am I the right person to be in this meeting, or am I the convenient person?

The answer was often “convenient.”

I had context on a system. I had been in the previous meeting on the same topic. My name was already on the invite list from a thread I no longer remembered.

That is not the same thing as being the right person to be there.

The right person, in my reading, is someone whose presence changes the outcome: because they have to make a decision, defend a tradeoff, commit to a timeline, or share information that nobody else can.

Once I started filtering invitations through that question, a fair number of them simply did not pass it.

Leaving when I am not the right person anymore

The harder version of this is leaving meetings I have already joined.

There are meetings where, twenty minutes in, I realize the discussion has drifted into an area where I cannot contribute. Maybe it is a modeling choice the data scientists need to argue out among themselves. Maybe it is a service-side concern that does not touch the pipeline I own.

In the past, I would stay. Out of politeness. Out of a vague sense that leaving would look bad.

I have stopped doing that more often.

If I can say in one sentence “this is not my call to make and I trust the people in the room to make it,” I leave. Quietly, with a short note in chat if it helps.

The first few times this felt rude. Most of the time, it is not. It is honest.

Staying in a meeting where I have nothing to add is not a contribution. It is a small lie I am telling about my own usefulness, and a real cost to whatever I should be shipping that hour.

The work that ships is rarely the work happening in the room I just stayed in to be polite.

What I had to admit

The uncomfortable part is that some of the over-attendance was about visibility, not value.

If I am in the room, people see me. They associate me with the work being discussed. Saying yes to a meeting is one of the cheapest ways to feel involved without actually doing involved work.

That is a soft trap, especially for someone trying to operate at a more senior level. It looks like presence. It is mostly performance.

The senior version of involvement is harder.

It is showing up to the meetings that genuinely need my judgment, prepared, with a position. It is declining the rest in writing, with a short reason and a pointer to who is actually the right person. It is leaving a meeting when the topic has moved past my contribution, and using that hour to ship the thing only I can ship.

I have not been doing this perfectly. I am still working on it.

What has helped in practice

The useful changes have been small and unglamorous.

Reading the agenda before accepting. If there is no agenda, asking for one. If the answer is vague, saying I will catch the notes.

Reserving two-hour focused blocks on my calendar with the same seriousness I reserve a meeting. They are commitments to the work I owe the team, not “free time.”

Replying to recurring meetings I no longer need with a short note: “I do not think I am adding value here anymore — happy to be pulled back in if a topic specifically needs me.” Most of the time the organizer is relieved.

Leaving meetings when the conversation has moved past what I can contribute, instead of staying for the optics.

None of this is a productivity hack. It is closer to a basic operating discipline I should have built earlier.

The part that ships

The reason this matters is not only work-life balance.

The work I am responsible for — pipeline migrations, infrastructure decisions, production reliability — does not happen in the gaps between calls. It happens when I have enough continuous time to think clearly, write something that works, and verify that I have not broken anything.

If I give those blocks away one acceptance at a time, the work either does not get done or gets done worse, by a more tired version of me, late at night.

The team rarely benefits from that version of me. The migration we are running this quarter does not benefit. My manager does not benefit.

Protecting that time is part of the job. It is not the same as being available.

One question I try to use now

When an invite shows up, I try to ask one question before accepting:

If I do not show up, what specifically goes wrong?

If the answer is “the meeting still works, someone else owns this” — I decline.

If the answer is “they would proceed without me but might miss something I know about the system” — I send a written note and skip the call.

If the answer is “a real decision will be made about something I own, and I need to be the one defending the tradeoff” — I show up, prepared, and contribute.

That question has not made my calendar empty. It has made it more honest.

And honest is usually a good starting point for the work I am supposed to be doing.

Meetings on Peter Fulop