1. Daily, but you may need to touch base multiple times a day as needed for struggling teammates or highly time-sensitive situations. The best thing you can do for a well-functioning team is make sure they have what they need (including well-defined and up-to-date goals) and then get out of their way, but for orgs that structure teams around leads, your responsibility is progress (whether this is a good tactic or not is debatable). Not being able to answer for where your team is at and not catching obstacles (anything from technical issues to gold plating or even sandbagging) before they get out of hand is your primary responsibility. You’ll have to figure out the balance and particulars with your team, and I think devs will feel less disrupted and stressed out if you set expectations up front rather than pester them. For example, if there’s a high priority issue, agree on what you expect them to do and tell them when you’re gonna check in next.
2. I had a weekly 1:1 to go over concerns individually, a weekly meeting between team leads and product to ensure alignment and be apprised of business changes or problems, and an end of week meeting with other tech leads to coordinate cross cutting concerns. More of that crap you can cut out or strip to the minimum, the better. The weekly 1:1 with my boss seemed to be most important.
3. I generally don’t mind a tight, small and organized daily stand up, and it did mostly help me accomplish #1 (since everyone could schedule around it), but these meetings are very easy to derail and are vulnerable to too many cooks in the kitchen. So that, the aforementioned weeklies, triage meetings, refinement sessions, code reviews, architectural reviews, etc… the meetings stack up fast and were one of the most miserable parts. Some were useful, some were only situationally useful, everything else was navel gazing and micromanaging. I can’t tell you what the right amount or cadence is, but kill anything that doesn’t have a firm agenda, limited attendance, or much value. Do your best to keep your devs out of meetings as much as possible.
4. I’ve never worked at a place with an organized approach, we mostly just figured out what we need as we went. Too much documentation is taking time away from work, plus it all decays as projects progress, but no documentation is worse. I tried to bring documentation into my responsibilities, but would delegate small, focused chunks to team members that did the work. Leverage things like OpenAPI, generated docs, plantuml or equivalent to do C4, ERD, sequence, etc. If you need to delegate documentation, put it in your acceptance criteria or requirements and make sure they can just brain dump and move on (rather than fussing around with what tool to use, etc).
5. I put cards in for all my sprint work, whether it was programming or a placeholder for time spent in meetings. You only have a fixed pool of time, pretending that programming vs meetings vs code reviews vs anything else all come from magic parallel pools just does not work. Anything unexpected that comes along takes time from that pool. If someone wants to add work, something else has to come out, end of story. Block time on your schedule, too, and be confident in saying no if someone tries to sneak more shit in or blow up your plan. Also, make sure it’s clear from your manager what expectations are from dividing your time between leadership tasks and technical work. Give them feedback on how that’s working during 1:1s, gather feedback from your team on how well supported they feel and how well your team is on track, recalculate and feed back into next sprint. I think it’s normal for you to do a lot less technical stuff in terms of day to day, and you have to fight the urge to get down in the dirt if your team needs leadership. I ended at like maybe 20-30% coding except during crunches. I did not enjoy that ratio and ultimately moved into architecture.
6. Well, if you’re doing something like scrum, you should have a plan before you execute each iteration. Everyone should know the priorities and deliverables expected at the end of it, and should have been able to have a say on whether it’s doable, clear, and you have everything you need. That time is your opportunity to look at all the work and figure out approx. how long it should take to get each thing done (comparing a task to similar historical work and using that as a rough estimate for how long it will take can help you here… building a rubric for your team to guide you here is a good idea). The rest of the sprint is you gauging where everything is at at least daily. Stand ups are supposed to take care of that. If you feel like there is a risk of something falling off, that’s your priority to get back on track or adjust expectations (last minute changes to the sprint should be avoided if at all possible, though). Then you’re supposed to measure how you performed the last iteration against expectations, figure out how to improve, and you feed that into next iteration. There’s a lot of watching cards in their swim lanes and activity in source control (or lack thereof) and reaching out to people when you are concerned.
The TL;DNR is a lot of planning, just enough communication, and being the glue to keep everything together.