Holding the Career Ladder Steady as a Tech Lead
2020-03-12
It is easy to view the tech lead role as one that is primarily, well…technical. However, as is the case with most jobs, a tech lead’s role includes responsibilities that are also human in nature:
- Can you provide sound technical feedback to decisions made by your teammates?
- Can you convince others of your architecture design using sound technical arguments without resorting to personal criticism or attacks?
- Does your team feel safe to be creative, make mistakes, and challenge each other?
A tech lead’s dual role in both technical planning/writing code along with writing code with other people on the team provides opportunity for unique insights that may otherwise be unavailable to managers. Engineering managers typically won’t work with team members on day-to-day technical decision making, output, and struggles. They may review pull requests, but may not be aware of who came up with the general solution design or who contributed or struggled with the implementation.
There are opportunities during performance review seasons for tech leads to share feedback, but not all review systems require peer feedback or require tech leads to review all members of their team. It is true that teammates also know what it’s like to work with one another, and while they may share frustrations with a manager during a one-on-one, they are not likely talking about their teammates’ career aspirations or skillful decision making. One-on-ones are usually focused on that individual’s career (as they probably should be). This means that the information that teammates, and tech leads in particular, have about each other will get lost come review season.
It is therefore vital to be a voice for members of your team. Tech leads are in a unique position where you can advocate for people who may not advocate for themselves or may not be in a position to do so. This is particularly important for people from underrepresented groups in tech. There are many assumptions that can be made without the more individualized feedback a tech lead can provide, and it has lasting effects on our teammates’ careers.
So what can tech leads do to help their teammates be recognized for their accomplishments and progress in their careers?
Give lots of credit.
Make a conscious effort to give credit for ideas, solutions, discoveries, or any other good thing that happens on a team. Do it both publicly (a line in Slack, shoutout in a retro) and make sure to call it out to a manager in private. Create a culture of asking questions.
Ask questions that you think teammates may have in a meeting, especially if you have new teammates or know that a teammate has expressed confusion on a topic. Not everyone always feels safe asking questions that may come off as “dumb.” Setting an example creates a culture of question asking, making it easier for others to do so. Depending on the person and your relationship, you can consider asking them directly, “You mentioned a good point the other day, do you want to share that?” Foster psychological safety, particularly around failure.
Engineers that are afraid of failure are less likely to search for creative solutions to problems. Let it be known that failures occur as a team, not as an individual. Consider the door/window philosophy of leadership. When ideas and comments come from outside the team, be a door to negativity and a window to positivity. NOTE: This is not a dismissal of constructive feedback which is equally important, it just ensures it happens in the right setting.
Use one-on-ones.
Schedule occasional one-on-ones with teammates to get a sense of the things they are hoping to learn, the things they think they are doing well, and the things they are struggling with. As opposed to a manager, your role here is to assign work, pair, offer learning resources, and review code with these things in mind. This also creates a known place for feedback to occur both ways.
Implement a healthy feedback cycle.
Learning how to give and receive feedback well is a skill that can be learned and practiced. There are many resources you can find if you want more information. When someone is excelling, let them know. Receiving affirmation can validate conscious efforts or encourage natural skill sets. When someone is struggling, provide feedback, opportunities, and resources in a way that is supportive while still constructive. And finally, feedback needs to go both ways. Be sure to ask for feedback in every one-on-one, making it clear that it’s a normal thing. This “giving permission” to provide feedback creates trust and increases the regularity of good feedback.
Provide concrete and actionable feedback.
Some examples:
- If you see a pattern of someone always looking for “just one more” review on a PR, investigate why they are hesitant to merge their code. This can be an opportunity to affirm their skill sets and awareness or to be a resource for clarifying confusing code paths or concerns.
- Someone may prefer not to speak up at meetings, but in one-on-one situations, they are insightful and collaborative and good communicators. Instead of saying something like, “You should talk more in meetings,” (which is just an empty cliche) express that being able to communicate complex technical ideas to varying groups of people is an important skill that contributes to collaborative and productive teams. You can help them ensure they are able to communicate to wider groups of people, via email or technical design docs.
- Be sure to provide technical feedback in addition to soft skills feedback. E.g. “I notice you lean heavily toward metaprogramming and inheritance, but that can sometimes make code difficult to read and maintain. Let’s focus on maturing your skills to produce easier to read code.”
Partner with the manager
Ensure that in your own meetings with your manager you take time to share the successes and areas for improvement for your teammates. If this needs to be an alternating meeting with your manager so you can also have opportunities to talk about your own career progression, so be it.
Offer leadership opportunities
As teammates’ skills progress, consider offering opportunities for anchoring/leadership on a team. Not all teammates may openly say they want to take on a project, but that does not signal their capability to do so. This also has the benefit of increasing your teammates’ sense of ownership of projects and signifies the importance of their role on the team. These also do not need to be full blown month long work streams, but can be as small as taking complete ownership on design for a card.
Though taken together these tips may seem like extra work, think of this instead as a tech leadership mindset. Being a technical leader means being aware of the technical needs and aspirations of your teammates, creating a space where a team can learn and grow, and giving credit where credit is due.