Role of a technical lead
I am currently a Tech Lead for the Atom platform at Kaplan Test Prep. As for my love of programming, I pursued my Bachelors & Masters of Science in Computer Science. In 2015, I joined Kaplan as a Senior Software Engineer. I was enjoying coding, refactoring, architecting a vision, writing unit tests, etc. and my happiness index was 4/5. My manager at the time saw my leadership potential and offered me a technical lead role when it became available. I took this role because I had interest in technology as well as management.
I have been a technical lead for the past two years now. My team operates like a startup inside a big company with autonomy. Given this autonomy, I took the opportunity to define my role as a technical lead based on the needs of the business and my team. I measure my success based on the success of my team. It is no longer more about my 8 point story, but instead about the 50 points we signed up for as a team.
Yes, part of my responsibilities include architecture, technical design across teams, scope and plan deliverables with Product Owners, and communicate an execution plan with estimates to the delivery managers. But in addition to that, I lead a great technical team. Here are four key things that I’ve learned sets my team up for success:
Be available and understand the needs of your team
As a developer, I would put on headphones with Spotify Global Top 50 and focus on my programming tasks. As a lead, you need to be available as your team members have questions for you. As a technical plan is made, you should try to pick stories for yourself that are related to prototyping, research, or small deliverables. You need to context switch when your team has questions, which would be tough if you are working heads down on a complex story. You are now responsible for the deliverables of a team as a whole. You have to help them move forward by pair programming, architecture brainstorming, debugging unit tests, rebase issues, getting any other information they need to do their job effectively, etc. You have to ensure that everyone’s work fits into the puzzle which is the business outcome.
Ship business critical projects on time
As a developer, during sprint planning I was assigned a “JIRA” ticket with all the requirements which I estimated and worked on that sprint. This informed the velocity of the team and helped us plan future projects. As a lead, I enabled leads to plan their sprints. We do a session of “What & Why we are building”, and then individual teams can plan and execute accordingly. Once we understand the desired business outcome, we can align technical stories along with business projects. This gives us freedom to try new technologies, refactor the platform, and avoid tech-debt (at that point). As long as the business projects get shipped on time, during the process we can have technical enhancements, improve test code coverage, ramp up junior engineers, and give people a sense of ownership of what they’re working on. This enables the team to be passionate towards the product they’re building rather than being focused on dates.
Invest in your teammates
As a developer, I was working with a lead and my manager was someone else. Every one-on-one with my manager, I communicated what I worked on, what I liked, and what I wanted to work on next. As a lead, you are not really anyone’s direct manager. However, you can bridge the gap between developers and their managers. You work closely with your team members on a regular basis; this gives you insight about their strengths, weaknesses, and goals for better feedback. I recommend doing regular one-on-one’s with your team members. You can help them channel their strengths and provide them constructive feedback that would enable them to grow. Also, given the insight you have about them, you can give feedback to their managers so that they can mentor and coach them. Each developer has their strong skills, but I personally always push them to try all flavors of the tech stack. I recommend them to try front-end + back-end + releases + QA; rather than being comfortable in one role. I want them to gain experience in different dimensions as they might discover new passions in the process!
Delegate and empower your team
“Yes, you can code”. I read a lot of articles as I became a lead on how everyone knows I can code and I need to “delegate”. As a lead, it was a journey for me to learn delegation, but now I definitely see the value as I don’t have to work crazy hours. Initially, I took on more complex stories for myself which isolated me from my team; we did not progress optimally and this isolation was ultimately not beneficial towards our goals. I also tried to do every code review, which made me a bottleneck. Now, I brainstorm the end-to-end architecture with the developer and code reviewer and then I trust them to roll with it. I try to get flexible timelines for junior developers, so that they have time to learn along the way which I see as a future investment. As developers perform code reviews, they learn from each other. It builds a healthier team dynamic, where they can reach out to one another with ideas or ask for help.
Psst! I still sneak in a code review comment here and there.
I still have a lot to learn as my career advances, but to summarize, here are some key takeaways:
- Be available and stay connected with your team.
- Be a part of the planning process.
- Take time to reflect on tech debt and technical improvement opportunities in a fast-paced environment.
- Do regular one-on-one’s with your team members even if they don’t directly report to you.
- Give your team new challenges to keep them engaged.
- Delegate, do not be the single point of failure on your team.
- Trust your team.
