What I've Learned in My First Year as a Software Engineering Team Lead

In January 2022, Kojo (then Agora) was rapidly growing, from a company with three engineering teams to six. I was given the opportunity to lead the Field team, which has since grown and changed to the Core Product team, covering our main product offerings. It’s been a year in that role (called either Team Lead/Tech Lead, or TL), so I wanted to share what I’ve learned. I’ve also included actionable steps to put this advice into practice. For reference, my team consisted of the TL (me), 3-4 other Software Engineers, a Product Manager, and a Designer. Like many new startups, we are a remote-first company, which can present some unique challenges around communication and team culture. However, the tips I have learned for how to combat these challenges can be applied in the office as well. Protect your engineers’ time We know that constant interruptions are a to deep thinking and concentration. Therefore, one of the most important things you can do as a TL is protect the time of your engineers so they can be productive. You act as a shield, taking high-level meetings, sorting out priorities, and navigating cross-functionally so that your engineers can stay focused on writing and reviewing code. huge barrier A good TL can be measured by how much uninterrupted time the engineers have on their team to do deep thinking and problem-solving. Here are some tips to minimize distractions for your team: Set the expectation that if you mark someone as optional, you truly mean optional. Add clear meeting descriptions/agendas so folks can determine if it’s worth their time. Make optional meetings truly optional: : Try blocks like a ‘No Meeting Wednesday’ to give people reliable blocks of time that they can use to work through difficult problems. I find a full day works best because half days start to slowly get ignored. Create meeting breaks Be transparent about the decisions you make and why. With your team’s trust, they won’t feel the need to come to as many meetings because they will know you have it handled. Trust is critical: Use 1:1s and retros effectively to gauge how people on your team are feeling and be humble enough to take constructive feedback. How you respond to feedback is critical to creating a positive and productive work environment. Check-in: Lead by example Your personal working style will set the tone for your teammates, whether intentional or not. Here are some tips to create a good working culture: If you are working late and sending messages at 9 pm, your engineers will feel pressure to respond or match your hours. Use scheduled messaging and reminders to encourage healthy work/ life balance and boundaries. Schedule a message for 9 am the next morning rather than sending it at 8 pm if you are working late. Be aware of the signals you send: You can’t always respond thoughtfully at the moment, if you don’t respond at all, you leave people feeling anxious (should I follow up? Did they get my message? Was that a stupid question?). You always have time to send a quick holder message like: Communicate when you will give people answers: “Great question! I’ll respond to this in 2 hours after my meetings” “I saw your PR, I’ll take a look first thing tomorrow morning!” Having a shared set of knowledge helps with a united culture, but also ensures that everyone is on the same page. It can also be a great way to collaborate, knowledge share, and help newer folks on the team get the context they need to onboard quickly. Use public channels to communicate when appropriate: If you don’t demonstrate that vacation is expected and appropriate, everyone on your team will feel less comfortable taking theirs. A positive work culture can start with you. Take a vacation: Create a safe and fun space Your teammates must feel safe and heard to do their best work. And . And it doesn’t hurt to have a little fun together as well. studies have shown folks are more productive in a safe environment Here are some steps you can take I have 1:1s with my engineers every 2 weeks, even though I’m not their manager. This can be time to see where processes are failing and improve, help them with a problem, or just connect on a personal level. Ask for feedback and listen: Use past sprints as examples and see where you can improve. Be honest about what didn't go well, and discuss clear next steps or experiments to try a new process. You don’t have to take on all the action items yourself - delegate! Use retros effectively and delegate action items: . Everyone works differently, so we create and share to let our teammates know how to best work with us. This can be everything from “I’m a morning person” to specific work pet peeves. Respect different work styles User Manuals After our weekly Retro, we have 30mins dedicated to an optional ‘Gameday’, where we play a fun online game together. Think Jackbox games, or of our team favorites: Add a little fun. Garctic phone. Remote bonding can be challenging, but I find having a game or a structure of some kind helps to make sure everyone can participate comfortably, and minimize awkwardness. Prioritize effective onboarding When a new engineer joins your team, you will often be the point of contact for onboarding. The faster this new hire ramps up, the faster your life will get easier so it’s worth thinking carefully about how to best prepare them for the new team. Things to consider include: Make sure you carve out time in your schedule during the first few weeks of a new teammate to dedicate to their questions and onboarding. You want them to feel safe asking you their “stupid questions” so they don’t waste unnecessary time. Prioritize answering their questions. Sometimes their questions are useful for your whole team, so you can sometimes encourage them to share their questions on the team channel. Just make sure they know they can also ping you separately if they aren’t comfortable. Pair with them both what they are working on (of course), but also what you are working on. Pairing is a two-way street, and seeing how you work helps them quickly find the tips and tricks of your system. Pairing is caring. The earlier you can give tips on best practices and codebase patterns, the better. Let them know you are being extra picky for these first few PRs so they aren’t discouraged. Spend extra time reviewing their first few pull requests. While you are leading their onboarding, don’t think that you are the only person responsible. Direct their questions to other folks on your team, encouraging pairing between those folks. This is not only best for your time, but it can be beneficial for getting a diversity of perspectives and approaches as well as building your team culture. Delegate. Try new processes It’s easy to get stuck using the existing processes, even if they aren’t an effective use of time. It’s now your responsibility to iterate and improve. Here are some process changes my team has made over the past year: We now ask folks to fill out 4 questions in advance, so we have more time to discuss the actual sprint. We also added a Notion database of 'Appreciations', where folks can call out other teammates and give kudos. The four retro questions: Changed Retro format. What went well? What could have gone better? What do we want to try? What puzzles us? The “goalie” of the day will be responsible for responding to and delegating the bugs that come to our team. This ensures the work is evenly spread, and no one on the team gets stuck always on bug triage. Added a rotational ‘Goalie’ system. . Every Friday morning for an hour, I hold an optional pair program time where we work on team-wide bugs. The time is optional, but it has become a really helpful way to knowledge share, collaborate, and work through tricky issues. Created a weekly pair hour For each sprint, we now specify a short sprint "goal" to align the team on our biggest focus. For example, if our goal is: "Ship the Exporting Quotes feature," our team knows that PRs related to that feature are a priority to review. Defined ‘Sprint Goals’. We use collaborative tools like to assist in brainstorming exercises. For example, we did an exercise called to talk about our team's relationship with customer success and the bug submittal process. Brainstormed new processes. Figjam Crazy Eights Each team member has 8 minutes to generate 8 ideas, 1 minute each, in a grid Then, each person goes over their ideas, for ~2-3 mins each We group similar items and vote on our favorites. Communication between other teams becomes more important As an IC software engineer, you often live firmly within your team, communicating with the team members the status of your tickets, helping review the team’s code, working on bugs, etc. As the TL, you become a crucial bridge to other teams. You need to have a clear understanding of not just your team, but how you fit in with the broader company goals, and the work of other teams. Here are some practical tips to do that: Ask another team lead to review your teams’ implementation specs. Other team leads may have context around the area of code you are touching that will be important for your success or longevity. Get outside perspectives. This can be a great time to ask questions or see how their next project might affect your own. Review other teams’ implementation specs. Make sure to share updates for shared components in a public channel rather than your team’s channel. If you set a standard for clear communication across teams, it will save you time and money down the road. Utilize public channels. It's been a great year building new features and leading a team at Kojo. Stepping into a TL role is a challenge, and I've made plenty of mistakes along the way, but it's very rewarding.