As tech lead, curveballs will constantly be thrown at you, or at least they were for me. Someone leaves the project, an external process takes longer than expected, or no one notices a bug before it’s too late.
These are minor bumps in a long road. It’s easy to react to everything in real time. You think you need to answer every message immediately, or you need to pivot everything the moment an issue occurs.
Instead, your job is to be strategic.
From the start, you need to think long-term. You need to understand the overall goal of a given technical decision, and all curveballs or bumps will be measured against how its affects the overall strategy.
If you don’t plan, everyone else will plan for you. Every other issue will take precedence over your roadmap.
For instance, if you’re building an app for many consumers, while you need to understand the different use cases and urgency, you also need to focus on the strategy to bring the app to fruition. If a consumer asks for a feature, you figure out how it can be built into the existing strategy — not replace it.
How do we build this API? What’s the timeline from that other team?
These are just two of many questions you may encounter in your time as tech lead. Unknowns can be grueling, keeping you up at night, tossing and turning over architecture decisions, of all things.
I get overwhelmed by unknowns. In my time as tech lead, we found approximately three more unknowns weekly. At every turn, it felt like there was a new team to seek out, a new strategy to discover, and a new architecture decision record to write.
I would get so overwhelmed by unknowns that I started keeping them to myself. Instead of telling my team, my head constantly swirled with questions. I was afraid of admitting I didn’t know things, particularly questions that popped out of nowhere to ruin my architecture plans or completed research.
Luckily, I realized I needed to write them down and get a strategy. I mapped my questions onto our architecture diagram, presented them to the team, and we got to work.
While unknowns can be scary, write down what you know. If you know that an unknown exists, that’s enough to start investigating. Don’t hide the questions in your head because no one else is aware of their importance.
Admitting when you don’t know something that is truly heroic.
You don’t need to know everything as a tech lead. But, you are in a unique position to point your team to where they can find answers.
There’s so much power in “I don’t know, but I know who might,” or “I don’t know, but let’s figure it out together.”
With “I don’t know, but…” you are saying it’s okay not to know. You are admitting you are not a perfect dictionary of a human. Believe it or not, leaders aren’t flawless.
Don’t beat yourself up for not knowing — look at it as a moment to learn something new and teach others how to solve it next time.
If team members complain about something, you are not responsible to find the perfect solution. You are no one’s fairy godmother.
Instead, help transform their complaints into solutions. Ask your team member, “What can we change to improve this scenario?”
Lead your team to brainstorm solutions.
Developers are problem solvers, whether it’s code or not. For them to grow in their careers, they cannot expect someone else to always solve their problems. While you may be tech lead, you can’t be responsible for every issue.
Let your team solve some problems on their own, and they’ll likely take the solution to heart since it wasn’t just handed to them.
Ultimately, you are not your product and your product is not you.
As tech lead, you are involved in every part of the project. While leading the technical side, you also need to understand how the design and product sides work. Thus, you are a reserve of information — understanding how all the parts mesh together.
While it’s great for you to know the overall project, you shouldn’t be the only one. If you are the only one who knows some information, there’s a problem. Give others the opportunity to learn and grow.
At one point or another, you will decide it’s time to leave the project. After all, software lives long after the people who work on it (okay — the hope is for everlasting software, right?). You do not want to be irreplaceable.
Instead, you should constantly make sure others can try on the many hats you wear, and your knowledge should be documented to an extent. You will make it easier for the next person to take on the role, and you won’t hold yourself back from future opportunities.
As a tech lead, you track which stories your developers are working on and what’s coming up next. While some responsibilities are also split with your project manager and product manager, ultimately, you are responsible for developers receiving work and helping them if they’re blocked.
For any tools you use day-to-day, customize them to fit your needs. For example, your issue tracking board (JIRA, Trello, Zenhub, etc.) should give you an at-a-glance view of everything going on. It should help organize upcoming sprints and provide enough info to your developers.
If it doesn’t, fix it.
As tech lead, I spent more time than I’d like to admit hovering over team members’ Github profile icons to discern who was working on what card. None of them set profile pictures, so they were all generic patterns of colored squares. I asked them to add pictures and saved myself any headaches.
I also added labels, columns, and anything else to help organize the board. Any tools you use should be customized to help you and your team.
Make those changes.
As a first-time tech lead, I found it easy to think the project’s success sat on my shoulders, even though everyone on the team played a major role. I almost burnt myself out, trying to solve every issue. It’s not sustainable or reasonable.
You are not measured by your project’s success.
If the project fails, it doesn’t mean you’re a tech lead failure.
Instead of putting pressure on yourself, lean on team members to help you. Ask for assistance, set up one-on-one meetings, and focus on taking care of your well-being. Your team needs you for this project, but they also need you to take care of yourself.