
Sometimes you have to trade the compiler for a calendar.
I used to think I was a CTO. In my previous role at a small startup, I designed the entire application architecture from scratch, managed backend and database design, handled DevOps, and orchestrated our APIs. I was a one-man army who eventually mentored a growing team of frontend developers working on our complex 3D product design tool. I was strict about code style, made all the tough technical decisions, and people came to me when they hit walls.
But as I gained experience, I realized something: I wasn't a CTO. I was a Tech Lead. And that distinction taught me one of the most important lessons of my career.
The Illusion of Technical Excellence
We started with no roadmap, just a goal and my technical vision. I vested myself as CTO because, well, someone had to. I mentored engineers from zero background to full-fledged developers, pushing them beyond their comfort zones while maximizing their strengths. When they became capable enough, I learned to trust them with critical work.
We grew tremendously as individuals and professionals. But the project? Not so much.
That's when the hard truth hit me: code alone doesn't make a product. You can write beautiful software, follow every best practice, ship relentlessly, but if there's no real value being delivered, the software is effectively dead. The solution matters more than the code.
We didn't have a tech bottleneck. We had a management problem.
I left because it became a burden, like a toxic relationship where I'd invested everything but received little in return. Sure, they kept the code, but I built it, and they can't take that talent. They miss me for that. The only consolation: I never stopped trying to improve myself.
A Different Kind of Challenge
Now I work for a big company with a massive software ecosystem. The contrast couldn't be starker.
Before, I called all the shots and held the master key to everything. Now, even when I have brilliant database optimizations with tremendous positive impact, I need to convince DBAs it's the right call. I need to dance through processes and arrangements just to gain access to critical systems. Minimum privilege access. Yay!
It's frustrating at first. Going from architect of everything to needing permission for routine tasks feels like a demotion.
But here's what I discovered: once a Tech Lead, always a Tech Lead.
Leadership Without Authority
In less than six months, I've moved between teams, had two manager changes, and experienced constant organizational shifts. Change is the only constant. Yet somehow, I've managed to make an impact:
- I learn fast and stay ahead of the curve.
- I unblock QA when they need fixes so features ship on time.
- I provide genuine feedback to peers because I truly value their work.
- I focus on results and being helpful.
I'm no longer the mastermind behind everything. Honestly, I feel clueless sometimes. But I do my research, I constantly learn, and I prove myself through outcomes.
Now they want me to become a Technical Leader/Owner. After less than six months. While I'm still learning the business domain and internal workings. They appreciate how I tackle problems, and my manager sees me as an asset who helps achieve team goals, not as a responsibility to manage.
What Leadership Actually Means
Some people think being a leader means being a boss, telling others what to do and how to do it.
That's not leadership.
A leader paves the way and shows how things get done. A leader provides insight and listens to feedback.
In war room discussions or architectural design meetings, I barely talk. I let my peers lead the conversation because they're confident and have strong input. I trust them, and I want to learn how they approach problems. When I do speak up, it's to ask follow-up questions or respectfully disagree when needed, not to justify my position or hijack the meeting.
A leader isn't obligated to dominate every discussion. A leader is entitled to disagree, ask questions, and broaden the scope so the team makes informed decisions together.
Lessons for Aspiring Leaders
I'm still learning, and I have a long way to go. But I'm surrounded by smart, capable peers who teach me something new every day. If I had to share what I've learned so far:
Be proactive. Ask any doubts you have. Don't be scared to sound silly or disagree with something that doesn't convince you.
Don't wait for others. Instead of relying on your manager to reach out to the client for input, ask the client directly. First-hand insight is invaluable.
Be methodical. Develop rituals in your routine that help you tackle daily goals, which accumulate into weekly and monthly progress, which impact your long-term objectives. Don't lose focus of yourself.
Know your role. A leader isn't someone who knows all the answers. A leader is someone willing to find them and provide solutions. And when they're not the ideal person to solve a problem, they make sure to find the right person who can.
True leadership isn't measured by the code you write, but by the engineers you grow.
Top comments (0)