It's important to understand that that when you're a tech lead, your first priority is the productivity of your teammates, not your own productivity. You're responsible for the output of the team as a whole, and if that means you do zero coding, so be it.

You should also be coming up with good ways to use productivity tools asynchronously. But remember that the natural impulse for many employees will be "Oh, the boss is busy, I better not disturb him. Guess I can't do any work until then!" You need to make sure that whatever communication mechanisms you agree on have buy-in from the rest of the team, and that they'll be comfortable interrupting you if they're really blocked and unable to get work done.

This. As a relatively new technical lead I'm finding myself coding less and less because of these sorts of things. I don't enjoy that aspect but at the end of the day what my job really is is to make the rest of the team as productive as they can

Ideally, upward, downward and lateral communication channels have people on both ends who are sensitive to issues created by timing. One of the roles of a leader in some organizations is to model desired behavior and develop productive habits throughout the team.

Since there are many more lateral communication channels within a team and there is an aspect of being a technical lead that is being a peer to the team's members [and not "the boss"], there is more productivity to be gained when all team members communicate in ways that reflect awareness of the state of the communication channel from the other person's perspective.

The problem with the internet text boxes is that complex human interactions get sketched and lose important details.

The second most important thing is to make sure the guy with the checkbook agrees with this. Worked myself out of a job once by not doing that, not on my timeline.

Actually both leads did the same thing, and I have no idea how they solved deep technical problems after that since the two of us were handling 75% of them... Here were two expensive Devs not getting features done as fast as anybody else. Look at all the money I saved!

I wouldn't recommend this. I have over 15 years as lead dev experience, and this isn't good advice. This tells your team that your time is more valuable than their contribution. No matter how good you are, you can't do as much as your team if they are properly guided, supported, and motivated.

OP's most important point is that when you're talking to team members, you ask them if it's a good time. Ideally, they'll take that as leading by example and hopefully they'll catch on.

Your flow is not important, theirs is.

In any leadership role you are more like a janitor than a hero. You have to clean up the messes, keep the bathrooms supplied, fix the broken things.

Either train yourself to cope with breaks in the flow, or get used to doing less coding.