Don't have full solutions to every question since I had the luxury of leading teams that had more experience (5+ years), so YMMV: 1-3. Try to do more 1-on-1 o

Don't have full solutions to every question since I had the luxury of leading teams that had more experience (5+ years), so YMMV: 1-3. Try to do more 1-on-1 or small group meetings, once per week max. Unless there is a lot of overlap/cross concerns, I found having a big group meeting become "holding court" where one person speaks to the lord (you), while the others sit there waiting (or checking email). Same would go with talking to your manager, try to do more 1-on-1 if possible, or ask if you could submit a quad chart instead of a big holding court meeting. (https://researchservices.cornell.edu/sites/default/files/2019-06/Quad%20chart%20examples.pdf https://researchservices.cornell.edu/sites/default/files/201...) Other than that, if you are comfy with being pinged via Teams/Slack/whatever, that seems to work best for small questions. 4. One thing our org tries to do is have regular rebuild days. That's where you take a base VM/system and rebuild your environment and code by following your own instructions. Best way to catch what you didn't document: modules you forgot you added, environment variables, etc. Basically you want to think about the experience of a new team member or customer who lacks the oral history and institutional knowledge of the project. Once a quarter is fine. 5. Agree to have offline hours where you work on your own tasks - marked on calendars if necessary. 6. Semi-frequent group meetings and rebuild days help here as well. This is where I was luckiest in that the team was more experienced in working together, so there wasn't much shepherding needed.