Think about it like this, in many of these meetings you're look at a multivariate problem with very few reference outcomes for any given decision path and you need to come up with a solution that doesn't break the other parts of the system. Sound familiar?
Depending on what kind of decision is made, dozens or hundreds of people will have to change how they work, so the cost is high and in many cases the longer you wait to make a decision the more technical debt you have etc... so time is really a factor because people are already working.
For example we needed to come to some consensus on the RPC format we were going to use because one group used JSON, another Protobuf, another XML and other organizations wanted us to use older complex formats like USMTF and UCI to be interoperable. So do we create anticorruption layers and let everyone just do whatever they want? how do we prioritize our streaming consumers and producers? Should we switch everyone to Avro? Etc... you get the idea.
Perhaps it would be fair to say, it is easier/more natural to spend 12 hours in a day dealing with people that moving bags of coal or solving differential equations.
Those 12 hours could have been spent differently to acheive the same or better results if optimized time management matters but I don't believe they do matter in this case. This person is fueled by the meeting (he leaves the meeting stronger) and by shortening his day he would never fully be in a zone.
Meetings aren't going away, and in most cases these are requirements coming from outside of me or my team. Part of the trick of leadership is deciding what you can say a hard no to and not even engaging, what you need to do a soft no to by taking meetings (sometimes useless) in order to maintain good relationships, and then for things that are important but would cause new work, to do a lot of work at the leadership level ahead of new tasks impacting teams so that you can help them maintain their velocity.
