Lessons from my first months as a tech lead

When I recently transitioned from a senior software engineer to a tech lead, I faced a bit of an identity crisis. For years, my value was measured by the quality of my code, the complexity of the tickets I solved, and the speed at which I delivered features.

Naturally, I fell into a common trap. I thought a "tech lead" was just a "super-senior", someone who writes the most critical code, solves the hardest bugs, and reviews every single PR to ensure perfection.

Over the past few months, my definition of "leading" has shifted drastically. I realized that my success isn't measured by my individual commit history anymore, but by the output and growth of my entire team. In fact, I've come to believe a controversial truth: If you are still the top contributor on your team's board as a tech lead, you are probably failing.

Here is how I learned to stop trying to do everything myself and started focusing on trust, engineering pragmatism, and building a scalable team.

The "super-senior" trap vs. enabler

Early on, if a critical feature needed to be delivered, my instinct was: "I'll do it myself. It will be faster." And short-term? It probably was. But this approach quickly led to my first major failure as a lead.

I remember picking up a critical infrastructure migration ticket because I knew the system best. I thought I was protecting the team from complexity. But because my schedule was fractured by planning meetings and stakeholder alignment, a task that should have taken two days took me week. The entire release was blocked because I was the bottleneck. I wasn't a hero. I was the single point of failure.

I realized that sometimes, the best way to lead is to let your team fail. In the past, I would catch every potential edge case during code reviews. I thought I was ensuring quality. In reality, I was teaching my team that I was the safety net. You cannot build ownership if you never let them own their mistakes.

The transition from "doing" to "enabling" didn't happen overnight. It required a conscious change in how I assigned work. I had to stop assigning tasks (instructions on what to do) and start assigning problems (context on what needs to be solved).

My turning point came with our recent project, the "Trips Builder". In the past, I would have designed the entire architecture, defined every interface, and handed out distinct coding tasks. I would have been the architect, and they would have been the builders.

This time, I tried a different approach. I provided the "why" (business assumptions) and the "what" (the end goal), but I deliberately left out the "how." I handed full ownership to a senior engineer on my team. The result? He didn't just code it. He planned the timeline, organized meetings with Product, and handled integrations with other services and external vendors. By stepping out of the way, I gained a partner who could drive topics from A to Z. I realized that trust is a two-way street: I had to trust him to figure it out, and he had to trust that I would support him if he stumbled.

I applied this same "outcome-first" logic when we started working on our new LLM-based service. I have a strong interest in GenAI, and I was tempted to do the research myself. However, I knew that if I hoarded the interesting work, I would disengage the team. Instead, I handed ownership of the LLM research to a developer who showed potential. Because I gave him the space to explore, rather than just giving him a solution to implement, he discovered an innovative "prompt auto-refine" method that I hadn't even considered. If I had insisted on being the "smartest person in the room", we might have missed that breakthrough.

This shift required an "adrenaline detox". As a senior engineer, I lived for the dopamine hit of execution, whether it was the deep flow of building a new feature or the adrenaline rush of fixing a critical bug at 3 AM. That tangible output was my validation. As a tech lead, I realized that if I hoard the exciting features, I disengage my team. And if the team needs a hero to save the release, I have failed at planning. A boring sprint is a successful sprint. I used to chase the excitement of "crunch time".

Now, I measure my day not by lines of code written, but by unblocked paths. My job is to be the enabler. I am not the only one who can fix the system anymore, and that is the ultimate success. My goal isn't to put out fires. It's to build fire-proof houses.

Pragmatism is an engineering skill

In the beginning, I wanted every solution to be elegant, future-proof, and architecturally pure. But in a fast-paced business environment, perfection is often the enemy of profit.

I now operate by a simple, controversial rule: code is a liability, not an asset.

Every line of code we write is something we have to test, debug, and maintain for years. The best tech lead isn't the one who writes the most elegant code. It's the one who convinces the product manager that we don't need to write the feature at all, or that a "boring" solution is better than a custom microservice. I learned that pragmatism, the ability to make calculated trade-offs, is just as important as knowing the fundamentals of computer science.

Take that same LLM-based flight extraction project I mentioned earlier. Faced with a tight deadline, I rejected the urge to "quick hack" it (creating technical debt) or "over-engineer" it (taking too long). Instead, I focused on strategic pragmatism. I negotiated scope with stakeholders based on ROI, cutting non-essentials to preserve architectural integrity. The result? We implemented the entire project in 3 months, improved data extraction quality, cut infrastructure costs, and reduced response time by more than half.

Pragmatism also applies to what I code. I realized that if I pick up the most urgent ticket, I become a liability and a bottleneck. My day is fractured by meetings, if I'm stuck, the critical path is blocked. Now, I practice "coding to stay sharp, not to block". I pick up important but non-urgent tasks (like researching new tools), ensuring I remain hands-on without endangering the sprint goal.

Engineering isn't just about building the "best" system in academic terms. It's about building the right system for the business context. Sometimes the situation demands a Ferrari. Other times, a reliable truck is exactly what's needed to get the job done.

From gatekeeper to guide (scaling yourself)

You cannot scale as a leader if you are the team's "single source of truth".

This realization hit me when I understood that Python or Go are not the most difficult languages to master. The hardest programming language is a natural language (in my case, English and Polish). Writing code is deterministic. The compiler (or interpreter) either accepts it or it doesn't. But explaining a complex architectural constraint to a non-technical stakeholder? That is full of ambiguity. I realized that ambiguity, not bugs, is the biggest threat to a project.

My most valuable contributions now aren't algorithms, but systems that remove this ambiguity and allow me to make myself redundant in the day-to-day details.

I achieve this by focusing on three areas:

1. Documentation as leverage: code tells you what the software does, but it rarely tells you why we built it that way. I focus my documentation efforts on context. I rely heavily on ADRs (Architecture Decision Records) to capture the "why" behind our choices. By documenting the trade-offs and reasoning, I prevent the same decisions from being re-litigated by the team months later.
2. Establishing guardrails: instead of acting as a "gatekeeper" who must approve every technical choice, I try to set standards and guardrails. This includes defining clear architectural patterns and investing in automated checks. When the "definition of good" is codified in the process, the team can make autonomous decisions without waiting for my blessing.
3. Strategic prioritization: I act as a filter for the team. Before every refinement or planning session, I invest time in aligning with Product Managers and stakeholders. I handle the tough trade-off discussions and prioritize the backlog before the work reaches the team. This ensures that the team isn't disturbed by chaos or vague requirements, allowing them to focus purely on execution rather than getting bogged down in ambiguous debates.

Ultimately, scaling is all about shifting your focus from scaling your hours to scaling your team and systems.

The mindset shift

Being a tech lead is a constant balancing act between the "maker's schedule" (deep work) and the "manager's schedule" (meetings and coordination). It is easy to feel like you are losing your edge when your GitHub contribution graph isn't as green as it used to be. But that is the wrong metric to watch.

To navigate this shift without losing my sanity, I distilled my experience into three simple heuristics that now guide my work every day:

1. The rule of redundancy: if I have to explain the same logic or process more than once, it must be documented. If I keep explaining it verbally, I am becoming a bottleneck.
2. The rule of theft: if I solve a complex problem entirely on my own, I haven't just "helped". I have stolen a learning opportunity from a team member who needed that challenge to grow.
3. The rule of pragmatism: an "elegant" solution that is delivered two months late and it is not used to its full potential, is actually a bad solution. True engineering seniority is knowing when to build a truck instead of a Ferrari.

If I could send a message to my past self, the one anxious about stepping away from the critical path, it would be this: Your job isn't to be the smartest person in the room. Your job is to build a room where everyone else can get smarter.

Real leadership isn't about control. It's about clarity. It is about replacing "I can do this faster" with "I trust you to figure this out". It is about trading the short-term dopamine hit of fixing a bug for the long-term satisfaction of watching your team build a system you didn't even have to touch.

Focus on unblocking others, be pragmatic about your engineering choices, and trust your team. That is how you scale.