Most engineering meetings unfold like a bad play nobody bought tickets for. First, someone drops a 60-minute block on your calendar called “Sync on Q3 deliverables” and you feel a little piece of your soul detach. Then twelve people shuffle into a room or a Zoom grid, and the opening seven minutes vanish while Dave hunts for the right dongle. Finally, you stumble out knowing less than when you walked in, and your IDE glares at you from the screen like a disappointed parent. I’m Fritz Muller. I’ve clocked fifteen years watching smart engineers perfect the thousand-yard stare under flickering fluorescent lights. The meeting isn’t the villain here—lousy process is. Let’s talk about how to run one that doesn’t treat builders like furniture.
The Default Meeting Is a Bug, Not a Feature
Let’s not kid ourselves: most calendar invites are panic attacks dressed up in Outlook. Somebody realizes they need three decisions, has no clue who owns them, and invites half the engineering org as a comfort blanket. You end up with a roomful of expensive brains silently toting up the context-switching tax. Yank a developer into a 30-minute meeting and you’ve probably incinerated a full hour of flow. The research on programmer productivity backs this up, and it’s not subtle. If your meeting lacks a clear outcome, you’re not collaborating—you’re just burning payroll in real time.
The fix starts before you even touch the scheduling tool. Frame your agenda as a list of decisions to be made, not “topics for discussion.” Can’t name at least two concrete outcomes? Delete the invite. Fire off a pre-read—three bullet points, tops—so nobody walks in cold. And for God’s sake, use the “required” versus “optional” attendee fields like an adult. Every optional body you drag into that room is another person silently composing your villain origin story.
Who Actually Needs to Be There?
I’ve witnessed standups with eighteen people. Eighteen. That’s not a standup; it’s a hostage situation with sticky notes. Here’s the rule: if someone’s presence won’t directly change the outcome, don’t invite them. Send them the notes instead. Decision-makers and the people doing the actual work are mandatory. Everyone else is a tourist, and tourists derail conversations with context-free questions because they don’t know the terrain. Stop letting tourists buy tickets to your meetings.
There’s a special circle of developer hell reserved for people who invite engineers “just to listen.” No. Just no. If you need an engineer to listen, record the damn thing and send a timestamped summary. Their time is better spent wrangling a compiler, and you know it. Deep down, you absolutely know it.
Start Like You Mean It
First five minutes: name the decision that needs to be made, the constraints, and who owns the final call. This isn’t a TED talk; spare us the throat-clearing. If you’re facilitating, your job is benevolent dictator, not everyone’s buddy. Cut off the ramblers. If someone’s been muted or silent for ten minutes, they’ve either checked out or they’re fixing a prod bug under the table—pull them in or cut them loose.
Timebox everything. I don’t care if the CTO is waxing poetic about horizontal scaling; when the clock hits zero, you move. Use a visible timer. It’s not rude—it’s basic respect. The engineer in the corner with a deadline in three hours will mentally send you a thank-you note.
The Agenda That Actually Works
Here’s my template. Take it, tweak it, pretend you invented it:
- 0:00-0:05: Decision to be made and why it matters. No context firehose, just the stakes.
- 0:05-0:15: Options and trade-offs. No solutioning yet—just “here’s what we could do and what it would cost.”
- 0:15-0:25: Discussion. Only people with skin in the game speak. If you’re repeating yourself, sit down.
- 0:25-0:30: Decision and owner. Who does what by when. That’s the whole enchilada.
If you can’t wrap the decision in 30 minutes, the issue isn’t the clock—it’s that you skimped on the pre-work. Slice it into smaller decisions or book a follow-up for the one dangling thread. Never, ever let a meeting slosh past its end time because “we’re so close.” Close isn’t a decision. Close is a vibe, and vibes don’t merge pull requests.
Kill the Status Update Meeting
Status updates should be async. Full stop. If your team needs a weekly circle where everyone recites a miniature diary entry, you’ve got a management failure, not a collaboration gap. Use a shared doc, a Slack channel, or a project board. If someone hits a blocker, they can yank the relevant people into a 15-minute huddle. The standup isn’t group therapy; it’s a coordination checkpoint, and it should die the instant it becomes a verbal status report.
I once parachuted into a startup that hosted a two-hour, all-hands engineering meeting every Monday. Two hours. Fifty engineers. The first hour was project leads reading slides that had already landed in everyone’s inbox the night before. The second hour was “Q&A,” which was really just two architects relitigating a database schema from a project that got shelved six months prior. We axed the meeting, shoved updates into a Loom channel, and handed engineers back something like 100 collective hours a week. Productivity ticked up, sure, but the real win was that people stopped looking like they needed a sick day by Tuesday morning.
Remote Meetings Are Worse (Unless You Fix Them)
Remote meetings take every bad habit and put it on a highlight reel. The “quick question” that inhales ten minutes. The person on mute who’s clearly unloading a dishwasher. The screen share that accidentally flashes seventeen open tabs, including a Reddit thread on lawn care. Rule one: cameras on for decision meetings, optional for info dumps. Yes, it’s tiring, but non-verbal cues matter when you’re hashing out an architecture call. Rule two: use a digital whiteboard or a shared doc everyone can see and scribble on. If I can’t see what you’re pointing at, I just assume you’re ad-libbing.
And please, for the love of decent audio, test your rig beforehand. The first five minutes of a remote meeting should not be a symphony of “Can you hear me?” and “My VPN is throwing a tantrum.” If you’re running the thing, join five minutes early and drop the agenda link in chat. If you’re an attendee, do the same or brace for my side-eye through the screen.
Decisions Over Discussion: The Engineer’s Creed
Engineers are trained to chase problems down rabbit holes, which means they’ll happily optimize a meeting into a black hole of edge-case spelunking. Your job as facilitator is to stop that. When someone says, “Well, what about if the user is on a 3G connection, in a tunnel, during a solar flare?”, you say, “That’s an edge case. We’ll document it and deal with it if it actually happens. Next.” The goal is a decision, not a mathematical proof.
This is where engineering culture gnaws its own leg off. We worship thoroughness, so we let meetings morph into deep-dives that scratch the curiosity of two senior engineers while the other six people question their life choices. Save the deep-dive for a design review. A decision meeting is for picking a path and assigning the work. If you need a deep-dive, schedule it separately and only invite the folks who’ll touch the code.
When to Actually Have a Meeting
Run this checklist before you even think about sending the invite:
- Does this need real-time, back-and-forth talk? If it’s one-way info, send an email.
- Is the decision so urgent and tangled that async would cause real delay? If not, use a doc.
- Do you need simultaneous input from several people? If it’s just two people, hop on a call—don’t drag a room into it.
- Can you state the desired outcome in one plain sentence? If no, you’re not ready.
Nine times out of ten, the meeting could’ve been a well-structured document. That tenth time, it should clock in at 30 minutes or less, with a hard stop and a named owner. If you can’t manage that, you’re not facilitating a meeting; you’re performing a ritual, and rituals don’t ship software.
The Follow-Up That Prevents the Next Meeting
A meeting without a written summary is just a chat that evaporates by lunch. Within an hour, fire off an email or Slack message that covers: the decision that got made, who’s doing what by when, and any open questions you tabled. No more than five sentences. If you can’t boil it down to five sentences, the meeting was a mess, and you need to tighten it up next time.
That summary also doubles as your accountability receipt. I’ve watched teams re-litigate the same decision across three consecutive meetings because nobody bothered to write it down. That’s not collaboration; that’s a memory leak. Write it down, pin it somewhere visible, and if someone tries to reopen it without fresh data, you can politely point to the record and suggest they go write some code instead.
FAQ: Meeting Survival for Engineers
Q: What if my manager insists on daily standups that are just status reports?
A: Pitch a one-week trial of async standups in a Slack channel. Show them the reclaimed time. If they push back, ask what information the live standup delivers that a written update can’t. Often, the standup is a security blanket for anxious managers. Gently suggest a 15-minute, twice-weekly sync instead and use the freed-up time to actually build things. If that fails, accept that some hills aren’t worth dying on and use the standup block to mentally refactor your codebase.
Q: How do I handle the person who always derails meetings with tangents?
A: Deploy a parking lot. At the top of the meeting, point to a spot—physical or digital—where off-topic ideas go to wait. When someone veers off, say, “Good point. Let’s toss it in the parking lot and circle back if we have time.” You won’t have time, and they’ll eventually get the hint. If they don’t, pull them aside privately. “Your tangents are burning about $400 in productivity per meeting. Mind saving the deep musings for the design doc?”
Q: Is it ever okay to code during a meeting?
A: Only if the meeting is genuinely irrelevant to you and your attendance was forced. But honestly, it’s better to decline the invite or ask if you can drop. If you’re coding with one ear half-open, you’re neither coding well nor listening well—you’re just putting on a multitasking puppet show. Be straight with your manager: “I can’t add value here, and I’ve got a critical bug breathing down my neck. Can I catch the notes afterward?” A decent manager will say yes. A bad one will make you sit there, and in that case, you have my blessing to quietly noodle on that neglected side project.
Q: What’s the ideal meeting size for a decision meeting?
A: Jeff Bezos had the two-pizza rule—if two pizzas can’t feed the group, it’s too big. I’d tighten that further: five people max for a decision meeting. One decision-maker, one facilitator, and up to three domain experts. Any more and you’re in town-hall territory, where the loudest voice wins and the quietest engineer mentally checks out. If you need wider input, gather it beforehand and bring the synthesis to the table.
Meetings aren’t the enemy of engineering culture. Unstructured, bloated, ego-driven meetings are. Treat a meeting like you’d treat a code review: be precise, be brutal about waste, and always, always demand a clear output. Your colleagues’ time is the priciest resource your company has. Spend it like you would a capped AWS budget—with an actual plan and a hard limit. Now go delete something from your calendar and write some code.
