Managing technical teams: lessons from IC to engineering leader

Executive overview

Most engineers who become managers have never had a good manager themselves, and the tech industry's historical disdain for management made this worse. Good engineering management is a technical discipline — not generic people management — and requires a fundamentally different skill set than writing code.

The transition from IC to manager demands new routines: regular one-on-ones, team rituals, and the ability to have hard conversations. The biggest failure mode is defaulting to coding when things go wrong instead of fixing the underlying coordination and planning problems.

The manager's job is not to write code — it's to make the conditions for great code.

The IC-to-manager transition

• One-on-ones are the core tool; weekly or biweekly depending on team size and interaction frequency.
• Honor the cadence even when there's nothing planned — people need a safe slot to raise small issues before they become crises.
• Open up personally a little; psychological safety on the team starts with the manager being approachable.
• Make your team a team: regular group meetings help engineers see themselves as a unit, not parallel players working in isolation.
• In remote settings, structured social rituals (e.g., a 30-minute Zoom tea) substitute for the natural office proximity.

Common rookie manager mistakes

• Jumping in to write code when the team is behind — this almost never solves the real problem, which is in planning or unblocking.
• Letting interpersonal conflicts fester; you must address them directly, even when the fault is ambiguous.
• Avoiding hard conversations; the muscle needs deliberate practice.
• Never asking for help — managers of managers find it harder to support someone who never surfaces problems.

Performance management and firing

• Clear behavioural violations (theft, harassment, screaming) have obvious paths; the harder cases are underperformance and cultural drain.
• For underperformance: a performance improvement plan (PIP) requires getting specific — define exactly what the person needs to deliver in 30–90 days.
• For negative-energy employees: a PIP often doesn't apply; "change your personality" is not a meaningful target. Move or exit them.
• Removing a toxic person always has a bigger positive impact on the team than you expect — productivity and morale improvements are consistently surprising.

Staying technical as a manager

• New managers who stop coding feel guilty because they lose the fast feedback loops they were wired for — this is normal; push through it.
• It's acceptable to stay somewhat hands-on in the first few years managing a small team, but never code your way out of a team problem.
• Side projects have limits: running a toy cluster is not the same as running systems in production under load; don't let side projects give you false confidence.
• Senior engineering managers stay credible by reading design docs, attending architecture reviews, and asking good questions — not by committing code.

Delegation and dealing with overwhelm

• Ask: what can I just stop doing, delegate, or hold to a lower standard?
• Delegation means accepting that someone else will do it less well — that trade is usually worth it.
• Recruiting is usually not something to drop, but you don't have to be on every hiring loop for every junior role.

Building and merging teams

• Culture clashes between teams usually reflect values mismatches, not personality differences.
• Be explicit about cultural expectations during hiring and onboarding — most interview processes don't screen for this at all.
• If someone is talented but wrong for a role, find another spot in the org rather than exiting them immediately.
• Play to individual strengths; a one-off skill that serves the whole org can be more valuable than a "standard" engineer in a standard role.

Recognising and praising good work

• Be specific about what was done well.
• Ask people whether they prefer public or private recognition — not everyone wants a shout-out in all-hands.
• Peer kudos in a team meeting ("who's done something awesome?") is often more meaningful than manager praise alone.

Non-engineers running engineering teams

• Generally a bad idea; engineering management is a technical discipline and credibility depends on understanding what engineers actually do.
• Non-technical managers end up playing "management telephone" between engineers and the business, adding latency without adding value.
• At the executive level, reporting to a non-engineer is normal and fine; below that, keep engineers managing engineers.

Leadership vs. management

• Leadership is a distinct quality — execution skills, strategic vision, and interpersonal charisma are three separable dimensions; most leaders are strong in at least two.
• All good managers have some leadership quality, but not all leaders are managers.
• The most transferable leadership skill is providing clarity in ambiguity — simplifying a hairy problem so others can act, rather than adding complexity.
• Build a track record of good decisions, explain your reasoning, and work on interpersonal skills that avoid pushing people away.