The Real Reason Developers Hate Meetings (It’s Not Time) 🧠💥

Was this post written during a long, pointless meeting?
Of course not!
…Or was it? 👀

Let’s start with this: I’ve been in the industry for over ten years. I’ve met all kinds of developers - including the stereotypical introverts who would rather refactor legacy code than talk to another human being.

And yet, I still haven’t met a single developer (no matter how introverted) who said:

“I’d much rather explain something for an hour on chat than just jump on a 5-minute call.”

(For office folks: replace “call” with “walk up to someone’s desk.”)

So no - we don’t hate people or conversations. Quite the opposite!
A short, focused call is gold for any developer. 💎

What we hate is something entirely different.

Endless, soul-crushing meetings 😵‍💫

You know the kind:

*️⃣ It could’ve been an email.
*️⃣ The same topic gets re-hashed for the tenth time.
*️⃣ Half the attendees have no idea why they’re even there.
*️⃣ Someone inevitably shares their screen and talks for 30 minutes straight.

As a senior dev / tech lead, you can get completely trapped in meetings.
In my previous company, I caught myself avoiding complex tasks — not because they were hard, but because meetings would make them take twice as long as they would for a junior dev with no calls that day.

Meanwhile, some “meeting person” feels accomplished because they scheduled a call “with many important people.” 🎉

And I’m not innocent either. Once I scheduled a 12-person call… only for the other team’s tech lead to say:

“Well, we’ll see. We need to check.”

That was it. That was the whole value of the meeting.
At least I felt ashamed for wasting everyone’s time. 🙃

The Myth of Multitasking 🧠❌

Some people - usually non-technical - believe that lots of meetings are fine because:

“You can just do something else in the background.”

Yeah, no. That myth was scientifically debunked last century.
There is no “multitasking.” There is only context switching - and it drains brainpower like crazy.

So you either:

Tune out completely and do your own work (in which case… why were you invited?)
Try to listen, knowing at any moment someone may say: “Let’s hear what you think.”

Result: you can only do simple, low-effort tasks - or, if you have none, you may as well write a blog post. 😉✍️

Software Development ≠ “Just Typing Code” ⌨️🧩

People often don’t understand the nature of software development.

Real development requires deep focus. And when that focus lasts long enough, you enter the famous flow state - where:

✅ things finally make sense
✅ the problem is “loaded into RAM”
✅ progress becomes fast and satisfying

…until a calendar notification pops up:

“Let’s have a 45-minute call to discuss something we already discussed three times, just to document it properly in a spreadsheet.”

or:

“Let’s invite 20 people to brainstorm a feature we might implement in 2028.”

A dev with three 1-hour meetings does not have 5 fully productive hours left.

After a meeting, you’re mentally drained and you need time to reload the entire context of your work.
That’s not laziness. That’s simply how the brain works. 🧠⚙️

🎯 Bonus Research

Research shows that it takes an average of 23 minutes and 15 seconds for a person to get back to their original task after a context switch. (Monitask)
According to one source, context-switching can reduce productivity by 20% to 80%, depending on how many switches and their type. (trunk.io)
It is estimated that context switching costs the global economy approximately US$450 billion annually. (atlassian.com)
One report found that the time staff spend managing and attending meetings costs employers an annual average of US$29,000 per employee. (WorkLife)
A study by London School of Economics and Political Science found that ≈ 35% of business meetings are unproductive, with the overall annual cost to firms of unproductive meetings estimated at US$259 billion in the US. (lse.ac.uk)
Only ≈ 30% of meetings are considered productive, and only ≈ 37% actively use an agenda. (Notta)

So what is a good meeting? ✅

Short. Clear purpose. Right people. Output > conversation.

Below are some practical tips you can steal 👇

🛠️ Action Points: How to Run Developer-Friendly Meetings

✅ Ask yourself first: “Do we really need a meeting? Can this be a comment, ticket update, or 3-message chat thread?”
✅ Invite only the people who actually need to be there. Optional attendees = async notes.
✅ Define the goal in one sentence. If you can’t — you’re not ready to schedule a meeting.
✅ Set a default length of 15 min. Extend only if needed.
✅ Start with facts, not storytelling. “Here’s the problem. Here are the options.”
✅ End with a decision and owner. If no decision was made — the meeting failed.
✅ Send a 3-bullet summary after. So no one has to join “just in case.”

Bonus tip:
If you must brainstorm, use async pre-work so the call starts at solution level, not catch-up level.

💬 How much flow time did you lose this week because of meetings? Drop a comment — let’s calculate the real cost of calls.