From Software Engineer to Technology Leadership

For a long time, my definition of a good day at work was simple: did the code work.

I started my career the way most engineers do — heads-down, solving one technical problem at a time. A module to build. A bug to fix. A hospital system integration that needed to go live without breaking anything. The scope was clear, the feedback was immediate, and success was easy to measure. Either it worked, or it didn't.

Somewhere along the way — through leading a team, then a project, then a technology function — that definition of a good day quietly changed. And it took me a while to notice.

The first shift: from writing code to being responsible for it

The transition doesn't happen the day you get a new title. It happens earlier, usually the first time someone on your team gets stuck and looks at you instead of the problem.

As a senior engineer, I was still measured by what I personally built. As a team lead, I was suddenly measured by what my team built — including the parts I never touched. That is a strange adjustment. You stop being the person who solves the hardest technical problem in the room, and you start being the person who makes sure the right person is solving it.

Your job stops being about your own output the moment other people's output becomes your responsibility.

I didn't fully appreciate this at first. I kept trying to stay the best engineer on the team, when what the team actually needed was someone removing blockers, setting direction, and protecting their time.

The second shift: from technical decisions to business conversations

The next change was less about people and more about language.

Early on, my conversations were almost entirely technical — architecture choices, database design, which framework made sense for a given problem. Good conversations, but narrow ones.

As I moved into project and program leadership, I found myself in rooms where the technical decision was the easy part. The harder conversation was explaining why it mattered — to a hospital administrator waiting on a go-live, to a business stakeholder asking why a platform migration was worth the disruption, to leadership deciding where the next crore of technology investment should go.

I had to learn a different vocabulary. Not simpler — different. Outcomes instead of implementation. Risk instead of edge cases. Timeline against business impact, not just technical complexity.

Nobody outside the technology team is impressed by how something was built. They care about what it made possible.

The third shift: from doing the work to owning what happens around it

Leading a technology function — as I do now — is a different job altogether from anything I trained for as an engineer. Nobody teaches you vendor governance in a computer science degree. Nobody teaches you how to hold a CAPEX conversation, or how to keep a release calendar sane during a peak-traffic campaign, or how to say no to a request without damaging a relationship you'll need again next quarter.

A lot of this role is invisible to the people who only see the finished platform. It includes:

• Deciding which of ten "urgent" requests actually deserves the team's attention this week.
• Holding a vendor accountable without losing technical ownership of the outcome.
• Making a budget case for infrastructure work that has no visible feature attached to it.
• Protecting the team's ability to do good engineering while the business asks for speed.
• Explaining a production incident to people who don't want an explanation — they want confidence it won't happen again.

None of this shows up in a demo. All of it determines whether the technology function is actually trusted by the rest of the business.

What I had to unlearn

The hardest part of this journey wasn't learning new skills. It was unlearning old instincts.

As an engineer, being right was the goal. As a leader, being right matters far less than the team moving in the right direction together — even if that means a decision I wouldn't have personally made, made by someone I trust with the context to make it.

As an engineer, depth was the whole job. As a leader, depth has to make room for breadth — enough technical grounding to ask the right questions, without needing to be the smartest person on every specific topic in the room.

I had to trade being the person with the best answer for being the person who builds a team capable of finding it.

That trade doesn't come naturally to most engineers. It didn't come naturally to me. I still notice the pull to jump into a technical debate and solve it myself, and I still have to consciously step back and let the team own it.

What stayed the same

Not everything changed. The instinct that made me a decent engineer — wanting to understand how something actually works before trusting it — is the same instinct that makes me a better technology leader today. I still want to understand the architecture. I still read the incident report line by line. I still ask "why" until the answer is real, not just plausible.

That grounding is, I think, the actual advantage of coming up through engineering rather than around it. I can't be talked past on technical substance, even while operating at a level where most of my day is spent on people, priorities, and business outcomes rather than code.

What I would tell the engineer I used to be

If I could go back and talk to the version of myself who just wanted the code to work, I would tell him this: the shift to leadership isn't a promotion away from engineering. It's a widening of what you're responsible for engineering — not just systems, but teams, decisions, and outcomes.

The tools change. The judgment you built solving hard technical problems doesn't go away — it just gets applied to a bigger, messier, more human set of problems.

And on the good days, it still feels a lot like solving something that actually matters.