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 huge barrier 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.

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:

• Make optional meetings truly optional: 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.

  
  

• Create meeting breaks: 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.

  
  

• Trust is critical: 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.

  
  

• Check-in: 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.

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:

• Be aware of the signals you send: 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.

  
  

• Communicate when you will give people answers: 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:

  
  

  • “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!”

    
    

• Use public channels to communicate when appropriate: 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.

  
  

• Take a vacation: 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.

  
  

Create a safe and fun space

Your teammates must feel safe and heard to do their best work. And studies have shown folks are more productive in a safe environment. And it doesn’t hurt to have a little fun together as well.

Here are some steps you can take

• Ask for feedback and listen: 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.

  
  

• Use retros effectively and delegate action items: 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!

  
  

• Respect different work styles. Everyone works differently, so we create and share User Manuals 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.

  
  

• Add a little fun. 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:

  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:

• Prioritize answering their questions. 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.

  
  

  • 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.

    
    

• Pairing is caring. 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.

  
  

• Spend extra time reviewing their first few pull requests. 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.

  
  

• Delegate. 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.

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:

• Changed Retro format. 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:

  • What went well?

  • What could have gone better?

  • What do we want to try?

  • What puzzles us?

    
    

• Added a rotational ‘Goalie’ system. 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.

  
  

• Created a weekly pair hour.  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.

  
  

• Defined ‘Sprint Goals’.  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.

  
  

• Brainstormed new processes. We use collaborative tools like Figjam to assist in brainstorming exercises. For example, we did an exercise called Crazy Eights to talk about our team's relationship with customer success and the bug submittal process.

  
  

  • 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:

• Get outside perspectives. 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.

  
  

• Review other teams’ implementation specs. This can be a great time to ask questions or see how their next project might affect your own.

  
  

• Utilize public channels. 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.

  
  

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.