The Three Mistakes Every First-Time Engineering Leader Makes
Moving into a leadership role is harder than it looks — not because the job is complicated, but because the intuitions that made you a great engineer work against you.
When a strong engineer becomes a team lead or manager for the first time, they bring all the habits that made them excellent at their previous job. And almost immediately, those habits get them into trouble.
I've made these mistakes. I've watched almost every first-time leader I've ever mentored make them. They're not character flaws — they're the predictable result of applying the wrong mental model to a new role.
Mistake 1: Optimizing for your own output
Engineers get promoted because they ship things. Their metric is throughput. They fix the bug. They write the feature. They review the PR and leave it better than they found it.
When you become a leader, your job is to make everyone else on your team more effective. Not to be the best individual contributor on the team — to multiply the output of the whole team.
This is genuinely hard to internalize. The fastest short-term fix is almost always to do the thing yourself. The right long-term move is to help someone else do it, which is slower, messier, and less satisfying in the moment.
The first-time leader who jumps in and writes the code is optimizing for the wrong variable. They feel productive. Their team is learning helplessness.
Mistake 2: Confusing having opinions with setting direction
Technical leaders have strong opinions. They've accumulated them through years of building real systems. When they move into leadership, those opinions often become mandates.
"We're using Postgres, not Mongo." "We're not adopting microservices yet." "We rewrite the auth layer before we build the next feature."
Sometimes these calls are right. Often they're right. But the way they're made matters enormously. A decision handed down from authority is brittle. A decision that the team understands and bought into is durable.
The difference between a leader who sets direction and one who dictates direction is what happens when they're not in the room. Direction sticks. Mandates require enforcement.
Mistake 3: Treating people problems like engineering problems
Engineering is largely about deterministic systems. Given inputs, produce outputs. Debug the anomaly. Refactor toward clarity. Find the root cause.
People are not deterministic systems. A person who seems disengaged might be dealing with something outside of work. A person who's not shipping might be blocked in a way they don't know how to articulate. A person who's difficult in meetings might be the best signal you have about a real organizational dysfunction.
The first-time leader trained on engineering intuition wants to find the root cause, apply the fix, and verify the outcome. Sometimes that works. More often, the right move is to slow down, ask open-ended questions, and listen for what isn't being said.
None of these are obvious going in. They're all obvious looking back.
If you're moving into a leadership role, or coaching someone who is, I'd suggest treating the transition as a genuine context switch — not a promotion that comes with the same job plus some extra responsibilities. The job is different. The intuitions are different. The satisfaction, when you figure it out, is different too.