My Story as a New Tech Lead
Tips that I found useful in the 6 months of doing this job
Just about 6 months ago I got offered a remote job as a tech lead in a very new startup based in Toronto. At first I was a little bit intimidated by the offer. Would I be good enough for the job? Am I experienced enough? Am I too young to be a tech lead? (I’m in my early 20s). I decided to take the job anyway and see for myself what the answers to these questions were. Today marks half a year after taking that decision and I am really glad I made that move. Nonetheless being a tech lead at a new start up has it’s set of challenges and here is my experience dealing with them.
Leading with flexibility
One thing I noticed as a tech lead is that some people will automatically assume that you know more about tech than they do and although I did have more experience than most of them, their collective knowledge almost certainly surpasses mine. Most people will automatically presume that your ideas are somehow always better since you have more experience, and that is totally false. I think you have to be very clear with your team from the start that you want to hear from them. They should be as comfortable contributing ideas or solutions as you are. Now, does that mean that you need to accept and embrace every single idea that they express? No, but allowing them to share what they think and allowing the team to contribute to solutions and ideas will only strengthen you as a team. Everyone will benefit from being exposed to different ways of solving problems and that will develop your critical thinking which is excessively important in today’s world and especially in software development. Not only that but they will feel more included and will be more motivated to work. And working with motivated co-workers is a thousand times better than the alternative.
Basically, I think that what I am trying to say is that to be a good leader you have to understand that your voice is not more important than anyone else’s in the team. If you want to lead a team to success you have to be the one adapting to them, you have to listen to what they have to say, take their ideas in consideration and allow them to debate on your ideas. You also need to understand that you don’t need to “lead” all of the time. If you want the developers to be independent you have to give them the space to be. Give them as much context as possible and always include them in discussions when it makes sense to do so. My job as a tech lead is to define the end goal and be sure that we are moving closer to that goal every day. It’s not to manage every second of a developer’s day and make sure they abide by my rules. You should keep in mind that you are there to help them, not the other way around.
The pull request workflow
A very unexpected problem I had was the pull request workflow. I had never done a pull request review in my life before the day I started that new job. I was comfortable with PRs from the “Pull Requester” side but I never thought about the “Reviewer” side. From the technical standpoint, one of the main struggles I had was the lack of code editor features in the pull request review process. If you try and review some code in a pull request in Github you just see huge files with diff but there is no “Go To Definition” or hover documentation I was used to in something like VSCodium. This was pretty simple to solve though once I found the Github extension. You can also use the Github CLI or just plain git if you are not using VSCode or VSCodium.
The biggest problem was on the actual review though. The hardest thing to do as a reviewer is to differentiate between personal preference and code that actually needs to be changed. You can mitigate a part of the problem by using a linter and a code formatter such as eslint and Prettier but these tools can’t parse anything related to the way the logic is written down or the name of the variables, functions and classes. And to this day I still feel like this is the hardest part about pull requests. Looking at code and figuring out if the change you are proposing will actually improve the actual quality or just your perceived quality. Most of the time the change you are proposing entails a bigger structural change to the code that will require a lot more work than just changing a variable name. In those cases the best way I found to deal with it is to get in contact with the developer(s) and let them explain their thought process. Sometimes you will realize that you were wrong all along and they were a step ahead of you or that changing a very small thing can make the code way more readable and expressive without having to make that huge structural change that you thought was necessary. A good way to avoid most of this is to gather as a team before even writing the first line of code and having a discussion on what the structure of the code should be. We chose Clean Architecture for all of our projects since it fits our needs but it could be anything that you want. Having a bad structure is better than having nothing.
Hard to focus on one task and always being available
One of my biggest challenge as a tech lead is time management. Back at my other job I could usually code without interruption. The path from idea to implementation was pretty straightforward and I could easily focus on one task at a time. That changed drastically as a Tech Lead. When developers are unsure about a problem or need more specific information about a requirement, you are always the first one they will call. This means that you have to be quick to answer and make your best to be always available. That also means that it’s really hard to focus on one thing because you will get interrupted multiple times during the day. Although there is nothing you can really do about it and you mostly have to deal with it. One thing I found to be helpful is to try to split my tasks into multiple small tasks. That way you can focus on that small piece of work and if something happens in the middle of it it’s easier to get back to it. Of course you can be a little less productive that way because to get in the “flow” you have to be able to focus for a while. But it’s better than having to read the code you just wrote 20 minutes ago because someone asked you a question and you are not out of context.
Staying in the loop
If you don’t practice your programming skills at least once in a while you will sharply start to lose it. That’s why I give myself at least a couple of programming tickets once in a while. You might think that doing code review would keep you up to date but I found that the skill required to read code and the skill required to write code is very different and you have to train both of them if you want to keep your coding fluidity. Whether that’s assigning some coding tickets to yourself or having a side project that you work on here and there, I think it’s really important to never stop coding. It will help you make better decisions and it’s easier to earn the respect of a developer when you can show them that you are not “just a manager”. Also, if you like coding like I do then it’s really fun to code a feature with your team. It helps you understand the project better and keeps you in the weeds.
Making decisions quickly with little information
And finally, as a tech lead in a small start up you are often required to make quick decisions with small amounts of information. We recently pivoted as a company and decided to go from a React.js web app to a mobile app and we had to figure out what technologies to use, quickly. The best advice I can give you here is one that also applies to anyone in the technology world, always be in “research mode”. Allow some time every day or week to research on a topic that is not directly related to your work or tech stack. Even though I have no experience in mobile development I had been doing some research about it so when it was time to make a decision I had this baggage of suddenly useful knowledge that I could use. This is also useful as a developer because exposing yourself to different technologies, languages, concepts and platforms can help you understand and improve your coding in your current tech stack.
Conclusion
Although I like my new job as a tech lead, nothing is perfect. As a software developer I love challenges and trying to figure out solutions to problems, so having these challenges only makes the job more fun. If you ever have the opportunity to be a tech lead at a startup I would strongly encourage you to go for it. It might be intimidating at first but I think you will find the challenge exciting and it will make you grow as a person. Not counting the fact that it will further your career! If you have any questions or are interested in other aspects of being a tech lead for a startup, please get in contact with me, I will be happy to answer :)
