Leading engineering teams
In the past 18 months I've been privileged to work as Technical Lead of some very talented software engineers in a complex organisation with lots of moving parts. In addition to having fun building products that are technically interesting, I have found a lot of joy in working with people and helping my engineering team progress along their professional journeys in the little way I can. I've worn the Technical Lead hat for nearly 5 years now in a variety of settings and companies.
Here are a few things I will keep doing as I get along in my career and as I continue learning to inspire people.
It is important to create a safe space where people feel comfortable expressing themselves in a manner that works for them. Understand that people are different and might require different approaches. Some people are shy, some are more energetic and some might not be empathetic enough to understand the perspective of others.
Encourage ownership of processes and solutions especially in line with stretch goals for the different members of the team. It is important to be ready to provide support through the process of achieving those stretch goals whilst allowing for room to make mistakes. Allowing engineers to anchor activities or lead the process for finding technical solutions helps with the sense of ownership and growth.
Learning in public
I'm a strong advocate of well crafted questions and I encourage it in my teams. I also encourage posing questions in spaces that are accessible to a wide group so that the solutions are shared across teams and others can learn from it. It is a lot easier to get younger folks to align with this mentality and it might be tougher to get more senior folks on board. My strategy for this is mainly leading by example. I ask questions publicly (even trivial sounding questions). When in the context of digital spaces like microsoft teams, slack or google chat I'd tag a team member who might initially have reservations about asking questions in public. I find people don't mind being mentioned or cc'ed in a question even if they mind being the ones asking the question. It is a huge opportunity for growth - particularly in communicating clearly and succinctly.
Listen and empathise
Always listen, empathise and try to see the world from the other person's perspective. People are very different and might be going through things that are not obvious. I found it useful to be able to observe body language or reactions which I could indirectly or directly check on later with the team member.
Admitting not knowing
I made it a habit to be clear when I don't have an answer to something. I think this is an important lesson for team members to understand and accept that no single person should be burdened with knowing all things. I also strongly encouraged brainstorming solutions, finding out who would be able to help us and going ahead to share the solutions in spaces with the highest impact. Depending on context, this could be across teams or the entire organisation.
It is important for teams to share context to maintain the notion of a coherent unit. This ensures there isn't much of a knowledge gap between engineers in the team and minimises any knowledge silos. I created a culture where context is regularly shared by always pair programming (swapping pairs twice a week) and having 1 hour a week where everyone comes together to talk about some interesting technical feature they worked on or would like to hear about.
Regular 1:1 check-ins
This is regular time set aside to listen and be listened to if needed. My approach to this definitely evolved over time. I set up recurring check-ins with members of my team the first week I joined and about 3 weeks in, I noticed the check-ins weren't actually happening as regularly as my invite stated. There were a couple of reasons for that. The first reason was that I assumed that everyone had calendar notifications set up and they would message me if they wanted to check in. This was not the case. I later found out in our regular feedback session that: "it would be nice to make the feedback sessions happen." The second reason was that some people preferred impromptu sessions - i.e., chat during lunch or whenever was convenient for them. I was pretty flexible and I accommodated this. The check-ins got easier and more organic. I also adjusted the frequency to match each individual's needs.
In addition to 1:1s, it is important to find some time as a team to give feedback to each other. One way to achieve this is by running speedback sessions where all possible pairs in the team sit together for a short amount of time (say 6 minutes) to give feedback to each other. Our speedback sessions evolved pretty nicely. We started in a physical location with chairs in different rooms and later ran them consistently remotely. It was also helpful to openly (within the team) track the things we were trying to grow in or receive feedback on.
Feel free to reach out to me if you have any questions about how to implement this in your team.
I’m publishing this as part of 100 Days To Offload. You can join in yourself by visiting https://100daystooffload.com.