Nobody likes being stuck in constant meetings—especially tech people. When I was a developer 10 years ago, I cared about one thing: coding. My focus was on building features, merging pull requests, and moving on to the next task. Every interruption felt annoying, pulling me away from what I loved most—building the product. Back then, meetings seemed like “useless stuff.”
Over time, I started to see the bigger picture. As I gained a better understanding of business value and customer focus, it became clear: coding isn’t the end goal. It’s a tool—a powerful one—but just a tool. Our real job as developers is to solve customer problems, deliver a product that makes their lives easier, and, in doing so, help the business achieve its goals.
That’s how we create value. It’s also what keeps a company running and pays the salaries that let us do what we love.
Dealing with meetings overload
When you’re part of a small team—up to 10 people—it’s easy to stay in the loop. You know which clients are in the pipeline, what features they’re requesting, whether there are any complaints from existing customers, and even what the founders are thinking. Communication feels natural, and everyone seems to know what’s happening.
But as the team grows—20, 30, 50 people—it becomes harder to keep track. The flow of information that once felt effortless starts to break down, and two common scenarios tend to emerge:
- You stick with the same flat structure, where everyone talks to everyone.
- You introduce clear processes and boundaries, creating a system where communication scales efficiently.
The first scenario comes with two major problems:
- As the team grows, everyone ends up in meetings where they only need a fraction of the information being shared.
- With more people, the number of meetings grows as everyone starts seeking input from others.
The result? Chaos. Productivity stalls as everyone in the company gets bogged down in a cycle of endless meetings that leave little time for actual work.
To fix the chaos, you introduce some structure:
- Founders/C-level: Setting the vision and strategy.
- Team leads: Translating goals into actionable plans.
- Engineers and execution teams: Building and delivering the work.
This three-tier structure seems logical, but it comes with a challenge—communication loss. Research shows that about 30% of information is lost with each level it passes through. By the time a founder’s vision reaches the execution team, over 50% of the original message is already lost.
Here’s the paradox with it:
- Stay flat, and you’ll have endless meetings to keep everyone aligned, but no one has time for focused, productive work. Tech people hate this.
- Introduce structure, and you’ll cut down on meetings for delivery teams, but now engineers risk becoming task robots—delivering code without understanding the bigger picture. They lose the business context and the information they need to propose meaningful solutions or innovate. That’s not what we want. Engineers are creative, highly skilled, and expensive for a reason. Turning them into executors instead of problem solvers is a waste of their talent—and your money.
And here’s the dream scenario:
- Engineers have full context—users, sales, the founders' vision, goals, and everything else they need.
- They spend most of their time building great products, with only a handful of meetings.
- Everyone enjoys a good work-life balance, working during their most productive hours, whether that’s early mornings or late nights.
It might sound impossible, but we can get a lot closer with the right approach.
Here’s how I suggest solving this: break it down into three levels—personal, team, and company.
Personal level
At the personal level, it’s all about discipline and the ability to say ‘no’. People will often try to pull you into meetings—maybe they need a quick input or want you to "get some context." But not every meeting is worth your time. Here’s what I do to cut down on unnecessary meetings:
- Always ask why you’re needed in a meeting and how you’ll contribute. If you’re not going to play an active role, just decline.
- Identify when and where you’re most productive—whether that’s early mornings, late afternoons, or even while sitting in the car waiting for your kids. Time or place doesn’t matter, as long as you block those times in your calendar. Protect these focus hours from interruptions, so you can dive deep into your work without distractions. I personally think this is especially important for engineers, as the best can 10x outperform average ones. A big reason for that is focus - when they have uninterrupted time for deep work, they deliver a lot more value.
- If you’re only there to listen or get the outcome, ask for the meeting to be recorded. Use note-takers or Loom to capture the discussion, action steps, and decisions. You can catch up asynchronously while traveling, or just not in the right headspace for focused work.
Team level
On the next level, it depends on the Product manager whether a team would have a flexible schedule with very few meetings or a calendar full of daily standups, plannings, retros, demos, 1:1s, and endless “let’s sync on this” calls. Add it all up, and it’s no wonder the team struggles to deliver anything. Here’s what team meetings should look like:
- Standups should be short—no more than 15 minutes. They’re meant for quick daily updates and identifying blockers, not long discussions. But too often, they spiral into 30-minute or even hour-long conversations, which is absurd. Engineers only have 5–6 hours of effective work time in a day, so wasting an hour in a standup means losing 15–20% of their productivity. I haven’t found the best approach, but I’d recommend experimenting with chat-based status updates. Focus on highlighting help, issues, and blockers, so only the relevant people are involved, and problems get resolved quickly without dragging everyone in.
- Combine retros and planning sessions back-to-back without interruptions. Retros help align the team and improve how they work together, while planning ensures productivity by setting a clear path to deliver results with an impact. Keep each session focused —30–45 minutes max—and run them bi-weekly to maintain momentum without overwhelming the team.
- 1:1s are important because they provide dedicated time for private conversations between a lead and an engineer. It’s a chance to focus on the individual’s growth, check in on their development plan, and offer support where it’s needed.
There’s a common perception among product teams that skipping detailed documentation—like expectations, definitions of done, or clear requirements—helps move things faster. But in reality, it often slows everything down. Without clear guidance, engineers aren’t aware what needs to be done and face two scenarios:
- They make decisions about the product and handle different scenarios. This can work only if they’re highly experienced and business-oriented. But without that level of expertise, things often go off track. The feature gets built, but it doesn’t meet expectations. The Product manager steps in, points out what’s missing, and the engineers end up reworking it with more context. This loop can repeat multiple times, and it’s definitely NOT fast.
- The Product manager schedules a meeting to explain what needs to be delivered. While this might speed things up temporarily, people forget details, leading to more interruptions and follow-ups. Productivity takes a hit, and the team still ends up stuck in the same frustrating loop of rework and misalignment.
I’m not a fan of writing long papers, but a team needs to find the right balance. Clear enough documentation ensures engineers have the information they need to deliver without constantly being pulled into sync or context meetings.
Company level
This is the most challenging part—or maybe it just feels that way because I’m the one leading these meetings. Founders/C-levels are always focused on whether everyone is aligned on goals, company updates, key decisions, delivery progress, and overall team happiness. It’s too easy to turn every one of these concerns into a meeting. Before you know it, every status update or piece of context becomes another slot on the calendar. Here’s how I handle this:
- Monthly all-hands meeting: This is the one meeting I believe should never be skipped. It’s the only time each month where founders and the C-level team can directly communicate with everyone, and employees can ask questions they need answers to. I keep the updates as short as possible—20–30 minutes max—and focus on providing context, not just repeating numbers that are already available in our tools. I dedicate around 30 minutes for questions, and if more time is needed, I make sure to give it. Those discussions are too important to cut short.
- No-meeting days/half-days: Even with the best personal and team practices, meetings still find a way to creep in and pull people out of their productive flow. That’s why it’s a good idea to set aside a full day or half-day with no meetings. It ensures everyone gets uninterrupted time to focus and dive deep into meaningful work without distractions.
- Share updates asynchronously: Similar to team-level practices, most updates—like sales results or company travel plans—should be shared asynchronously through tools like Notion or Loom. This way, anyone who’s interested or needs more context can access the information on their own time, without being pulled into unnecessary meetings.
The bottom line
Meetings aren’t inherently bad—it’s having a meeting for everything that causes problems. Constant interruptions and context-switching take a serious toll on productivity. If you notice delivery slowing down or hear complaints about heavy workloads, start by looking at how many meetings people are attending and how much uninterrupted time they have each day. You’ll likely find the answers there.
.png)
