How to Escape the SRE Meeting-Industrial Complex
How to reclaim your brain from the meeting-industrial complex
Monday morning. I opened Slack at 8:30. By 8:47 I had four meeting invites: a standup, a sync, a pre-mortem for a system that hasn’t broken yet, and a “quick alignment call” about the alignment call we had on Friday.
By 11am I’d spent two and a half hours talking about reliability. I’d spent zero hours improving it.
Someone on r/devops posted this week: “My team should be renamed to TalkOps.” Ninety-nine percent upvote ratio. Every SRE on the planet felt that in their chest.
Hey, I’m Lakshmi — I help developers build, deploy, and distribute their SaaS without hiring a team. I also run Stacksweller and Supabyoi.
New here? Start with Why Your AI Wakes Up Every Morning With No Memory or Clean Code Is Dead.
The Meeting-Industrial Complex
Here’s what happens in platform engineering and SRE orgs at scale. The work is invisible. Nobody sees the deployment pipeline until it breaks. Nobody notices the monitoring until it doesn’t fire. The only proof that your team exists is... meetings.
So meetings multiply. Not because they’re useful, but because they’re visible. Your manager needs to justify headcount. Your team needs to “align” with five other teams. Every incident spawns a post-mortem, every post-mortem spawns action items, every action item spawns a planning meeting, and the planning meeting spawns a follow-up sync to check on the action items from the post-mortem about the incident that happened because nobody had time to do deep work because they were in too many meetings.
The recursion is beautiful, in a terrible way.
Deep Work Is the Actual Product
I’ve been a Principal SRE for long enough to have an opinion that would get me in trouble at most companies: most reliability improvements happen in 2-hour blocks of uninterrupted focus, not in 30-minute standups.
The monitoring rule that catches the subtle memory leak? That took a quiet afternoon staring at Grafana dashboards. The deployment pipeline fix that cut rollback time from 20 minutes to 90 seconds? That was a Saturday morning when Slack was silent.
The real work — the stuff that actually moves your error budget in the right direction — requires the kind of concentration that evaporates the instant someone says “can I get 15 minutes?”
Fifteen minutes is never fifteen minutes. It’s five minutes of context-switching in, fifteen minutes of meeting, and thirty minutes of trying to remember what you were doing before the meeting. That’s fifty minutes gone for fifteen minutes of “alignment.”
The Side Project Tax
Here’s where it gets personal. If you’re an SRE who also builds on the side — SaaS, open source, writing, whatever — the meeting-industrial complex doesn’t just eat your work day. It eats your creative energy.
I leave my day job some days having produced nothing but words. Spoken words. Words in Zoom calls. Words in Slack threads about Zoom calls. By the time I sit down to work on my own projects, my brain is cooked.
Not tired-from-solving-hard-problems cooked. Tired-from-performing-productivity cooked. There’s a difference. One is the good kind of exhaustion. The other is the kind where you stare at your side project and think “I’ll just do this tomorrow” for the 47th consecutive day.
The cruel irony: the skills that make you good at SRE — systems thinking, pattern recognition, automation instinct — are exactly the skills you need for building products. But TalkOps burns through your cognitive budget before you can apply those skills to anything that’s actually yours.
Fighting Back (Without Getting Fired)
You can’t just decline every meeting. I’ve tried. People notice. “Not a team player” shows up in your review. The trick is strategic visibility reduction.
1. The Async Post-Mortem
Most post-mortems don’t need a meeting. They need a document. Write the timeline, the root cause, the action items. Share it. Let people comment asynchronously. Reserve the live meeting for cases where there’s genuine disagreement about the fix.
I started doing this two years ago. Saved roughly 3 hours a week. Nobody complained. Several people thanked me.
2. The Office Hours Model
Instead of being available for “quick syncs” all day, block two hours for office hours. “Need my input? Come between 2-4pm Tuesday and Thursday.” Outside those hours, I’m heads-down. Slack messages get a response within 4 hours, not 4 minutes.
This feels rude until you realize that every senior engineer at a company like Google does exactly this. They just don’t announce it.
3. The 1-Page RFC
Half the planning meetings exist because nobody wrote down what they want to build. A 1-page RFC — problem, proposed solution, tradeoffs, timeline — kills 3 meetings. Write it before the meeting gets scheduled. Share it. Cancel the meeting. “I think the RFC covers it. Drop comments if anything’s unclear.”
4. Protect Your First 2 Hours
No meetings before 10:30. Not negotiable. Those first morning hours are when your brain is sharpest. Using them for standups is like using a surgical laser to heat soup.
If your standup is at 9am, that’s not a standup. That’s a productivity assassination. Push for async standups (Slack bots work fine) or at least move it to after lunch when everyone’s already in low-focus mode.
5. Make the Work Visible Without Meetings
The root cause of TalkOps is invisible work. Fix the visibility problem and you fix the meeting problem.
Weekly automated reports. Dashboards in shared channels. Monthly “here’s what platform eng shipped” newsletters. Make the work visible on your terms, in your format, on your schedule. If people can see what you’re doing, they stop scheduling meetings to ask.
The Real Output
Every hour you reclaim from TalkOps is an hour you can spend on actual reliability work. Or actual side project work. Or actual thinking, which is the scarcest resource in any engineering organization.
The r/devops thread had a comment that stuck with me: “By the time I get a quiet hour, I’m already drained.”
That’s not a scheduling problem. That’s a systems problem. And if there’s one thing SREs should be good at, it’s fixing systems.
Start with your own calendar.