I never thought I would enjoy being a tech lead. As a natural introvert, my comfort zone was always in the code. But one day, a senior colleague I’d worked with on a freelance project “hijacked” me, pulling me into a new venture while I was still at my old company. He was handling the backend, and I was on the frontend. He gave me the freedom to choose our stack.
I remember deciding to use Bun instead of my usual Node.js. At the time, around 2019 or 2020, Bun was brand new—still in version 0.x.x with very little documentation. I’d seen a post about it on social media and was curious.
So, what’s the difference between Bun and Node.js?
Both are JavaScript runtimes, meaning they allow you to run JavaScript on the server. Node.js is the long-standing industry standard, known for its stability and massive ecosystem. Bun, on the other hand, is a modern challenger built for speed. It has its own super-fast JavaScript engine (JavaScriptCore, from WebKit), a built-in bundler, transpiler, and package manager, aiming to be an all-in-one, high-performance toolkit. My choice was a bet on raw speed and novelty over stability.
To my surprise, my senior colleague loved the initiative. His appreciation fueled my motivation. The project was a semi-e-commerce mobile web app that allowed users to create product links and share them directly to social media. Unfortunately, the project stalled after a few months due to technical hurdles, but the experience was invaluable.
An Unexpected Reunion
A few years later, that same senior colleague joined the company where I was working, this time as an Engineering Manager. It was a shock, but a pleasant one. We didn’t interact much at first since he wasn’t my direct manager. Then, after about a year and a half, he reached out. He said he had a good impression of me and, noting my five years of experience as a Senior Software Engineer, he offered me an interview for a Tech Lead position.
The interview went smoothly, and I got the offer. I was overjoyed by the career change and the salary bump, but I was also nervous about moving from an individual contributor to a manager. I decided to embrace the challenge with an open mind.
Building a Hybrid Team from Scratch
My first task was to build my team. We had tight deadlines to meet business targets, so while we hired full-time local engineers, we also brought on an outsourced agency from India to fill the headcount quickly. Suddenly, I was leading a hybrid team of nine: a local team and an international one.
This came with its own set of challenges.
- Time Zones: We had to find a daily stand-up time that worked for everyone.
- Language Barriers: I often had to act as a bridge to ensure communication was clear and project coordination ran smoothly.
My focus quickly became about managing team dynamics. When I felt the daily stand-ups were becoming a soulless routine, I’d post in Slack to realign everyone on our sprint goals and the value of the features we were building. I constantly emphasized a no-blame, high-transparency environment. Mistakes were learning opportunities, not moments for defensiveness. I made it clear that anyone could come to me with any question—whether about a feature, a piece of code, or even a confusing message from a teammate.
More Than Just Code
My calendar filled up with one-on-one meetings. It was a huge shift from my days of just coding (though I still did code reviews), but I loved hearing each person’s unique perspective. These sessions were where the real issues surfaced: concerns about task distribution between the local and outsourced teams, suggestions for new tools like Cypress for automation testing, or complaints about unclear QA feedback processes. I did my best to provide solutions for each, whether through explanation or by communicating with the relevant stakeholders.
Another challenge was that my background was in web development, but my team’s major product was an Android app built with Kotlin. I hadn’t touched Android code in years, and even then, it was with React Native. I thought this would be a massive problem. But I learned that as long as I performed my role as a tech lead effectively—communicating clearly and unblocking my team—I could trust them to deliver. I only had to touch the Android code once or twice for an urgent fix; my team handled the rest.
The Politics of Engineering
Beyond the team, I learned about the importance of managing outwards. I had to coordinate with the product team to manage expectations and learned the art of semi-political lobbying and negotiation with other teams and senior stakeholders—something I never expected.
When a service spanned multiple teams, the tech leads would often try to avoid taking ownership to keep their team’s responsibilities contained. If no agreement was reached, the CTO would step in to assess business value, complexity, and team workloads to decide who would own the cross-functional service.
My motto became: If a problem can be solved by you, don’t escalate it. You’re there to solve problems for your manager, not create more.
I focused on reporting tangible results and good news. For difficult issues, especially technical decisions, I’d research a solution, form a justified opinion (e.g., “we should use MongoDB here because the data structure is unpredictable,” or “we need to decompose this function into its own service to prevent a bottleneck”), and then present it to my manager for their perspective. This approach helped build trust and demonstrated my value my manager.
The Informal Award
Then came the moment that tied it all together. My Engineering Manager held a meeting for our entire tribe. Besides the usual quarterly goals and business reports, there was a surprise internal awards session. The question was simple: “Who is your favourite team member?” This could mean the most helpful person, or the go-to person when you have a problem. We all voted in a simple app, and the results were shown live.
To my complete shock, I won.
I honestly had no idea that the effort I was putting in—the one-on-ones, the constant communication, the focus on unblocking others—was having such a profound impact. It was an incredibly validating experience.
That informal award, given by my peers, meant more to me than any formal recognition I’ve ever received. It taught me that true leadership isn’t about having all the technical answers or being the best coder in the room. It’s about creating an environment of trust, clarity, and support, and empowering the team to do their best work. It was a powerful reminder that the ultimate product of a leader is not the software they ship, but the team they build.