How to run efficient meetings with engineers

This article is part of the Technical Manager Guide. Everything here comes from the small pile of scars I earned running product teams at mindnow and a few gigs before that. Use what fits, ignore what doesn’t.

---

Back when I was a backend engineer at a fintech, the CTO loved status meetings—Monday, Wednesday, Friday, every single week. Twenty people in a glass room, half of us silently fixing merge conflicts in our heads. I hated those hours (and, if I’m honest, skipped a few). These days I’m the one sending calendar invites, so the hypocrisy stings—but it also forced me to figure out how to keep meetings tolerable for the people on a maker schedule while still giving managers the structure they need.

Across a few hundred meetings—some crisp, some train-wrecks—I’ve found patterns that help. They’re not universal truths; I could be wrong, and a 200-person enterprise might need heavier process. Consider this a field note from a 40-ish-person product shop.

Simple Truth

Any non-trivial project will need meetings—compliance reviews, architecture decisions, roadmap resets. The trick is knowing when a synchronous slot beats an email or Slack thread. Makers optimise for uninterrupted flow; managers optimise for alignment. Those incentives clash, so choose live time sparingly.

I’ve boiled it down to two legitimate reasons to gather people in one (virtual) room:

• You need something only real-time conversation can unlock—conflicting opinions, rapid feedback, the kind of white-board riffing that dies in long email chains.
• Someone else needs something from you and the latency of asynchronous back-and-forth would block real work.

Can the meeting be an email instead?

Ninety percent of “status updates” can. If all you want is to broadcast progress, write it down. Long emails, short Loom videos, a Notion page—anything the team can consume when their compiler finishes.

(Side note: I got this wrong for the first 18 months at mindnow, burning half a Tuesday on show-and-tell sessions that should have been a two-paragraph Confluence post.)

Only relevant people in the meeting

People need to have a purpose

Calendar fatigue is real. I invite only the folks whose voice changes the outcome—decision makers and the specialists they trust. Everyone else gets the notes. The invite itself should spell out why a person is there (“frontend review of auth flow” beats “sync”). Sounds obvious, yet my inbox still sees too many <no subject> events.

Have a moderator

The moderator steers the ship and parks tangents. Two months ago we noticed an issue with a fancy “AI meeting assistant”—it started transcribing, froze, and spammed the chat with error pop-ups. Five minutes of chaos later we ditched it and the human moderator took over, recapping the agenda in plain English. Lesson: tools help until they don’t. A person with authority to say “parking lot, moving on” is non-negotiable.

Have someone to take notes

Memory is lossy. We rotate the note-taker role—no one wants the permanent secretary badge. Some teams swear by automated transcripts (Whisper + GPT, quick and dirty). They’re great for keyword search, less great for whiteboard sketches or gestures, so combine them with manual highlights. And if you hit record, warn people first; privacy laws differ wildly and the fine print isn’t fun to read over coffee.

Preparation and structure

1-1 meetings instead of group meetings

Group calls amplify extroverts. If the goal is coaching, career feedback, or a sensitive architectural gripe, schedule a 30-minute 1-1. You’ll surface more truth and waste fewer engineer-hours. (I’m not entirely sure this scales once you manage five teams, but it works up to two.)

Schedule all meetings on a single day

We bunch meetings on Tuesdays. The rest of the week is for building. Developers know context switching is coming and plan around it. It’s not perfect—emergencies ignore calendars—but productivity bumps enough to keep the habit.

Do the preparations

Vague objectives kill momentum. Draft an agenda, attach docs, and time-box each segment. Send everything a day earlier so attendees can read, comment, and arrive half-decided. For demo-heavy sessions, share annotated screen recordings; transcripts alone miss the visual cues.

Staying on point

Summarize and repeat back what was discussed after each point

The moderator—or sometimes I, when the wheels wobble—repeats decisions aloud: “So we ditch Redis cache v1, migrate to v2 next sprint, and Alice owns the rollout.” People nod, or they don’t, and disagreement surfaces before Slack turns into a flame war.

Have guidelines for your meetings

We keep a short living document: assume positive intent, argue the idea not the person, juniors and seniors get equal speaking time, cameras on if bandwidth allows. Nothing fancy, just guardrails that let people focus on substance instead of pecking order.

Timing

Avoid pre and post lunch meetings

Brains slow down when they’re busy planning shawarma runs—or digesting them. Early morning or late afternoon slots work best for anything that needs real thought.

Be punctual

If we say 08:00, Zoom opens at 08:00. We start. Chronic late-arrivers eventually self-correct (walking into a mid-sentence discussion is awkward enough to fix habits).

Final thoughts

At mindnow we try to cap meetings at roughly 10-20 % of a developer’s week. Anything longer means we’re either stalling or could’ve written a decent memo. The system’s not perfect, but build hours keep climbing, and the complaints channel stays quiet—most weeks.

Curious how you handle meetings? Drop me a line—always keen to steal good ideas.

---

Thanks for reading! Here are some things I think you might like:

• 🛠️ How to be a better technical manager
• 🚀 Founders Guide 2022
• 📚 Q&A for Startup Founders
• 📰 Previous Newsletter Issues