First Steps as a Team Lead: Rules I Wish I'd Known
Every leadership book gives you the same ten rules. Most of them are right. All of them are incomplete. What I'd tell myself before stepping into the role.
Every leadership book gives you the same ten rules. Do 1:1s. Delegate. Stop coding. Listen. Build psychological safety.
Most of them are right. All of them are incomplete.
I’ve given this talk at multiple conferences, published a Manager README that I hand to every new team, and still managed to learn something new each time. The rules below aren’t the standard playbook. They’re the corrections I had to make after following it.
Outcomes over output
This is the one principle that holds everything else together. Ownership means the result, not your part in it. Not “I wrote my code and it works” — but “the feature shipped, the user problem is solved, and the team knows what we learned.”
Jeff Bezos frames it as one-way versus two-way doors. A two-way door — reversible, low cost — you walk through fast and course-correct. A one-way door — irreversible, high stakes — you slow down and get it right. Most first-time leads get this backwards. They agonise over two-way doors and sprint through one-way ones.
In practice: run small experiments over debating hypotheticals. Choose the simplest path that could work. Measure what shipped, not who typed it. If you find yourself counting pull requests or lines of code, you’re managing output. Stop. Ask instead: did the outcome move us forward?
I learned this the hard way. At one company, we measured output — commits, tickets closed, PRs merged. The dashboard looked healthy. But the team was demotivated, the work felt hollow, and within six months the senior engineers had left. We’d optimised for the scoreboard and lost the players. The metrics were green. The outcome was a gutted team.
Camille Fournier’s The Manager’s Path is the canonical reference here, and it’s good. But the gap she doesn’t fill — the gap none of the books fill — is what to do when your intuition says one thing and the data says another. My rule: trust intuition, but only if it’s deeply informed. If you can’t articulate why your gut says no, you haven’t earned the right to override the evidence. Go gather more.
Rigour isn’t micromanagement
“Don’t micromanage” is the advice everyone gives and nobody finishes. Micromanaging tasks is toxic — hovering over someone’s implementation, rewriting their code after hours, prescribing how to solve a problem you’ve already delegated. That kills autonomy and erodes trust.
But rigour on standards isn’t micromanagement. It’s leadership.
The test is simple: are you checking how someone works, or what they delivered? The first is micromanagement. The second is quality assurance. The people who report to you will feel the distinction long before you articulate it.
Start with high trust — assume competence, give autonomy, don’t hover. But verify proportional to risk. In structural engineering, every weld on a bridge gets inspected. Every bolt on a skyscraper gets torqued to spec. The engineer who designed it isn’t offended — they expect it. The stakes demand it. Software is the same, just less visible. A CSS change gets a glance. A database migration gets a thorough review. A security-critical feature gets a deep audit, every time, regardless of who wrote it. That’s not distrust. That’s professionalism. And as people prove their judgment, oversight decreases. The goal is earned autonomy — the trajectory should always point towards less oversight, not more.
The areas where rigour is non-negotiable? Security. Compliance. Data handling. Money. Architecture decisions in the first 90 days. The PRD before anyone writes a line of code. These are yours to own — not because you don’t trust your team, but because the cost of getting them wrong is asymmetric. A bad variable name costs you a rename. A bad security posture costs you a breach. A bad architecture in month one costs you a rewrite in month six. Evolutionary architecture reduces that risk — but you still need the judgment to know which decisions are load-bearing.
I tell my teams: mistakes happen, including mine. What matters is transparency, learning, shared responsibility over blame. But the team that understands why certain things get more scrutiny — and sees you apply the same standard to your own work — will respect it. The team that sees you wave through your own commits while nitpicking theirs won’t.
Patrick Kua’s Talking with Tech Leads captures this well — the role exists at the intersection of technical judgment and people leadership. You can’t abdicate either one.
Stay technical in the right places
“Stop coding” is the most common advice for new leads. It’s also the most misunderstood.
Stop coding features on the critical path. Yes. You’ll block your team, create bottlenecks, and signal that you don’t trust them to deliver. But don’t stop being technical. Build tools. Write automation. Prototype architecture spikes. Contribute to open source. Keep your hands in the code — just not in the code that ships on Tuesday.
Charity Majors calls this the engineer/manager pendulum: the best managers are recent practitioners, and the best practitioners have done management. The moment your team can’t trust your architecture opinion — because you haven’t touched a codebase in eighteen months — you’ve lost your most valuable asset. You’re not a manager who used to be technical. You’re a technical leader who also manages.
The balance shifts with seniority. Roughly 60/40 technical as a team lead, trending towards 10/90 as a CTO — the exact numbers depend on the company, the team, and the week. But it should never hit zero. The day you stop understanding the work is the day your judgment stops being useful.
Safety for disagreement, not comfort
“Build psychological safety” is in every leadership article written since 2015 — probably earlier, but I haven’t checked. Most of them describe it wrong.
Safety doesn’t mean comfort. It means your team can say “I think this is the wrong approach” without fear of retaliation. It means your most junior engineer can challenge your design in a review and be taken seriously. It means disagreement is expected, not tolerated.
I write it into my Manager README: “Speak up early and honestly. Disagree if needed. Alignment stems from clarity.” That’s not a platitude — it’s an operating principle. If nobody pushes back in a design review, that’s not consensus. It’s silence. And silence ships bad software.
Give your sceptic teeth. Every team needs someone whose default is “are we sure?” — the person who asks whether the event-driven rewrite is justified or whether a batch job would do, who questions whether we need a new service or whether a library would suffice. If that person doesn’t exist, create the role. If they exist but get overruled every time, that’s a culture problem — and it’s yours to fix.
The common thread is simple. Manage outcomes, not output. Review what matters, not everything. Stay close enough to the work that your judgment means something — without doing the work yourself.
Every leadership book will give you the rules. What they won’t give you is the corrections. Those, you earn.