Lessons from leading frontend
A few things a decade of frontend work and years of leading it taught me, mostly about leverage and people, not code.
I have led frontend on insurtech platforms and, now, on a multi-app product. The lessons that stuck are rarely about a framework. They are about leverage, communication, and the boring discipline that lets a team move fast without falling apart. Here are the ones I would hand to a younger version of myself.
Your job stops being “write the most code”
As an individual contributor, your output is your code. As a lead, your output is the team’s. The highest-value hour is often not the one I spend coding, it is the one I spend unblocking someone, clarifying a fuzzy requirement, or setting a convention that saves everyone an argument later. It took me a while to stop measuring my day by lines written.
Big changes win by staying shippable
The most useful thing I ever led was a Vue 2 to Vue 3 migration, and the lesson generalizes. Large changes do not succeed because the plan is clever. They succeed because they are broken into slices small enough that the product keeps shipping the whole time and nothing is ever broken for long. “We can pause here and be fine” is a requirement, not a luxury.
Invest in the foundation, it is the team’s multiplier
A design system, shared types, consistent tooling: these feel like overhead until you watch a small team run several apps off them. A lead’s leverage is not the features they personally build, it is the foundation that makes everyone else faster. Time spent making the common path easy pays back every single day.
You are the bridge, so communicate like it
The frontend lead sits between design and the backend. Half the job is translation: turning a design into components, turning product needs into a clear API contract, and pushing back early when something will not work. The best technical decision, communicated badly, still fails. Clear contracts, especially around the API, prevent more bugs than any clever code.
Make tradeoffs explicit, and revisit them
Every real decision is a tradeoff: Vite over Next, one abstraction over another, this pattern over that one. The mistake is pretending there is one right answer forever. I try to write down why we chose what we chose and what would make us change our minds. Decisions age, and the ones you cannot explain later are the ones that hurt.
Consistency beats cleverness
A team moves fast when the code is predictable. A slightly boring convention that everyone follows beats a brilliant pattern only one person understands. As a lead, defending consistency (in review, in the design system, in how we structure things) is worth more than being the cleverest person in the codebase.
Protect quality with process, not heroics
Speed without guardrails becomes debt, and debt is paid by the whole team. Tests, review, and a real definition of done are not bureaucracy, they are what let us move fast next month too. The goal is to make the safe path the easy path, so quality does not depend on anyone being a hero on a given day.
The throughline
Leading frontend turned out to be less about knowing the most and more about raising the floor: better foundations, clearer communication, decisions that can be explained, and quality that does not rely on luck. The code still matters. It just is not the main thing anymore.