What I Learned Leading a Frontend Team of 4+ Engineers

The job changes the moment you're not the only one writing the code

Leading a team of 4+ engineers on SaaS and e-commerce products taught me things no amount of solo coding ever would. Here's what actually stuck.

Code review is a teaching tool, not a gate

Early on, my reviews were mostly "approve" or a list of required changes. Over time I realized review is the highest-leverage teaching moment available — it's specific, it's tied to real code the engineer just wrote, and it happens right when the context is fresh. I started explaining why, not just what, and asking questions instead of dictating fixes when the engineer was capable of finding a better answer themselves.

Standards only work if they're written down

"We just know how we do things" doesn't scale past two or three people. A shared component library and clear architecture patterns turned tribal knowledge into something a new engineer could actually learn from, instead of absorbing slowly through months of review comments.

Trust is built in small decisions, not big speeches

The biggest lever for team output wasn't a process change — it was deciding which decisions I needed to make and which ones I could hand to the engineer closest to the problem. Over-controlling every technical choice slows a team down and quietly signals you don't trust them. Under-guiding leaves juniors stuck. The actual skill is knowing which is which, case by case.

Deploy time is a team health metric, not just a tech metric

When we cut deploy time by 25% through shared libraries and better architecture, the bigger win wasn't the number — it was that engineers stopped dreading feature work that touched shared UI. A slow, fragile deploy process quietly erodes morale in a way that's easy to miss until you fix it.

What I'd tell someone about to lead their first team

• Your job is now the team's output, not your own commits — measure yourself accordingly
• Write down the patterns you want followed; don't rely on osmosis
• Spend real time in code review — it compounds faster than almost anything else
• Protect the team's focus as fiercely as you protect your own

Handling disagreement without becoming a bottleneck

A frontend team lead will eventually face a technical disagreement between two capable engineers who are both partly right. Early on, I resolved these by just deciding myself, which was fast but quietly trained the team to stop debating and just wait for my answer. Now, I ask both engineers to write a short comparison of trade-offs before I weigh in — often they converge on an answer themselves, and the team gets better at resolving disagreements without me every time.

Protecting focus time is a leadership responsibility

Engineering leadership isn't only about code and review — it's also about shielding the team from constant context-switching. A team fielding ad hoc requests all day produces worse code than one with protected blocks of uninterrupted time, even at identical skill levels. Part of my job became triaging incoming requests so engineers weren't the ones absorbing that interruption cost directly.

Junior engineers need different feedback than senior ones

The same code review comment lands differently depending on experience level. A senior engineer can take "this could be cleaner" and run with it. A junior engineer often needs the why spelled out explicitly, plus a concrete example, or the feedback doesn't generalize to their next piece of code. Calibrating feedback style per person, not applying one blanket review style to everyone, made reviews noticeably more effective across the team.

What I'd measure if I were starting over

If I could redo my first year leading a team, I'd track fewer vanity metrics (lines of code, tickets closed) and more of the metrics that actually predicted team health: how often engineers were blocked waiting on review, how often the same type of bug recurred, and whether junior engineers were shipping independently over time. Those numbers told a far more honest story than velocity charts ever did.