Been in both IC, TL, and EM positions. The TL in abstract fills the gap between the collective ICs and the EM. If you have no EM, you are the EM. Here's a bit o

Been in both IC, TL, and EM positions. The TL in abstract fills the gap between the collective ICs and the EM. If you have no EM, you are the EM. Here's a bit of a brain dump. It starts in planning and other ceremonies. From those meetings, you should leave with everyone understanding what they will be working on and you understanding everything that will be done in total during the next few weeks. You should be preparing for these meetings with sorting and filtering the queue of tasks. Then you should be fleshing out the tickets as a team. Over time, the team can also make sorting/filtering decisions. You should also make sure any gaps are filled during 1:1s and check in with everyone to make sure they have a reasonable plan. As time passes and people mature, you can relax these touch points. Other than that, you should be plugged in to all work streams from your team. This requires public conversations and sharing status before too much time is wasted. So you should encourage everyone in your team to ask the team for help if it takes >20 mins being stuck on anything. By the end of standup you should know what everyone will be doing today. You should also be able to predict some of the places people will be stuck and expect to be asked about them. Pairing people up on mini projects is a good way to keep productivity up and get people to become comfortable asking for help and helping one another. This is crucial since you don't want to be the only person answering things. You should be talking to EM weekly and ICs biweekly in 1:1 formats. Those should have a mix of prepared topics and random ones. Beyond that, I would schedule pairing time weekly to work on something and round robin invite people to it. This was a good way to understand where folks are strong and to rub off on them in good ways. For example during an early session, I found one of my engineers lacked deeper knowledge of the language. So the following session with her was planned to coincide with a task that leaned on that and we paired on it. Sometimes it was a task I chose. I often would bring up the thought in 1:1s and mention that we have a pairing session coming up and give ICs the option to bring something they want to work on. All of this gets you to people working properly and learning/growing. The goal is to rely on ICs for what they can do and continuously expand what they can do. If you know what to build and have clear line of sight, this is enough. Beyond that your job is also to contribute at a company/organization level to larger initiatives and get alignment on various things. Staying productive is hard. I'd often do sprints where I'm mostly heads down and have no meetings for the first week, but batch a lot of meetings to my second week. Batching meetings is my single biggest tool here to get focus time. I will happily do 2 days of all meetings with the remainder being all large blocks of focus time. Having 2 days worth of meetings peppered into my week kills me. Aside from this, you need some sort of way to manage your work. I would have 3 lists - sorted by importance. I would add to the lists as I go and periodically groom them (different cadence for each list). 1. tiny tasks - anything small; perfect for between meetings; if a task takes 15 mins or less, it's one of these 2. long tasks - anything that takes 1 day or less (so like 5 focused hours?); typically smallish ticketed things, but as tech lead often not always the case 3. long tasks - anything longer than above; often research tasks or exploratory things I limit the length of the lists - different for each list. I would do daily code reviews of everyone's PRs, not necessarily commenting since that can feel overbearing.