I've led frontend teams of 3 and teams of 13. I've managed developers in a startup agency in Bergamo, senior engineers at AXA Switzerland, and cross-functional squads at Migros and UBS. The team sizes, tech stacks, and industries were different every time. But the patterns that make teams succeed? Those are remarkably consistent.
This isn't a post about Agile ceremonies or OKRs. It's about what I've actually seen work when your job is to make a group of frontend developers more effective than the sum of their parts.
Technical Vision Without Dictatorship
The biggest trap for technical leads is becoming the bottleneck. You have opinions, you have experience, and you can probably architect the solution faster than anyone on your team. But if every decision flows through you, you've created a single point of failure — and you've robbed your team of the growth that comes from making decisions themselves.
At AXA, when I founded the Style Guide team and built a cross-framework component library with Web Components, I didn't design every component myself. I set the architectural direction — Web Components for framework agnosticism, a clear API contract pattern, accessibility as a non-negotiable — and then let engineers own their components end-to-end. The result was better than what I would have built alone, because different developers brought perspectives I hadn't considered.
My approach: define the boundaries and constraints clearly, then give maximum freedom within those boundaries. At UBS, where I manage 13 frontend developers across different areas, I set the patterns for how our applications should be structured, how state should flow, and how we handle shared concerns. But within those guardrails, each squad makes their own implementation decisions.
Code Review as Mentorship
Code review is the highest-leverage activity a tech lead has. Not because it catches bugs — your tests should catch bugs — but because it's a one-to-one teaching moment with immediate, concrete context.
I review code differently based on who wrote it. A junior developer gets detailed feedback on patterns and principles. A mid-level developer gets questions that push them to think about edge cases they missed. A senior developer gets architectural discussions about trade-offs.
The key is to never just say "change this." Always explain why. "This creates a re-render on every state change because the object reference changes — consider useMemo here" teaches something transferable. "Use useMemo" teaches nothing.
I sometimes encouraged reviewers to leave a "learning comment" alongside their feedback — not a change request, just an observation about something interesting in the code, a pattern worth knowing, or a potential improvement for next time. It helped shift reviews from a pure gatekeeping exercise toward knowledge sharing.
Hiring and Onboarding
The team you build determines the software you ship. I've hired and onboarded developers across multiple countries, and the single most important trait I look for isn't framework knowledge — it's the ability to think like an engineer.
What does that mean in practice? I want people who aren't fanboys of any particular technology. React, Angular, Vue, Svelte — they're all tools, and a good engineer picks the right tool for the right job. When someone tells me their stack is "the best" without qualifying for what, that's a red flag. When someone can explain why they'd choose one approach over another depending on the constraints — team size, timeline, existing infrastructure, long-term maintainability — that's who I want on my team.
I can teach someone React in a month. I can't teach them to evaluate whether a library is worth adding, whether a pattern will scale, or whether an abstraction serves the team or just serves their ego. These are judgment calls that come from experience and intellectual honesty.
For onboarding, I use a graduated approach: week one is reading code and asking questions, week two is small bug fixes with paired review, week three is a small feature. By week four, most developers are contributing meaningfully. The key is making it safe to ask "stupid" questions — because in my experience, the "stupid" question is usually pointing at something the team has been ignoring.
Technical Debt is a Conversation, Not a Backlog
Every team I've joined had a "tech debt" backlog that nobody touched. Tickets labeled "refactor X" or "upgrade Y" that were perpetually deprioritized because they didn't deliver visible business value.
My approach is different: tech debt is addressed alongside feature work, not instead of it. If you're building a feature in a module that has debt, you clean up that module as part of the feature work. Boy Scout Rule at the module level.
At Vontobel, when building the markets platform, we had a legacy CMS integration that was painful to work with. Rather than creating a "refactor CMS layer" epic that would never get staffed, we improved the integration incrementally — every feature that touched CMS data left that layer slightly cleaner. Within two quarters, the integration was solid, and we never had to justify a "tech debt sprint" to the business.
This requires discipline from the team lead: you need to scope feature work to include the cleanup and defend that scope in sprint planning. "This feature is 5 points, not 3, because we need to fix the data layer it depends on" is a conversation I've had hundreds of times.
The Human Side
The hardest part of leading developers isn't the technology — it's the people. Developers have egos (myself included). They have off weeks. They disagree with each other and with you. They leave for other companies. They burn out.
What I've learned: transparency builds trust faster than anything else. Share the reasoning behind decisions, even uncomfortable ones. If a project is behind schedule, say so and explain the plan. If you made a wrong call, own it publicly. Your team will follow the standard you set.
At UBS, I focus heavily on what I call "cross-area cohesion" — making sure that developers working in different parts of the product feel like one team, not isolated squads that happen to share a repo. Regular cross-team code reviews, shared architectural decision records, and rotating pair programming across boundaries all contribute to this.
Leading a frontend team is about creating an environment where good decisions emerge naturally — where developers have the context, the tools, and the psychological safety to do their best work. The technical part is important, but it's the easier half.