Why More Meetings Slow Down Delivery (And What Works Instead)

Is your software team collaborating? I’m sure most leaders in tech would happily exclaim “Yes!” and you certainly would be correct to some extent. So the next important question is: “How are you collaborating?”

Collaboration is one of the most misunderstood activities in software development. All software is built in some form of collaboration, but what often happens is we introduce multiple layers of process that introduce various levels of friction.

If you’ve read my previous articles, you’ll notice a repeating pattern I talk about-reducing the length of feedback loops. The best way to define collaboration is the process of getting information/knowledge/wisdom from one person to another.

For example: - Product managers who know what needs to be built have to communicate it to the engineers who know how to build it - A developer who is leaving the company and is the only person who knows an obscure part of the codebase needs to share what they know with the team - A designer needs to explain a complex interaction pattern to developers - A tester needs to communicate edge cases to developers

All of these necessitate some form of communication. The question is: what’s the most effective way to do it?

How Teams Fake Collaboration

There’s a reason why software engineers (not only engineers, to be fair) talk about the negative impact of multiple meetings. Context switching is a real issue and a well-documented bottleneck to productivity.

The Meeting Overload Problem

One of the most common patterns I’ve seen in teams is having multiple ceremonies around work tasks:

Pre-grooming sessions
Grooming sessions
Refinement sessions
Planning sessions
Kickoff sessions
Sync meetings
Status meetings
Retrospectives
And so on, and so on…

Each meeting seems necessary, but together they create a meeting-heavy culture where actual work happens in the gaps between meetings.

The Planning Fallacy

The problem is in software there are always unknowns which can dramatically impact the velocity and cost of delivering something. You do a planning session with very little information about the work you’re about to do over the next sprint or two, and what many teams attempt to do is have a perfectly refined snapshot of what the work is.

We try to: - Limit story points - List all scenarios - Define acceptance criteria - Identify dependencies - Plan every detail

In essence, we try to clarify a piece of work as much as we can before starting.

The Reality of Software Development

If you’ve been in the industry long enough, you have to admit that’s rarely the case. Most of the time there will be:

Multiple unknown constraints - Things you didn’t know you didn’t know
Scenarios you don’t care about right now - But might matter later
Scenarios you didn’t realize you’d have to consider - That emerge during development
Technical discoveries - That change the approach
Edge cases - That weren’t obvious initially

The Meeting Spiral

At that point you’ve spent a couple of hours on planning and start working on something. You suddenly uncover a few unknowns and organize a meeting, but all the people you need aren’t immediately available, so you organize a meeting 2 days from now to gather everyone on the same Zoom call.

Work flow stops!

You’re blocked, waiting for a meeting, unable to make progress. By the time the meeting happens, you’ve lost context, and the discussion isn’t as productive as it could have been.

The Ticket Obsession

The obsession with perfectly clear tickets that anyone can pick up and meetings to “sync up” are one of the biggest problems to having a high-performing team.

Tickets become a proxy for collaboration. Instead of talking to each other, we write tickets. Instead of collaborating in real-time, we schedule meetings. Instead of working together, we work in isolation and sync up later.

The Real Problem: Asynchronous Collaboration

The problem is not necessarily with meetings or tickets, but how we view them as the main point of synchronizing work on a project.

This is an asynchronous cycle with respect to the work itself:

Work → Meeting with stakeholders → Writing tickets → Work → Repeat

This introduces wait times and delays in our system of work.

The Abstraction Layer Problem

Furthering the problem is the over-reliance on tickets that we touched on. A text-based list of user scenarios is an abstraction layer between the people who need to communicate - product managers, software developers, designers, testers, etc.

Arguably, text is a very poor way of communicating ideas, system flows, and UX choices.

Think about trying to explain: - A complex user flow in text - A visual design in words - A system architecture in a ticket - An interaction pattern in acceptance criteria

It’s possible, but it’s inefficient. Much gets lost in translation.

The Context Loss Problem

When collaboration is asynchronous, context is lost:

Time passes: By the time someone reads your ticket or attends your meeting, they’ve forgotten the context
Details fade: The nuances of the problem get simplified or forgotten
Assumptions creep in: People fill in gaps with assumptions
Misalignment grows: Different people understand things differently

The Waiting Problem

Asynchronous collaboration creates waiting:

Waiting for tickets: For someone to write or update them
Waiting for reviews: For someone to review your work
Waiting for meetings: For the next sync-up
Waiting for decisions: For stakeholders to make up their minds

All this waiting adds up to longer cycle times and slower delivery.

How to Actually Collaborate

So how do we improve these problems?

The Goal: Synchronous Collaboration

It’s not about having meeting-free days. Of course, we’ll always need meetings, but the trick is to know how to have meetings productively. Find the most productive way to communicates the most amount of information between the people involved in a task.

The goal here is again to reduce the feedback loops so that you don’t have to go through the meeting cycle multiple times to add a simple text field to a form.

Effective Collaboration Techniques

There are several techniques that work well:

Mob Programming: Multiple developers work on the same code at the same time. Great for: - Complex problems that benefit from multiple perspectives - Knowledge sharing - Code quality - Learning

Pair Programming: Two developers work together. Great for: - Code reviews in real-time - Knowledge transfer - Catching bugs early - Learning

Design Sprints: Intensive workshops for product decisions. Great for: - Aligning on complex features - Making decisions quickly - Building shared understanding - Validating ideas

PM-Developer Pairing: A PM and developer work together for a day. Great for: - Clarifying requirements in real-time - Making trade-offs together - Understanding constraints - Building better features

Event Storming: A Powerful Collaboration Technique

But one of my favorite ways to improve collaboration is Event Storming.

Event Storming is a workshop format that helps bridge the gap between product people and engineers. It can be done at a very high level (whole system) or focused on a particular new feature.

How Event Storming Works

The idea is simple: gather all relevant stakeholders in a room (or virtual whiteboard), use sticky notes to create a timeline of important events and user commands.

Note: You don’t need an event-driven system (existing or future) to do the workshop. The idea is to reason about states and what happens when a user performs an action in the system.

The Process

Gather stakeholders: PMs, developers, designers, testers, domain experts
Create a timeline: Left to right, showing the flow of events
Add events: What happens in the system? (e.g., “Order Placed”, “Payment Processed”)
Add commands: What actions trigger events? (e.g., “User clicks Checkout”)
Add actors: Who performs these actions? (e.g., “Customer”, “Admin”)
Identify aggregates: What are the main entities? (e.g., “Order”, “Payment”)
Discuss: Talk through the flow, identify edge cases, clarify understanding

What Makes It Powerful

Instead of writing tickets that get misinterpreted, everyone builds a shared mental model together:

The PM explains what happens when a user clicks “submit order”
The engineer asks “what if the payment fails?”
The designer shows the flow visually
The tester identifies edge cases

In 2-3 hours, you’ve aligned on: - The problem - The solution approach - The edge cases - The technical constraints - The user experience

All without a single ticket.

The Benefits

Shared Understanding: Everyone leaves with the same mental model. No more “I thought you meant…”

Faster Development: Developers know exactly what to build. No more back-and-forth clarification.

Better Design: Designers understand the full flow, not just their piece.

Fewer Bugs: Edge cases are identified upfront, not discovered later.

Less Rework: Misunderstandings are caught early, not after development.

When to Use Event Storming

Event Storming is particularly useful for:

New features: When you’re starting something new
Complex domains: When the problem space is complicated
Cross-team work: When multiple teams need to align
Legacy systems: When you need to understand existing systems
Refactoring: When you’re redesigning a system

Getting Started

You don’t need special tools or training:

Gather the right people: PM, developers, designers, domain experts
Set aside 2-3 hours: Block time for focused work
Use sticky notes: Physical or digital (Miro, Mural, etc.)
Start with events: What happens in the system?
Build the timeline: Left to right, showing the flow
Discuss and refine: Talk through the flow, identify gaps

(More on Event Storming: https://en.wikipedia.org/wiki/Event_storming)

The Principles of Effective Collaboration

Based on what we’ve discussed, here are the principles of effective collaboration:

1. Synchronous When Possible

Work together in real-time when you can. It’s faster and more effective than asynchronous communication.

2. Visual Over Text

Use diagrams, sketches, and visual tools. They communicate complex ideas better than text.

3. Shared Understanding

Build shared mental models together. Don’t just document-discuss and align.

4. Reduce Abstraction Layers

Talk directly to people. Don’t use tickets as a proxy for communication.

5. Focus on Outcomes

Collaborate on decisions and discovery, not just documentation.

6. Make It Easy

Lower the friction for collaboration. Make it easy to ask questions and get answers.

Conclusion

Collaboration is essential for software development, but how you collaborate matters more than whether you collaborate.

The problem isn’t that teams don’t collaborate-it’s that they collaborate ineffectively:

Too many meetings that don’t add value
Over-reliance on tickets as communication
Asynchronous cycles that create delays
Abstraction layers that lose information

The solution is to:

Collaborate synchronously when possible
Use visual tools and techniques
Build shared understanding together
Reduce abstraction layers
Focus on outcomes, not documentation

Techniques like Event Storming, mob programming, and design sprints can dramatically improve collaboration effectiveness. They’re not silver bullets, but they’re better than the meeting-heavy, ticket-driven approach many teams use.

The goal isn’t to eliminate meetings or tickets-it’s to use them effectively. When collaboration means “more tickets + more meetings,” you’re doing it wrong. When collaboration means “shared understanding + faster delivery,” you’re doing it right.

If collaboration currently means “more tickets + more meetings” in your organization, it’s time to try a different approach. The best teams aren’t the ones with the most meetings-they’re the ones with the most effective collaboration.

And effective collaboration doesn’t mean more process-it means better communication, shared understanding, and faster feedback loops.

If you want a fast, objective view of what’s slowing delivery down in your organization, you can do my 2-minute Delivery Flow Assessment to get a personalized report of how your team operates and suggestions on how to improve.

Or if you’d like to a more personalized approach and 1-to-1 time with me let’s have a conversation - Book a Call here

It’s a more comprehensive analysis where we’ll map your value streams, identify bottlenecks, and outline how we can work together to improve your delivery system.