Your highest priority as a tech lead is taking a wide view of the work so that you keep the project moving. How do you go from organizing and planning the code you need to write on your own to organizing and leading the overall project?
In the systems architect and business analyst roles, you identify the critical systems that need to change and the critical features that need to be built in order to deliver upcoming projects. The goal here is to provide some structure for basing estimates and ordering work. You need not perfectly identify every single element of a project, but there’s a lot of value in spending time thinking through the externalities and issues related to a project. This role requires you to have a good sense of the overall architecture of your systems and a solid understanding of how to design complex software. It probably also requires you to be able to understand business requirements and translate them into software.
Project planners break work down into rough deliverables. With this hat on, you’re learning to find efficient ways of breaking down the work so that the team can work quickly. Part of the challenge here is getting as much productive work done in parallel as possible. This can be tough because you are probably used to thinking about only your own work, instead of the work of groups of people. Finding places to apply agreed-upon abstractions to enable parallel work is key. For example, if you have a frontend that consumes JSON objects from an API, there should be no need for the API to be completely finished for the frontend development to begin. Instead, agree upon the JSON format and start to code to that format using dummy objects. If you are lucky, you’ve seen this happen before and are simply pattern-matching your previous work. At this stage, you will want to gather input from the experts on your team, and talk to the people who know the affected parts of the software deeply, so that they can help with the details here. You will also want to start identifying priorities as part of this process. Which pieces are critical, and which are optional? How can you work on the critical items early in the project?
Software developers and team leaders write code, communicate challenges, and delegate. As projects move forward, unexpected obstacles arise. Sometimes tech leads are tempted to go to heroics and push through these obstacles themselves, working excessive overtime to get it all done. In your position as tech lead, you should continue writing code, but not too much. Even if you are tempted to pull a rabbit out of the hat yourself, you must communicate this obstacle first. Your product manager should know as early as possible about any possible challenges. Enlist the help of your engineering manager as needed. In a healthy organization, there is no shame or harm in raising issues early. Teams often fail because they overworked themselves on a feature that their product manager would have been willing to compromise on. As a large project nears its delivery date, there will be compromises on functionality. Start looking for opportunities to delegate work, especially if there is part of the system you expected to build yourself that you have not had the time to tackle.
As you can see from these descriptions, in the process of being a tech lead, you have to act as a software developer, a systems architect, a business analyst, and a team leader who knows when to do something single-handedly, and when to delegate the work to others. Fortunately you don’t have to do all of these tasks at once. It may be uncomfortable at first, but you’ll find a balance with time and practice.