These are some notes from insightful blog posts on what it takes to be an effective tech lead.
What makes a badass TL is broken down into three A’s: attributes, activities and actions.
Attributes
Over time, you should always be increasing three attributes: Knowledge, Speed, and Awareness.
- Knowledge: If work is completed, but waiting to be reviewed, then you should almost always drop your own work and help move it forward.
- Speed: You should strive to be ultra-responsive and capable of making instant decisions, always kicking the ball forward.
- Awareness: You should be able to keep the current state of the entire project in your head at all times. Otherwise, you cannot be aware of potentially imminent blockers.
Activities
The two most important things that a tech lead can do also happen to be exact polar opposites: block and unblock.
- Block: The tech lead needs to be alert and aware to what is going on in the project, always ready to jump in and block bad decisions before they are made, typically armed with a better solution. Blocking should not stop progress, it course corrects so things can keep moving. Think harness, not safety net.
- Unblock: If someone has a question, you should be able to either give an answer or bring in the right person to field it.
- Redirect: Mentally build an expert index so you always know where to find an answer. Proactively adding the right individuals to any thread or code review can help increase the overall quality of the work.
- Decide: The faster you can reach a decision, the quicker others can act on it. When you do listen to your instincts, make sure that you’re making a robust decision that can stand the test of time. When given a set of options, reduce the number to 2, see if there is a best choice based on experience or data. If not, redirect to someone better suited, or block the decision from being made or unblock it by going with your instinct.
- Show: Have the respect and trust of your team, which is best accomplished by demonstrating that you know your stuff.
Actions
There is a long assorted list. Here is an attempt to put its items into buckets:
- Management responsibilities “outward”: Say “no” often to new or unnecessary features, vet the product’s privacy and security concerns, work with other engineering teams especially on dependencies, etc.
- Management responsibilities “inward”: Create and maintain launch and testing and release plans, shield engineers from management, setup team fix-its and hackathons and bug scrubs, escalate blocking issues as necessary, and load-balance work among the team, etc.
- Other management responsibilities: Help create and stack rank project priorities, create target milestone dates and correct and refine them as needed, etc.
- Best technical practices: Define best practices for issue tracking, maintain on-call and onduty processes, and ensure tests are being written for core functionality, etc.
- Team growth: Recruit engineers, review code in detail and give useful feedback, read and write and give feedback on design documents, help onboard, etc.
- Technical action: Identify technical debt, generate new ideas and elegant solutions, debug difficult production issues, write the right code at the right times, etc.
Learn to Delegate
- When you take on the harder problems, it also misses an opportunities for other developers to grow and problem solve.
- For problems when your experience and knowledge are important, find a way to delegate but still be involved. Kicking off a design session to discuss general approaches, or reviewing progress a regular basis.
Find Time to Code
- Being involved in the code helps you build respect with the rest of the team, and keeps your knowledge up to date and current with constraints, problems, and the “shape” of the codebase.
Visualise Your Architecture
- Have a visual representation of their system architecture on-hand and uses it to have discussions with developers.
- Host a whole-team whiteboard session. Focus on attributes that drive your architectural vision (scalability, performance, usability concerns, etc) and how they have shaped your architecture. Call out assumptions and the historical context.
Spend Time 1-on-1 With Team Members
- Anything that you can do to make each person on your team better makes the overall team better.
- Understand the backgrounds, strengths, interests and goals of the team members. Align their tasks with their responses.
- Connect developers with opportunities for them to grow.
Learn to Speak the Language of the Business
- To communicate technical concepts to non-technical people, find the terms that business people use and find ways to explain tasks in those terms.
- Possess strong technical skills. You’re also responsible for fixing technical issues that your teammates can’t solve. If you can’t fix something yourself, find an acceptable workaround.
- Teach your teammates. If there are some core principles or practices that you want them to apply to their work, you must invest time to promote that understanding.
- Trust your teammates. If you trust a teammate, that developer will respond with improved output. The quality may not be ideal, but the developer will show more effort.
- Stimulate self-organization. Do not simply assign tasks to your teammates, but organize planning meetings where members can choose their tasks. But promote a balance in the assigned tasks.
- Don’t keep the coolest technical tasks for yourself. Give your teammates the opportunities to work on such tasks. This raises morale, trust, and skill.
- Try to prevent overtime as much as possible. If in a situation where the team must put in some overtime, don’t tell your teammates they have to do it; instead ask them if they want to do it. Also do not go home early while your teammates are still working.
- Remember that you are responsible for the final result. Never put the blame of something wrong on one of your teammates.
- Give credit where credit is due. Give credit where it is due, and make sure everyone else knows about it too, especially management. Never take credit for the work of a teammate.
- Realize that your teammates are not your developers. Having a leadership role does not mean that you can boss around your teammates. This destroys morale.