From Developer to Architect: What Actually Changed

I went from developer to team lead to program architect on a large .NET and Angular program. The job titles changed less than the job did. Here is what surprised me.

Over five years on enterprise software for the US mortgage industry, I went from developer to team lead to architect on a program with more than thirty developers. On paper it looks like a straight line. In practice every step was a different job, and I was not ready for most of the differences.

As a developer, the code was the output

As a developer, a good day meant a feature shipped and a bug fixed. The feedback loop was short and clear: it works, or it does not.

The habits that made me good at that, going deep, finishing things myself, knowing the code better than anyone, were exactly the habits I had to partly unlearn later.

As a lead, other people became the output

The first surprise of leading a team was how little time I had for code. One-on-ones, planning, unblocking people, reviewing, answering the same question for the third person that week.

The mistake I made early was trying to stay the best coder on the team at the same time. It does not work. Either the team waits for you, or you work evenings to keep up. The shift is accepting that your job is now to make five people productive, not to be the most productive one.

As an architect, decisions became the output

Architecture turned out to be less about diagrams and more about decisions that are expensive to reverse. Which service owns which data. How systems talk to each other. What we standardise on, and what teams can choose themselves.

A few things I learned the hard way:

The best design nobody follows is worse than an average design everyone does. Adoption is part of the architecture.
Write decisions down, with the why. Six months later nobody remembers why we chose a queue over a direct call, and the decision gets undone by accident.
Stay close enough to the code. An architect who has not opened the codebase in a year starts designing for a system that no longer exists.

What did not change

Some things carried through every role. Understanding the business problem before the technical one. Being honest about what you do not know. Caring about the person who will maintain the code after you.

Those mattered as a developer, and they matter more the higher you go, because your mistakes get multiplied by everyone who builds on top of them.

If you are about to make the jump

Expect to feel less productive for a while. You will ship less code and spend more time talking, and it will feel like you are doing less. You are not. You are just measuring the wrong output.

What was the hardest part of your first step away from pure coding?