# What Leading a 4-Person Engineering Team Actually Looks Like I became an engineering lead without a transition plan. One week I was an individual contributor shipping features. The next I was responsible for four engineers, client deadlines, sprint planning, code reviews, and making sure nothing fell through the cracks. Nobody handed me a playbook. I figured it out by making mistakes, some of which cost us real time and real credibility. This is what I wish I'd known in the first six months. * * * ## Mistake 1: I Kept Writing Code Like an IC The first instinct when you become a lead is to keep doing what made you good — writing code. It feels productive. It's measurable. And for the first few weeks, it's fine. Then sprint planning gets skipped because you're heads-down on a feature. A junior engineer is blocked for two days because you're in flow and didn't check in. A client requirement gets misinterpreted because nobody translated it properly into a ticket, and you weren't in the room when it was discussed. I was individually productive and collectively a bottleneck. The mindset shift that fixed it: your output is no longer lines of code. It's the velocity and quality of the team. A day spent unblocking three engineers, clarifying requirements, and reviewing PRs carefully is a more productive day than a day spent shipping a feature yourself — even if it doesn't feel that way. I still write code. I own specific modules, handle architectural spikes, and stay close enough to the codebase to do meaningful reviews. But I no longer treat it as the primary metric of a good day. * * * ## Mistake 2: I Assumed Requirements Were Clear When They Weren't Client requirements arrive in many forms — a Notion doc, a Slack message, a 45-minute call, a Figma file with comments. Early on, I'd take whatever arrived, mentally fill in the gaps, and write tickets based on my interpretation. Engineers would build against those tickets. Then the client would see the result and say "that's not quite what we meant." Not because the engineers built it wrong — they built exactly what the ticket said. The ticket was wrong. The gap between what a client says and what they mean is almost always larger than it looks. Now before any ticket gets written, I ask three questions: What does success look like for the user? What's explicitly out of scope? What's the edge case nobody's thought about yet? The answers to those three questions change almost every requirement I've ever received. Writing tickets well is an underrated engineering skill. A well-written ticket — clear acceptance criteria, explicit non-goals, a definition of done — reduces back-and-forth, reduces misbuilds, and makes code review faster because the reviewer knows exactly what to evaluate against. * * * ## Mistake 3: I Gave Feedback Only in Code Review For the first few months, my feedback to engineers lived almost entirely in PR comments. Inline notes on code quality, architecture choices, naming, test coverage. Detailed, sometimes lengthy, delivered asynchronously after the fact. This is a bad feedback loop. By the time someone gets a PR comment, they've already spent hours building in the wrong direction. Fixing it means rework, which is demoralising and wastes time. And async text-based feedback strips all the nuance — what reads as a sharp critique in a comment lands completely differently in a five-minute conversation. Two things changed this. First, I started having brief design conversations before implementation, not after. Five minutes discussing the approach before someone writes 200 lines of code saves hours of rework. Second, I made feedback in code review additive rather than corrective — pointing out what's working as explicitly as what isn't, so engineers understood their own strengths and weren't only receiving criticism. PR reviews got shorter. Rework dropped significantly. The quality of the code that arrived for review improved because engineers were better calibrated before they started. * * * ## Mistake 4: I Didn't Protect the Team's Focus Clients communicate directly with engineers in Slack. A question here, a small change request there, a "quick clarification" that turns into a 30-minute tangent. Each one feels minor. Collectively they destroy deep work. I underestimated how much this mattered early on. An engineer context-switching three times in a morning has effectively lost that morning. The cost isn't the interruption — it's the recovery time after each one. Now client-facing communication routes through me first. Engineers aren't hidden from clients — they're in calls, they demo features, they answer technical questions. But they're not on the receiving end of every ad-hoc request. I take the interrupt, translate it into a ticket if it needs work, and the engineer gets a clean, scoped ask instead of a half-formed request with missing context. This also benefits clients. They get faster, clearer responses than they did when questions landed in a channel and waited for whoever was least busy to notice. * * * ## Mistake 5: I Waited Too Long to Have Hard Conversations Two situations in the first six months where I noticed a problem — a deadline at risk, a quality issue on a specific engineer's output, a communication pattern that was creating friction — and said nothing for too long. I told myself I was gathering more data. I was avoiding discomfort. Both situations got worse before I addressed them. The conversations I eventually had were harder because the issues had compounded. And both engineers later told me, separately, that they'd have preferred to hear it earlier. Feedback given early is a gift. Feedback withheld until it becomes an incident is a problem. I learned to say something within a day or two of noticing an issue, directly and without softening it into ambiguity. "I noticed the last three PRs have had recurring issues with error handling — let's talk about it" is better than waiting until a client flags a bug. The conversation doesn't have to be long. It doesn't have to be formal. It just has to happen. * * * ## Mistake 6: I Didn't Invest in Onboarding When a new engineer joined the team mid-year, I handed them a GitHub repo link, a Notion doc with some context, and told them to ping me with questions. I was in the middle of a delivery crunch and didn't have time to do it properly. They were unproductive for three weeks. Three weeks of context-gathering through trial and error, confusion about conventions, and questions that interrupted everyone else on the team. A proper onboarding doc — architecture overview, environment setup, coding conventions, how we write tickets, what good looks like on this team — takes half a day to write and pays back immediately. Every engineer who joins after spends less time confused and less time interrupting others. I wrote one after that experience. It's now the first thing a new engineer gets. * * * ## What the Job Actually Is Engineering leadership at a small team isn't management in the traditional sense. There's no org chart to navigate, no performance review cycles, no HR processes. It's closer to: make sure the right things get built correctly, by people who have what they need to do their best work. The mistakes above all share a root cause — I was optimising for my own productivity and comfort rather than the team's. Staying in code because it felt familiar. Avoiding hard conversations because they were uncomfortable. Skipping onboarding because I was busy. The job got easier when I accepted that my discomfort is often the signal that I'm doing it right. * * * Six months in, I was a better lead than I was at the start. Twelve months in, I was significantly better than six months. The gap between where I started and where I am now is almost entirely made up of mistakes I don't make twice. That's probably how it works for everyone.