Tech Lead is a solid title. It is something most engineers aspire to. But what does it really imply? If I am a Tech Lead, or aspire to become one, what are the expectations on me, and how will my work day look?
Less coding
As a programmer, you may spend up to 80% of your time coding. There is daily standup and a few weekly meetings. And every now and then you participate in a roadmap workshop or a strategy presentation.
Not so for the Tech Lead. As a Tech Lead, you still write code. But a LOT less of it. The rest of the article describes what you will be spending your time on instead.
Create specifications
As a programmer, you can hope to get a specification that tells you what to do and what is expected. As a tech lead, you are the person WRITING that specification. Together with your Product Owner and perhaps a Designer, you look at a business problem and you come up with a solution.
A business problem can be of the form “Our customers are creating too few profiles”. Your job is to sit in the room from the very beginning helping to brainstorm solutions to the above problem. For each solution, your specific responsibility is to quickly estimate the cost in terms of time and complexity. Then it is your job to suggest something that is almost as good, but much simpler to implement. This cycle repeats until the group has a solution that the customer will love, creates good business value, and can be implemented in a REASONABLE TIMEFRAME.
At this stage, there will still be many unknowns as there still isn’t a proper design, only some sketches and a shared understanding. Your next task is then to look at what parts of the proposed idea have the highest technical risk. You point to these and propose what needs to be done to reduce that risk. Are you worried that the UI will become very complex? Ask that work be started on a UI wireframe. Are you worried about whether the idea will fit into the current architecture? Initiate a POC to check the feasibility of the technical solution.
Once it is time to start writing the actual production code, whether you do it yourself or if you have a large team to help you, the questions that pop up should be small and should not affect the timelines significantly.
Coaching
As a tech lead, you typically have more junior people in your team. Your job is to make them less junior. You do this by coaching them.
The best coaching is pair programming. You work on the same piece of code. One types, and the other reads, thinks about the next step, and gives feedback. Pair programming is proven to over time give faster development with better quality.
If pair programming is not an option, then solution and code review are alternatives. Before a developer starts a task, have them explain the task to you. They need to explain to you why the task matters and how they intend to solve it. You should only ask questions until you are confident that they know why they are doing the task and that their solution will be a good one. Once they have done the solution, you review their code to ensure that their solution is good enough.
Driving architecture
As a Tech Lead, you are responsible for the architecture of the modules you are in charge of. You can ask for feedback from the solution architects or other senior developers, but they will not and should not provide you with a finished solution.
So for each task, ensure that the code written will not degrade the architecture and quality of your module. And if you find that your module has degraded, talk to your Product Owner and propose a cleanup project to be added to the backlog.