[lostcolony]

You seem to have completely ignored my "Communication is necessary, but not the output". Put another way, meetings are the 'how', not the 'what'. The how is not a deliverable, and so can be changed so long as the 'what' stays the same. You can get input, collaborate, etc, in other ways that are not synchronous.

We've all had that "this meeting could have been an email" experience. Make it an email. Start re-evaluating every meeting; any sort of unidirectional informational meeting can be offloaded onto a doc or recorded presentation just as efficiently. Bidirectional decisional meetings can often be done more effectively by writing up a problem statement, the various options, and a 'due' date for input. Allow people to read over it, comment, propose new suggestions, etc, then at that due date, hold a vote (can be done sync or async). Voila, a decision is reached that allowed for greater amounts of discussion, and was arrived at as democratically or 'loudest voice in the room' (if only a select few people's votes count) as you care to have it, rather than whatever organically happens in your meetings. Etc. In my experience what I'm left with are the meetings where it's the 'personal connection' that matters; these are things like the occasional AMA/Town Hall style meetings, and 1-on-1s. 90% of my pre-COVID meetings turned out not to need to be meetings.

[JoeQuery]

I didn't ignore anything. The product is the output. Code is not the output. Your code is as much the output as communication is. Users don't care if you spent your time coding or in a meeting. They care if the product fulfills their needs. A meeting that stops a terrible redesign contributes as much the output as the heads down programmer who would have implemented it. Now I would hate to be in meetings all day, don't get me wrong. But I disagree that code is the output specifically for a product.