I regularly hear engineers complain about too many meetings. They’re right.

The specific complaint is usually about flow state, and it’s worth taking seriously. Flow state is where you’re fully locked in on a problem, holding a lot of context in your head at once. It takes 15 to 20 minutes to get there. Chop the day into pieces and flow doesn’t happen.

When you insert planning, refinement, retro, daily standups, a Scrum of Scrums, an engineering leads sync, and whatever cross-team dependency meetings have accumulated on the calendar, several hours of a sprint are already spoken for before a line of code gets written. In a short sprint, that’s a meaningful percentage of the available time.

Here’s the rule to apply: all standing meetings that support the sprint should consume about 10% or less of it. For 2 weeks, that’s one business day. For a 1-week sprint, that’s about 4 hours total. The meeting budget should scale with the sprint length.

Another common problem is that meetings accumulate and never get reassessed. Someone adds a sync to solve a problem. It works. The problem fades, but the recurring meeting stays. Attendees get added when coordination gets complicated. They rarely get removed when it simplifies. Over time the calendar fills up not because anyone designed it that way, but because the question never gets asked: does this meeting still earn its slot?

The engineers aren’t wrong about the meetings. Give them room to actually work.