It’s 4:47pm on a Thursday. I’m halfway through a problem that’s been bugging me since Monday, and I can feel the shape of the solution forming. My brain is doing that thing where all the pieces are slowly rotating into alignment. Ten more minutes and I’ll have it.
My calendar pings. “Urgent sync — can we jump on a call in 15?”
I know what’s going to happen. We’ll spend 30 minutes talking through something that could have been a one-page document. By the time the call ends, I’ll have lost the thread of what I was working on. I’ll spend Friday morning trying to remember where I was. And nobody, including me, will remember what we actually decided on that call by Monday.
I join the call anyway, because I’m a professional. But I’m not happy about it.
If your meeting doesn’t have an agenda, a document, or a decision to make, it’s not a meeting. It’s an interruption with a calendar invite.
The tension nobody talks about honestly
There’s a fundamental tension between engineering and product that most companies pretend doesn’t exist. It goes something like this:
Engineering needs deep focus. Writing code, debugging systems, designing architecture, these are activities that require sustained concentration. Context-switching is expensive. Every interruption costs you not just the time of the interruption itself, but the 20-30 minutes it takes to get back into the zone afterwards [1]. Engineers know this in their bones, which is why they get twitchy when someone says “quick call?”
Product needs to talk things through. Product managers, project managers, and designers often think by talking. They need to bounce ideas, test assumptions, hear reactions in real time. For them, a conversation IS the work. A document sitting in a Google Doc feels slow and disconnected. They want feedback now, not in 48 hours.
Neither of these is wrong. That’s what makes it so frustrating. Both teams are doing their jobs the way their jobs need to be done. The problem is that these two working styles are fundamentally incompatible if you don’t manage the tension deliberately.
The Thursday 5pm problem
I should name and shame myself here, because I’ve been on both sides of this.
I’ve been the engineer who silently fumes through a late-afternoon call, contributing nothing useful because my brain checked out at “can everyone see my screen?” I’ve sat through meetings where five people spent 40 minutes discussing something that one person could have written up in 15, circulated for comments, and resolved async by the next morning.
But I’ve also been the CTO who pulled someone into an “urgent” call because I was anxious about a deadline and wanted reassurance, not information. I’ve been the person who scheduled the 5pm Thursday meeting because I ran out of patience and wanted an answer RIGHT NOW instead of waiting for the process to work.
The thing about 5pm on a Thursday is that everyone just wants dinner. Nobody is doing their best thinking. Nobody is going to remember the nuances of what was discussed. And yet, somehow, this is when half of all “urgent” syncs seem to happen. It’s the worst possible time to make decisions, and the most common time people try to make them.
What should be a document
Here’s my rule of thumb: if you need people to review information, form an opinion, or provide detailed feedback, that’s a document. Not a meeting.
Technical decisions. Write an RFC or a decision document. Lay out the options, the trade-offs, the recommendation. Give people time to read it, think about it, and respond thoughtfully. A 30-minute call where you present three options and ask “what do you think?” is almost always worse than a document that people can digest at their own pace.
Status updates. If nobody needs to make a decision, it’s not a meeting. Write it down. A weekly update doc that people can read in five minutes saves an hour-long standup where most people are on mute doing other work anyway.
Feedback requests. “Can you review this?” is a document task, not a meeting task. Send the thing. Give a deadline for comments. If there are disagreements, THEN maybe you need a meeting to resolve them.
The beauty of documents is that they have memory. A document remembers what was decided and why. A meeting remembers nothing unless someone writes it up afterwards, and let’s be honest, how often does that actually happen?
What should be a meeting
Not everything should be async, and this is where the “async-first” crowd sometimes gets it wrong. Some things genuinely need a synchronous conversation:
Conflict resolution. If two people disagree and it’s getting tense in a Slack thread, stop typing and get on a call. Text is terrible for resolving disagreement because you can’t hear tone. What reads as aggressive might have been meant as playful. What reads as dismissive might have been typed in a rush. A 10-minute call can resolve what a 50-message thread will only make worse.
Brainstorming with constraints. When you need to generate ideas quickly within a specific box, real-time conversation is faster. The energy of people riffing off each other is genuinely valuable and hard to replicate async.
Sensitive conversations. Anything involving someone’s performance, role, career, or feelings. Never async. Never in writing first. Voice at minimum, video if possible.
The actual decision point. After the document has circulated, after people have commented, after the options are clear, sometimes you need 15 minutes of synchronous time to actually commit. “We’ve all read the RFC, we’ve got two viable options, let’s pick one.” That’s a meeting. A short one.
The product-engineering peace treaty
Here’s where I want to be constructive rather than just venting about my Thursday evenings.
The companies that get this right seem to have something in common: they create structured touchpoints that give product the real-time conversation they need without destroying engineering’s focus time.
I think about Apple a lot when I think about this tension. Whatever you think of their culture, they shipped the iPod and the iPhone, which means at some point, engineering and product figured out how to work together without one side strangling the other. I’d love to know the secret sauce, but from the outside it looks like very clear boundaries around who decides what and when.
For my own team, here’s what I’ve been experimenting with:
Designated collaboration windows. Mornings are for deep work. Afternoons are for meetings. Product knows that if they need engineering input, the afternoon slots are available. Engineers know that their mornings are protected. It’s not perfect, but it’s better than the free-for-all.
The “write it first” rule. Before requesting a meeting, write down what you want to discuss and what decision needs to be made. If you can’t write it down, you’re not ready for a meeting. If you can write it down, maybe you don’t need the meeting at all.
The 24-hour buffer. No meetings on less than 24 hours notice unless something is genuinely on fire. And “the client asked a question” is not on fire. “Production is down” is on fire. Learning to tell the difference is a skill that takes practice.
Decision logs. Every meeting that results in a decision gets a one-paragraph summary in a shared doc within the hour. Who decided what, and why. This is the thing that saves you from the “wait, what did we agree?” conversation the following week.
The bit I’m still working on
I haven’t cracked the patience problem. I still sometimes feel the urge to pull someone into a call because I want an answer now. And I know, rationally, that waiting 24 hours for a thoughtful written response is better than getting an off-the-cuff answer on a surprise call. But knowing it and feeling it are different things.
The product people I work with aren’t wrong to want real-time feedback. Their instinct to talk things through is valid. The challenge is channelling that instinct into the right moments rather than letting it eat into everyone else’s focus time.
If you’re a product manager reading this, I’m not having a go at you. I’m having a go at the system that never taught either of us how to work together properly. The tension between “I need to think” and “I need to talk” is real, and the answer isn’t one side winning. It’s both sides learning when to do which.
And if you’re an engineer reading this, maybe don’t schedule your most critical deep work for 4:47pm on a Thursday. That one’s on me.