Article · 2 min
What changed when I stopped writing only code
My first promotion to lead taught me that shipping more code wasn't the point anymore. The multiplier is systems and people, not heroics.
Over five and a half years at Softwow I went from Frontend Developer to Frontend Tech Lead to Technical Lead. Same company, three altitudes. The promotions changed my title twice, but what they really changed was the definition of my job — and the second change is the one worth writing about.
The shift nobody explains up front
As an IC, success is legible: the features you ship. I joined building client frontends from scratch, and for a while, getting better meant shipping better.
The first promotion came from doing things that weren’t strictly my tickets — taking ownership of standards, reusable components, and delivery quality. And with it, the job quietly inverted. Success stopped being my output. The work became: analyzing client requirements, proposing architecture, choosing technologies, distributing work, unblocking developers, reviewing implementations, mentoring juniors. Shipping more code than anyone else was no longer the point — making sure the project succeeds technically was.
The levers that compound
As Technical Lead, leading distributed teams across concurrent projects, I learned that a lead’s leverage lives in a small number of changes that keep paying after you make them:
- CI/CD adoption across client projects — deployment frequency went up about 30%.
- Engineering standards and reusable components — so quality stops depending on who happens to be on the project.
- Systematic code review — used as teaching, not gatekeeping.
- Mentoring — handing juniors smaller projects and guiding them through the hard parts rather than doing it for them. Doing it for them is faster exactly once.
None of these are heroic. That’s the point. The heroic version of leadership — the lead who personally rescues every project — doesn’t scale and doesn’t teach anyone anything.
Staying hands-on, honestly
Through all of it I kept writing code, and I still consider that essential to how I lead: proposing architecture you won’t touch is a different (and worse) job. But I’ll be honest about the boundary too — I’ve never carried formal people-management: hiring, performance reviews, compensation. That’s my growth edge, and something I’m genuinely interested in.
The shape I know works, because I’ve lived it: technical leadership at the point where code leadership and people leadership meet — architecture, technology choices, unblocking, review, mentoring — while staying close enough to the code to keep your judgment sharp.