My journey to becoming an engineering manager

I started coding when I was twelve. Back then, it was simply a hobby: a way to make things and follow my curiosity. I did not have a career plan, and I certainly did not imagine becoming an engineering manager.

That hobby eventually became my profession. The path from there to management was not a single decision or a clean break from engineering. It was a gradual widening of what I cared about and what I wanted to be responsible for.

A hobby became a profession

I began my professional career as a full-stack engineer. That gave me a broad view of how software comes together, but I kept finding more questions in the frontend. The deeper I went, the more curious I became about JavaScript, browsers, and the layers of engineering behind an interface that appears simple to the person using it.

I enjoyed complex technical problems then, and I still do. There is a particular satisfaction in understanding why a system behaves the way it does and finding a solution that makes it clearer, faster, or more reliable.

Specializing in frontend engineering gave that curiosity somewhere to go. It taught me the value of depth and helped me build a stronger technical foundation. But it never replaced my interest in the product as a whole. I cared about the code, and I also cared about why we were writing it, who it was for, and whether it solved the right problem.

Side projects kept the whole product in view

Alongside my professional work, I built countless side projects. A few became small businesses. Most did not, but each one gave me a reason to learn something I could not explore in the same way at work.

When you build a product yourself, the boundaries between disciplines disappear. You move from an idea to an interface, from implementation to release, and from a technical decision to its effect on the person using the product. There is nowhere to hand off the difficult or unfamiliar parts.

That made building my own products an important part of my education. Side projects kept me close to code, but they also made me think beyond it. They reinforced something I had been feeling for a while: I loved engineering, but I was increasingly interested in the conditions around the engineering too.

Responsibility came before the title

As I gained experience, I noticed that I enjoyed taking responsibility. I did not want to control every decision; I cared about what happened beyond my own tasks.

I liked being part of a team that learned together. I liked helping the people around me move forward. I found myself paying attention to whether teammates had the context they needed, whether it felt safe to ask a question, and whether the way we worked was stable enough for people to do their best work.

I became opinionated about people leadership before I had a formal management role. I believed people needed a safe and stable environment to do their best work, and I kept finding myself trying to build one.

My leadership style is built around five things: trust, autonomy, impact, accountability, and fun. I want people to have room to own their work, understand why it matters, and be accountable for the outcome, while still enjoying the work and the people around them.

The problems that interested me were getting wider. I still wanted to solve engineering problems, but solving only the technical part no longer felt sufficient. I wanted to help shape the system in which a team solved those problems together.

Tech lead was the bridge

A formal tech lead role gave me my first sustained experience of that wider responsibility. The position was roughly half hands-on engineering and half people management.

I enjoyed that balance. It confirmed that I wanted to take on broader responsibility, not only larger technical problems.

The role also changed how I understood impact. As an individual contributor, I could point to the code I wrote or the problem I solved. As a lead, some of the most valuable work was less direct: creating context, improving a conversation, helping someone make a decision, or removing a source of friction for the team.

That did not make the work less technical or less concrete. It meant that my contribution increasingly showed up through other people and through the quality of the environment around them.

Communication became part of the craft

Throughout this period, I worked deliberately on my communication skills. I kept asking myself how I could explain an idea more clearly, manage up more effectively, translate a technical subject for a non-technical audience, and choose better communication tools for a team.

This was not separate from engineering. A technically sound idea has limited value if nobody can understand it, challenge it, or act on it. The larger the group involved, the more the quality of the outcome depends on shared context.

I began to think about communication as something to design for the audience and the decision. What was obvious to me only because I had been close to the problem? What did other people need before they could act?

I am still learning this. Communication is not a skill you finish. Every new team, stakeholder, and situation exposes another assumption and asks for a different kind of clarity.

The scope changed again

Over the last two years, while I was leading the frontend unit, an internal opportunity came up. I had been actively looking for a way to take the next step, and I was offered an Engineering Lead position. That became my formal move into engineering management.

The new role came with a different set of expectations. People management became a larger part of the job. So did stakeholder management and working with a cross-functional team in an enterprise environment. I had to work with people from different backgrounds and connect their perspectives on the same problem.

The investment I had made in communication began to pay off. Explaining technical trade-offs to non-technical partners, bringing different perspectives into the same conversation, and managing expectations upward were no longer supporting skills. They were central to the role.

Staying technical, differently

I enjoy management and the path I am on. At the same time, I still care deeply about the technical side of my work and make an effort to keep it current.

I am still working out the right balance. I want to understand the technical decisions and trade-offs facing the team without getting in the team’s way. The role gives me a different relationship with the technical work, but my curiosity remains the same.

I still build side projects to stay technically current. That practice keeps my judgment grounded while leaving room for the engineers I lead to own their work.

We can now solve an amazing number of coding problems with LLMs. I find that genuinely exciting. But the underlying engineering problems remain. Someone still has to understand the context, make trade-offs, and judge whether the result is right for the system.

That is why I believe staying technically grounded will be more important than ever for engineering managers. As LLMs produce more of the code, we need enough depth to ask good questions and make sound engineering decisions.

Where I am now

Looking back, I did not leave engineering for management. I followed the parts of engineering work that gave me the most energy until the shape of the role changed around them.

I still enjoy solving difficult problems with code. Now I also get energy from helping a team learn and solve problems together.

I am happy with the path, still learning, and still building.