Measuring your performance as Tech Lead
People tell you you're doing good; Do you?
Measuring your performance is something that, commonly, happens once a year with your manager. During that process, you tell “what you did well” and “what you want to focus on next year” and your manager will do the same.
If you are lucky, you will receive feedback from your manager (at least) all across the year, so during the performance review the number of “unexpected things” will be very low.
But that’s the ideal world. In the real world, that’s not always the case; your manager has many meetings, and no time to focus on giving you feedback or even to keep track of the successes you communicate to her/him.
From here, I wondered about how a Tech Lead could have a north start that could keep her/him on track for success in this role, so I did an exercise to research and understand how I would measure the success of my role, measure the success of the Tech Lead role.
In today’s issue, I will present my understanding of how to measure the performance of a person in the role of Tech Lead.
I defined a list of keys to measure myself. Please note that, even though each of us has our own context, so the measurement should be tied to that context, I’ve tried to come up with a list of keys that could be used to measure the role itself and not only apply to me.
The keys are:
Manage the Tech Debt & Technical Initiatives
Ensure Code Quality
Optimize Software Delivery
Mentoring of teammates
Please note that some of these keys can be easily measured quantitatively, while others are more qualitative.
👩🏻💻 Manage the Tech Debt & Technical Initiatives
This is about ensuring that the amount of tech debt in the software you own does not get rough.
You choose the way you want to address the tech debt, either in dedicated time frames or on a daily basis, but you have to have a strategy for this. I prefer to address the tech debt right away when I’m implementing product features.
Same for technical initiatives. In a product company, the money comes from new features, but still, you have to push for delivering engineering-related work, like implementing new pipelines and putting in place new practices, patterns, and architectures, not only coming from your own initiative but also from the Engineering organization.
If you work with Scrum, a good way to deal with Technical Initiatives is to book an X% of your capacity to deliver engineering-related work.
☢️ Ensure Code Quality
The quality of the code must be one of your main focus.
Whether you perform pair programming, pair reviews, or just normal code reviews, you have to put in the right effort to ensure that the right practices and patterns are in place for every change.
This is not just related to tech debt, it’s something else. It’s a continuous practice of reviewing, adapting, and shipping changes, with the goal of improving the quality of your code and making it more maintainable.
For this, the book I commented here helped me a lot 👇🏻
♻️ Optimize Software Delivery
This is about to ensure the way to deliver your software is and keeps smooth. You have to deliver and deliver fast. Also, you have to be prepared for the “unknowns” as much as you can.
For example, you ship a change into production, but something goes wrong, your service does not respond anymore, and you have to solve it. The way you deliver software should allow you not only to detect that before your customers, but also to react to that as fast as possible, and ship the fix.
Also, this is about removing the impediments that hold you to deliver as many times as you could need per hour/day/week/month. In a recurrent manner, do the exercise to identify those impediments, a retro with your teammates could help so that you can include the outcomes in the Tech Debt or Technical Initiatives I’ve mentioned in the first section of this article.
👩🏻💻🧑🏽💻 Mentoring teammates
When you are in the Tech Lead role it’s not only about you anymore. This is the first role, coming from a Software Engineer role, in which the focus on your teammates comes to be a major task. From here to more senior positions, the effort to help others comes to be more and more important.
In this dimension, you should focus on the technical growth of your teammates. How? I can suggest this:
Find and understand the technical path that your peers want to follow up. Sometimes people, more often Junior profiles, don’t know which technical area to grow. If you can help them with that, do it, even though this could be an Engineer Manager’s responsibility.
Find opportunities for them. Because you are in the role of Tech Lead and have other responsibilities, you will be exposed to meetings and situations that the rest of the team will not. There, you can find opportunities for your teammates, linked to their technical growth, so they get that chance and move forward in their careers.
If you have learning references, like courses, certifications, books, or newsletters like the ones from Hemant Pandey, Gregor Ojstersek, Jordan Cutler, or Ryan Peterman.
The more they grow, the more you grow.
My friend Akash Mukherjee wrote a very interesting article about mentoring, and you can read it 👇🏻
✨Takeaways
As final words, let me share with you some takeaways:
The keys I’m sharing with you to measure the Tech Lead role come from a real need I had.
They are meant to be used to measure the Tech Lead role in general. Even though you have to understand the context of your company, to ensure these keys are aligned with the goals your company and manager put on you, these keys can be seen as good practices for the Tech Lead role.
Those keys are meant to keep the person in the role focused on the final goal of growing in this role.
Hope you enjoyed this issue as much as I did writing it. I would love to hear from your experiences about measuring your performance; Drop a message in the comments so all of us can learn more!
Best,
Marcos.
Great insights. Thank you for the shoutout :)
Great article, Marcos and thank you for the mention!