The Day I Quit Meetings for 90 Days

My breaking point came on a Tuesday in March. Twenty-plus hours of meetings filled my calendar that week, and that didn't even count the "quick syncs" sure to materialize out of nowhere. After eight months as a tech lead at our health tech startup, my job had somehow morphed from writing code and guiding architecture into professionally attending meetings.

On that particular Tuesday, VS Code got opened exactly twice. Both sessions lasted under 15 minutes before another notification dragged me away.

Here's the thing: performance wasn't declining. My calendar was packed because people valued my input. But the math simply didn't work. How could anyone lead technical decisions for a growing engineering team while spending most of their time in synchronous conversations that could have been a Slack thread?

So an idea took shape, one that felt career-limiting at the time. A pitch went to my leadership team for a 90-day experiment: saying no to every meeting and relying entirely on async communication. No standups. No planning sessions. No one-on-ones. Nothing.

What happened next taught me more about developer productivity without meetings than any blog post or conference talk ever could. Some lessons were predictable. Others caught me completely off guard.

Getting Buy-In for a Radical Experiment

Let me be clear about something: ghosting my calendar wasn't an option. That's a fast track to unemployment.

Instead, a proposal got written. Five pages. It covered the problem (context switching destroying my output), the hypothesis (async-first communication would improve both my productivity and my team's autonomy), and most importantly, the safeguards.

Those safeguards mattered. My commitments included:

• Responding to all async messages promptly throughout the business day
• Recording brief daily Loom updates to replace standup
• Being available for real emergencies via phone
• Tracking and sharing weekly metrics on my output
• Killing the experiment immediately if it hurt the team

My engineering director was skeptical but intrigued. Our VP of Product needed convincing. Her exact words still stick with me: "This feels like you're checking out."

Pushing back was necessary. Meetings had become our default communication method because it was easy, not because it was effective. She saw my calendar next to my commit history. The inverse correlation? Embarrassing.

She gave me a trial period initially, which got negotiated to 90 days by agreeing to more frequent written check-ins.

If you're wondering how to decline meetings professionally as a developer, start here. Don't make it about avoiding work. Make it about doing better work. Come with data, come with a plan, and come with safeguards showing you're not abandoning responsibilities.

Replacing Everything with Async Tools

Before day one, my replacement system needed building. You can't just remove meetings and expect everything to work. Better alternatives are essential.

For daily standups: Short Loom videos each morning. Walking through what got done yesterday, what's getting tackled today, and any blockers. My team could watch at 1.5x speed on their own schedule.

For planning and brainstorming: Everything moved to Notion documents. Detailed proposals with my thinking would sit open for 48 hours of async comments, then decisions came from the discussion. This became one of the best async communication methods for software engineers on my team, not just for me.

For code review discussions: We shifted to PR-driven communication. Instead of scheduling a meeting to discuss architecture, a draft PR with extensive comments explaining my approach would invite async feedback.

For one-on-ones: This was the hardest replacement. A shared doc with each direct report let them add topics throughout the week. Written responses went back, and those docs helped identify when real-time conversation was actually necessary.

The toolkit wasn't perfect on day one. Weekly iterations based on what wasn't working kept things improving.

Tracking What Actually Changed

Engineers measure things. Here's what my personal tracking showed across 90 days:

Focus time blocks (2+ uninterrupted hours):

• Before experiment: 3-4 per week (based on my own calendar analysis)
• During experiment: significantly higher, eventually reaching 10+ per week

Commits to main branch:

• Monthly average before: around 50
• During experiment: roughly doubled by the end of the 90 days

PR review turnaround time (from request to completion):

• Before: often took most of a day
• During experiment: dropped to just a few hours on average

That last one was surprising. Async seemed like it would slow down collaboration. Instead, the opposite happened. When reviews came in, they got handled during natural breaks in focus time rather than waiting for a scheduled meeting to discuss them.

My weekly survey to the team (anonymous, simple thumbs up/down on "Are you getting what you need from Priya?") stayed consistently positive after the first rocky week.

But here's the metric that mattered most personally: a microservice migration that had been stalled for months finally shipped. That's what deep work for software engineers actually looks like when you protect it.

Unexpected Consequences

Not everything was sunshine and productivity gains. Let me be honest about the weird parts.

What went surprisingly well:

Our documentation got dramatically better. Because explaining things in meetings wasn't possible, writing it down became mandatory. Those written explanations became living documents that helped onboard new engineers later that year.

My team's written communication improved too. They stopped asking "Can we hop on a quick call?" and started writing clearer, more complete messages because they knew that's how answers would come.

Junior developers actually got more attention, not less. In meetings, the loudest voices dominated. In async threads, everyone could contribute thoughtfully, and responses could go to each person individually.

What proved difficult:

Loneliness was real. Week three hit hard. Monthly board game nights exist because being around people is something to look forward to, and the isolation of pure async work was rough. Walks with colleagues got scheduled, not to discuss work, just to stay human.

Some relationships cooled. A PM who'd worked closely with me admitted later that she felt abandoned. We repaired it, but the experiment had a cost.

And then there was anxiety. Without the reassurance of constant meetings, feeling disconnected from what was happening became common. Was the team struggling without me noticing? Was leadership losing faith? Written updates said everything was fine, but my brain didn't always believe them.

What Came Back: Two Irreplaceable Meeting Types

By day 90, my answer about how to reduce meetings as a developer without losing what matters became clear. Most meetings are replaceable. Two types aren't.

Relationship-building conversations. You can't build trust entirely through text. Regular one-on-ones with each direct report came back, but with a rule: no status updates allowed. Those happen async. These meetings are for career conversations, personal check-ins, and building the kind of rapport that makes hard feedback possible.

High-stakes, high-ambiguity decisions. When we're dealing with novel problems where nobody has the answer, real-time conversation matters. The back-and-forth, the ability to read confusion on someone's face, the collaborative energy of thinking together: async can't replicate it. But this should be rare, maybe once or twice a month.

Running these remaining meetings looks different now. No standing meetings. Each one gets scheduled only when needed, with a clear agenda, a hard time limit, and a written summary posted within an hour of ending.

What those 90 days revealed: most meetings exist because we're too lazy to write things down, not because we actually need to meet.

Your 30-Day Version

Look, doing exactly what happened here isn't something most people should attempt. Saying no to meetings at work for 90 days straight requires specific circumstances: a supportive manager, enough credibility to spend, and a job where it's even possible.

But a smaller version can start Monday.

Week 1: Audit every recurring meeting on your calendar. For each one, write down what you actually get from it. Be honest.

Week 2: Identify your three most draining meetings, the ones that consistently feel pointless. Skip them. Send async updates instead. Watch what happens.

Week 3: Propose replacing one team-wide meeting with an async alternative. Try Loom for standups or Notion for planning. Measure whether the team notices any drop in effectiveness.

Week 4: Evaluate. What worked? What broke? Where do you actually need real-time conversation versus just defaulting to it?

Starting small is how one developer increased productivity by saying no to meetings. The 90-day version came later, after proving the concept.

The core insight isn't that meetings are evil. It's that meetings should be rare, intentional, and irreplaceable. Everything else? There's usually a better way.

Now close your calendar. Open your IDE. And build something.

---

Have you tried reducing your meeting load? Would love to hear what worked and what spectacularly failed. Find me on the Austin tech Slack or at the next meetup.