Great technical leadership requires more than writing good code.
It requires a collection of skills that are difficult to define, even harder to practise, and impossible to learn completely from a school or a book. At least, that has been my experience.
Becoming a tech lead is not a straightforward promotion from “good at coding” to “good at leading.” For someone used to solving problems with logic, patterns, and a suspicious number of browser tabs, it can feel like learning an entirely different discipline.
How it started
Honestly, I was mostly clueless.
I always liked taking ownership of the projects I worked on. I wanted to understand how everything fitted together, help remove obstacles, and make sure the final result was something we could be proud of. Somehow, that created a path for me—and an unsolicited label as the “lead” of the pack.
When I joined WPMU DEV, roles were not always neatly defined. As a solo frontend engineer for the products division, I always had to do my best with everything in front of me.
That lack of structure could have been confusing. Instead, it pushed me to find my own way of being useful. I became a helping hand for the team. I introduced the first shared library for our projects, slowly encouraged developers to collaborate around it, and tried to make our work a little more consistent.
I made mistakes, of course. Some were small. Others taught me the kind of lesson that arrives after you have already sent the message, merged the pull request, or confidently suggested an idea that was not quite as brilliant as it sounded in your head.
Over time, I became known as the jack of all trades.
That was useful—but it was not yet leadership.
The quiet lead
As the company grew, the teams became more defined. People started coming to me with questions, asking for guidance, sharing problems, or looking for an extra pair of eyes when the code became particularly stubborn.
Without noticing it, I had become the lead. A quiet one, but still a lead.
The role became official later. By then, the most important part had already started: learning that leadership was less about having all the answers and more about helping other people find theirs.
That shift was not easy for me.
The soft skills were the hard skills
One of the hardest things I had to learn, especially as someone with ADHD, was self-control.
Not the dramatic kind. The everyday kind.
The kind that helps you pause before jumping into a conversation. The kind that reminds you to stop preparing your answer and actually listen. Not just hear the words, but listen for the context, the uncertainty, and the thing someone might not feel comfortable saying directly.
Listening helped me develop patience.
When a new developer joined the team, I had to guide them without becoming frustrated when they did not know something I had already learned. Their success was not a delay to my work. It was part of the team’s work. If the team succeeded, I succeeded too.
That sounds obvious now. It did not always feel obvious at the time.
Moving out of the spotlight
As a solo frontend engineer on the products team, I had become the person to go to for everything. I knew the code, the history, the shortcuts, and probably the name of the person who had originally opened the ticket three years earlier.
Then I started leading people, and that habit became a problem.
I had to learn to delegate and trust. I had to let people take ownership, even when they would approach a problem differently from how I would. I had to celebrate their good work without quietly adding an imaginary footnote about how I might have done it.
Leadership meant stepping aside often enough for other people to shine.
That was probably where humility became real for me. Not as an idea, but as a daily practice.
I did not need to be the smartest person in every room. I needed to help create a room where everyone could do their best work.
Continuous learning
There is no single path to becoming a tech lead. Some people are naturally vocal. Others lead through calm decision-making, deep technical context, or a talent for connecting people. Some are recognised early. Others, like me, collect responsibilities until someone finally gives the pattern a name.
The title is only part of it anyway.
The real work is learning when to speak, when to listen, when to guide, and when to get out of the way. It is learning to trust your team, own your mistakes, and understand that leadership is not about becoming the centre of every decision.
It has been a wild ride. I still make mistakes, and I still learn every day.
Maybe that is the most honest path for a tech lead: becoming a little more useful, a little more patient, and a little less convinced that you need to do everything yourself.