Everyone replying seems to be assuming this time is all for standups and status meetings, but in practice it’s probably about half an hour a week for status upd

Everyone replying seems to be assuming this time is all for standups and status meetings, but in practice it’s probably about half an hour a week for status updates for us to. The rest of the time is a mix of reserved time for synchronous technical collaboration (e.g. reserved time for pairing, time to talk about technical architecture at a higher level and for people to opt in to presenting some of their work for feedback) My team skews a bit junior right now, and I generally expect a pretty high degree of autonomy. We’re not a feature factory and people aren’t pulling tickets from a backlog mindlessly- I expect them to understand what they are building, why, talk to users, take ownership of a problem and exercise sound judgement. That requires some coordination. More senior people can handle that with less structure. For a highly competent but less experienced engineer I’ve found asking them to work mostly asynchronously was setting them up for failure. Giving the a bit of structure, making them available to one another to help themselves grow, and giving me more opportunities to recognize when I needed to intervene early has been successful. For some teams it might feel like too many meetings, but that’s why I said that you need to pick what works for the specific team. Don’t cargo cult process and structure, but don’t be afraid of it when it can help either.