How do I optimize my sacred hour at work?

• Can you block 2-3 days each week where you block your calendar in the mornings for "focus time"? You should expect the other days to be jammed with meetings, but that's probably ok (and perhaps even better).
• Could you create 1 or 2 weeks each half which are declared as "no meeting weeks"?

For both of the above, you'll get more buy-in broadly if you first talk individually to others on the team (especially if there are others on the west coast) and then coordinate the days/weeks which are focus blocks.

Few more suggestion which are "out of the box":

• Can you work on weekend mornings? Maybe take off early on Friday afternoons and then work Saturday mornings.
• Can you emulate the environment in mornings in the late afternoon, when your team is actually not working? Maybe trick your brain into thinking it's morning by going for a run, taking a nap, having coffee, etc.

I actually was in a very similar scenario back at Instagram. I was a tech lead working on a big XFN project as part of the Menlo Park office (West Coast) and the primary partner team was in Meta London and we had some collaborators being on the East Coast (Meta NY) as well. It will be difficult for you to shift the meetings given how the time zones work, so my main piece of advice is to reduce the meeting load as much as possible. Here are my tactics/thoughts there:

• The incentives align - The morning meetings will be stressful for both you and the European teams as they're in the early morning for you and pretty late for them (after 5PM). It's in multiple parties' interest to not do the meetings if possible, not just yours.
• Maintain an ultra-high quality source of truth doc - For me, we had a Master Quip (Google Doc/Notion competitor) that I spent a lot of time writing and maintaining. The maintenance part is hard and often forgotten, but this not-so-glamorous work is necessary to prevent people from needing a meeting or noisy DMs to get some question answered. For an example of what this should look like, check out my System Design series: System Design Masterclass: Taro Playlists
• Get into the habit of writing async updates - This can be either daily in a standup style or weekly through Workplace/Slack/Teams (I recommend weekly, but you may need something more often as a startup). Here's an in-depth breakdown of what a good project update looks like: "How to get more visibility on work?"
• Be nimble - This is something you and your teammates should be naturally good at anyways, since you work in an earlier stage startup. You don't need to follow some strict process all the time - You can always switch things up. This was the case for my workstream: When the project was stable and going well, we only met once a week. However, there was a time when things went south and there was a mission-critical regression we couldn't solve. We quickly went into a "situation room" mode and did daily stand-ups to stay in sync better and debug faster. After we solved the issue, we went back to a weekly model. Try decreasing the meeting load, and if things go poorly due to poor alignment, you can always bring them back.

Wrapping this all up at a high-level:

• Minimize hard process as much as possible, especially given the distributed nature of your team which makes process expensive
• Be very diligent about leaving high-quality artifacts and paper trails, so people can work as independently and efficiently as possible
• Stay on your toes and adjust accordingly as things change

This is pretty much how we ran all of our projects back at Meta (Meta has a lot of startup culture still within it, which is a big reason why Meta is successful). It worked very well and was very pro-engineer, letting folks have the autonomy they need to really get stuff done.

I agree with what Alex said about written documentation. Maybe you can bring this issue up (constructively) in a 1-1 with your manager. If the meetings are small & recurring, I would also reach out to the individual participants and see if they’re open to moving the meetings.