How to Cut Meetings Without Leaving Your Team in the Dark

Do the math yourself. One hour meeting, ten people in the room. That is not one hour. That is ten hours of work burned in a single room.

And most of the time, the decision that comes out of those ten hours is one sentence. A sentence somebody could have written down in a document in five minutes.

I have been shipping product for 20 years, across Tokopedia, Hijra, Flip, three startups of my own, and now four product teams. One pattern repeats everywhere: the team with the fullest calendar is rarely the team shipping fastest. Usually the opposite.

Meetings are a symptom, not the disease

This is the part people read wrong.

When a team complains about too many meetings, the standard fix is to cut meetings. Trim them to 30 minutes. Declare no-meeting Wednesdays. Two weeks later the meetings are back, sometimes worse.

Why? Because the meeting is only the symptom. The disease is that there is no single obvious place to go find an answer.

If an engineer does not know why a feature exists, they ask in a meeting. If a designer does not know the technical limits, they ask in a meeting. If QA does not know which cases matter, they ask in a meeting. If a stakeholder does not know the status, they request a meeting.

Every one of those questions has the same root: the context lives in someone's head, not in a document.

So as long as the context is still in your head, you can cut meetings all you want and people will find another way to mine your brain. A message at 11pm. A tap on the shoulder. A sudden call.

A meeting is just a queue for retrieving information. If you want the queue shorter, do not manage the queue. Open more counters.

A good spec reduces questions, it does not add pages

This is where the product spec comes in. Not the thick one nobody reads.

I once wrote a beautiful 20 page spec. Full structure, diagrams, every field filled in. And people still asked me basic questions every single day. Because I wrote that document to look complete, not to be read by someone in a hurry.

A good spec is written with one question in mind: if I disappear for two weeks, can people keep working from this document alone?

Three things, minimum.

First, why we are doing this. Not "improve engagement," but a real number you are trying to move, from where to where. When I worked on identity at Tokopedia, the target was explicit: install to register from 35% to 59%, register to verified from 30% to 77%. Everyone on the team could see the scoreboard.

Second, the boundaries. What you are deliberately not building in this version. This is the section people skip most, and it saves the most time. A large share of long meetings is people arguing about something you already decided not to do, and never wrote down.

Third, decisions already made and the reasoning behind them. Not just the outcome. The reasoning. Because three weeks from now, somebody new will ask why you did not just do it another way. If the reasoning is written, they read it and move on. If it is not, you spend another hour replaying the same debate.

One extra rule I hold to: the document is alive. Every new decision that shows up in chat or on a call goes back into the document. Otherwise, two months later the document is lying, and people stop trusting it. The moment people stop trusting the document, the meetings come back.

Async is not slow, it gives people room to think

There is a fair fear about cutting meetings: that everything gets slower, that decisions float in a thread for days.

My experience is the opposite, as long as the rules are clear.

When I led the account integration between Tokopedia and Gojek, it was a large project spanning many teams. Three month target, finished in one month. There is no way something that size runs on meetings. If every decision has to pass through a room, you burn your time matching calendars.

What made it work was not more meetings. It was that everyone knew where to find answers, and who was allowed to decide what without asking.

Three things make async actually work.

One, every written request asks for something specific. Not "please review." Instead: "I need your call on point 3 before Thursday. No reply and I proceed with option A." A clear default makes silence a safe answer instead of a dead end.

Two, every decision has a name on it. One person, not "the team." A decision with no owner automatically becomes a meeting agenda item.

Three, meetings still exist, but they get promoted. Reserve them for three things: debates that genuinely need tone of voice, bad news, and moments where people need to know each other as humans. Everything else gets written.

The side effect I like most: people who think slowly and deeply finally get room. In a meeting, the fastest talker usually wins. In a document, the clearest thinker wins. Those are very different things.

If the PM will not lead this, nobody will

Here is the uncomfortable part.

Meeting culture does not change from the bottom. An engineer cannot decline a director's invite. A designer cannot tell a stakeholder to go write it down. The person positioned to make that call is the PM.

And PMs are often the most reluctant, because meetings look like work. A full calendar feels like importance.

Making companies more efficient is an old habit of mine, long before AI was trendy: $4 million and up per year from a mix of initiatives, from process fixes to cost optimization to product decisions that simply wasted less. The pattern was always the same. Someone had to sit down, write things out, and trace where the resources were leaking. Your team's time is the most expensive resource you have and the one that leaks most quietly, because no invoice arrives for it each month.

Back then that kind of leverage required a title, an engineering team, and expensive systems. Now AI is the sharpest tool for the same habit, and it can be taught to everyone on the team.

My closest example: the 8 channel content distribution system I built and run by myself. One long video gets cut automatically, spreads across eight channels, and reports to me daily. I review and approve. Work that used to need a whole team now runs with zero coordination meetings.

Starting is easy. Pick one recurring meeting next week. The one you attend most often and that produces decisions least often. Replace it with one short document you update weekly.

If nobody has lost context a week later, you have just found out how many hours were burning for nothing.

If you want to learn how to think and build systems like this for your own work, I go through it regularly with people inside AI Circle. If you run a team or a company and want to shift the culture together, there is a path for that on the corporate page.