I've gone in the opposite direction: on projects I've led, I decided to have no recurring meetings at all, very much going against the flow of the broader organization. Instead, I would set up a time when we had something specific to talk about. I wrote a short but hopefully clear description of what we needed to cover on each event that I scheduled. I found this worked really well in practice. We actually talked mor…
I really prefer this over recurring meetings. The gist of it is that you're communicating early and often when you can't solve things in isolation, avoiding putting things off or letting understandings of problems atrophy while you wait. Ironically, I do this most with my remote coworkers. They're amazing. The coworkers I have in office are much less keen to give up time for communication. They're great too, in other ways, but harder to communicate with.
Your point about shared mental models is huge. Ironing these things out with another person is invaluable, but having more than one person do it at once means it's multiplied across the team. So many people we work with are building this model in isolation with LLMs, and I'm certain it's harming our collective grasp on what it is that we're actually doing. Very strange times!
It has never seemed more important for humans to communicate with each other and have these shared mental models. To simplify rather than add complexity, to cultivate that meat-space context that gives software purpose in the first place, to understand that purpose, and so on. Interacting with each other fluidly and regularly is such a great way to make that a reality.