I was promoted to tech lead at the startup in early 2020. The team was five engineers, including me. My previous experience managing people: none, unless you count mentoring a couple of interns.

The first month was humbling. The second month was better. By the third month I had a clearer mental model of what the role actually required and how it differed from what I’d been doing before.

What Changed Immediately

My productivity metric changed. As an IC, a good day was shipping code or unblocking a hard technical problem. As a lead, a good day was the team shipping code. These are not the same thing. There are days as a lead where you write almost no code and the team has an exceptionally productive week — that’s a good day, even though it doesn’t feel like one.

The adjustment: stop measuring your value by your own output. Measure it by the team’s output and health.

My calendar filled up. 1:1s, planning discussions, cross-team syncs, hiring interviews. I went from 2–3 meetings per week to 8–12. The deep-focus time I’d relied on for hard technical problems became scarce.

The adjustment: protect blocks of deep focus time aggressively. Batch meetings on fewer days. Learn to context-switch faster between shallow and deep work (or accept that you won’t, and budget accordingly).

People started waiting for me. I was used to unblocking myself — if I had a question, I’d figure it out or search for the answer. Engineers on the team had a question → waited for my input → stopped if I was slow. The queue of things waiting on me became a critical bottleneck.

The adjustment: respond fast to unblocking requests, even if the response is “I’ll look at this in two hours.” Silence creates uncertainty.

What I Got Wrong in the First Month

I kept doing too much IC work. It felt good. I was fast at it. The team was slower on some tasks than I would have been. The temptation was to just take those tasks myself.

This is a trap. By doing the work myself, I prevented the team members from developing the skills to do it, created a dependency on me for those tasks, and consumed time I should have spent on lead responsibilities.

The correction: delegate more than feels comfortable. Accept that the output will be less polished than if you’d done it. Invest the time you save into code review and mentoring — the multiplier on the team’s ability over time exceeds the short-term quality gap.

I gave feedback too indirectly. When someone wrote code I thought could be better, I’d phrase it as “I wonder if we could…” or “have you considered…” rather than “I’d change this because X.” I thought I was being collegial. I was being unclear.

Engineers want clear feedback on their work. Vague suggestions are ambiguous — are you asking them to change it, or musing out loud? The correction: give direct, specific feedback. “I’d do this differently: [specific change], because [specific reason].” Trust people to take it professionally if you deliver it professionally.

I didn’t have 1:1s early enough. I thought 1:1s were for “issues” — I’d schedule them when something came up. It took me six weeks to realise they’re for relationship-building and information-gathering that makes everything else easier.

Once I started weekly 1:1s, I learned things about team morale and blockers that I’d been entirely unaware of. Not big problems — but the small frictions that erode motivation over time.

What Actually Made the Team More Effective

Removing blockers fast. The most valuable thing I did in month two was make it my personal mission to eliminate anything that slowed people down: access requests, unclear requirements, cross-team dependencies, tool problems. Every day I asked: what is each person blocked on right now? Then I went and fixed it.

Clarity on priorities. At a startup, the backlog is always longer than the capacity. Engineers making tradeoff decisions without clear priorities default to what seems technically interesting or what’s easiest to justify — not necessarily what the business needs most.

My job was to maintain a clear, shared understanding of what we were building, in what order, and why. When priorities were clear, the team made better autonomous decisions and I spent less time in alignment conversations.

Making decisions stick. Early on, I’d discuss a decision with the team, reach a conclusion, then find that the decision hadn’t propagated — different team members were still working from different assumptions.

The fix: write decisions down. After a discussion that produces a decision, send a follow-up message (Slack, email, ticket comment): “we decided X because Y, this affects Z, [name] is responsible for implementing.” This sounds bureaucratic. It prevented probably ten hours of rework across the quarter.

Technical context, not technical control. My strongest instinct was to review every technical decision carefully and push back when I disagreed. This doesn’t scale and it slows people down.

What scales: making sure everyone on the team has the context they need to make good decisions themselves. Architecture discussions, post-mortems, documentation of why things are the way they are. When the team has the context, they make decisions I’d make without me being in the loop.

The Things That Are Still Hard

After the first 90 days, these were still genuinely hard:

  • Performance conversations — telling someone they’re not meeting expectations, specifically and constructively
  • Prioritisation disputes — when stakeholders disagree about what the team should be working on
  • Knowing when to take something on yourself vs. when to wait for someone on the team to figure it out
  • Protecting team capacity from legitimate-sounding requests that don’t fit the current priorities

These are probably still hard after 90 months. The job of a technical lead is not to have solved these problems — it’s to navigate them thoughtfully, repeatedly, with more skill over time.

The career advice I’d give my pre-promotion self: the transition is real, the skills are different, and the discomfort of the first few months is normal. The engineering work doesn’t go away — but it becomes a smaller fraction of the job than you expect.