From engineer to leader: how I learned to scale through people, not code
When I first entered the field of engineering, my idea of success was simple: write nice code, solve difficult problems, and get things deployed: done!
But as I made the transition to leadership, I discovered something painful: the very behaviours that served me well as an engineer were holding me back as I sought to grow as a leader. Impact was no longer measured in lines of code I could deliver or bugs I could remove, but in how effectively I could create the conditions that enabled other individuals to succeed.
Below are some of the things I learned along the way.
1. Learning to measure success differently
As an engineer, your success directly correlates with work you do with your own hands. You write code, you push a commit, tests pass, feature deployed, you can see your impact almost immediately – why I loved software engineering.
As a leader, that feedback loop is disrupted. Your success is now the sum of what your team ships, not what you personally ship. It’s no longer about if you personally coded the function, but if the team shipped the product and created value.
That role shift was a liberation and a humbling experience. I had to learn to take pride in results I didn’t directly produce. The more I empowered others to deliver, the greater my impact became.
2. Delegation is empowerment
One of my early mistakes was to treat delegation as “just handing something off”. If it didn’t pan out, I’d dive back in. That saved the situation in the short run but destroyed trust and created dependency.
I learned that good delegation is an investment. It’s a question of providing clarity, context, and resources; then stepping aside. Delegation isn’t abdication; it’s empowerment.
The first time I witnessed a teammate take complete ownership of a project I would have otherwise clung to, and succeed in ways I wouldn’t have, was eye-opening. That’s when I understood leadership is about multiplying capability, not hoarding it.
3. Communication becomes your codebase
As an engineer, precision matters; ambiguity breaks things.
As a manager, communication is your new “codebase”. You’re now writing for humans, not computers, and humans need repetition, clarity, and context. If I’d said something once, I assumed everyone was aware. In reality, people need to hear the vision, the priorities, and the “why” multiple times and in different ways.
I learned that when you feel like you’re over-communicating, you’re probably just starting to communicate enough. Words, not commits, became the foundation for trust and alignment.
4. Trust is the real multiplier
As an engineer, I could count on process and tools to scale. As a leader, I discovered the real bottleneck wasn’t process, it was trust.
When people trust each other, they take risks, move faster, and solve problems no process can dictate. Without trust, even the best systems grind to a halt.
I learned that building trust wasn’t in the big gestures; it was in the small ones: keeping promises, being transparent, defending my team when things went wrong. That trust enabled the culture where the team could step forward, take ownership and resolve issues I couldn’t possibly solve for them.
5. Leading through uncertainty
As an engineer, I loved deterministic systems; given the same inputs, I could expect the same outputs. Sadly, leadership does not work that way.
There are always those moments when strategy shifts, reprioritisation of business needs happen, team members leave the team or projects fail despite best efforts. It’s at those moments that the team is watching me more closely than I might have expected.
If I panicked, they panicked. If I was calm, they stayed grounded. Resilience as a leader is not just about how you cope; it’s about how you get your team to cope with the uncertainty and still move forward with confidence.
6. Feedback as a leadership superpower
As an engineer, feedback was largely through code reviews: technical and precise and in most cases, immediate. As I transitioned to leadership, feedback is about growth, behaviour and impact.
Early on, I avoided tough feedback conversations, as I did not want to be that person discouraging my team. However, I have learned that not giving feedback is in many ways worse.
I’ve learned that feedback isn’t about pointing out flaws — it’s about unlocking potential. Feedback, given and received, is a gift that fuels growth.
Final thoughts
My journey from engineer to leader has been less about climbing a corporate ladder, seeking a longer title, but more about letting go. Letting go from needing to be the smartest person in the room. Letting go from having to write the perfect line of code (or any code). Letting go from defining myself by my personal contributions.
Instead, I’ve learned to scale by enabling others, by building trust, by communicating with clarity, and by investing in people.
And the truth is, the journey isn’t over. Each new stage of leadership requires unlearning old habits and embracing new ones. But that’s what makes it worth it.
If you’re an IC considering leadership, my advice is simple: embrace the discomfort. That’s where the growth and the real scale happens.