What effective leadership in software development actually looks like — and why most organizations get it dangerously wrong.
"You can't effectively lead developers if you aren't — or haven't been — a developer yourself."
A principle too many organizations still resist
Picture a familiar corporate scene. A stand-up meeting. A product team mid-sprint, wrestling with a gnarly distributed-systems bug. The engineering manager — two years removed from writing any code — opens the floor: "Can't we just fix it by Friday? The business really needs this."
The engineers exchange glances. The silence stretches. Someone politely explains, for the fourth time this quarter, why that particular deadline is physically impossible given the nature of the problem. The manager nods, says "let's find a way," and closes the meeting. Nothing changes. The team's trust erodes a little further.
This is the backseat-leader problem. It's endemic, it's expensive, and it stems from a stubborn myth: that strong "people skills" are a complete substitute for technical fluency when leading technical teams.
They are not. And the evidence — from team retention numbers to product quality — keeps making the case.
The idea has a seductive logic to it. Leadership, the argument goes, is fundamentally about humans. It's about motivation, alignment, communication, and clearing blockers. Technical depth is what the individual contributors are for. The manager's job is to create the conditions for great work, not to do the great work themselves.
In many industries, that's a reasonable framework. A great operations leader at a logistics company doesn't need to drive trucks. A marketing director doesn't need to hand-code landing pages.
Software development is different. Here's why: the substance of the work and the complexity of its decisions are inseparable from the medium. You cannot make meaningful judgments about scope, risk, architecture trade-offs, or technical debt without understanding the domain. Not superficially — deeply.
Nicklas Millard, a senior software engineer, put it bluntly in a widely shared essay: leaders need to be hands-on, every day. The argument isn't that managers should be the best coder on the team. It's that a leader who cannot engage with the technical reality of what their team does is operating blind — and asking everyone else to follow them in that blindness.
The costs of technically disengaged leadership are rarely captured in a single dramatic failure. They accumulate quietly, in the texture of day-to-day team life.
When leaders don't understand the work, sprint planning becomes theater. Estimates are ignored or overridden based on business pressure rather than technical reality. The team learns, quickly, that their professional judgment doesn't carry weight. They stop giving honest estimates and start gaming the process to protect themselves.
Technical debt is one of the most consequential long-term forces in any engineering organization. But it's nearly impossible to explain to a leader who's never felt its weight. Without a leader who can advocate internally for paying it down — who can translate "we need a refactoring sprint" into business terms a CFO will respect — debt accumulates until it becomes a crisis. By that point, it costs ten times as much to address.
Skilled engineers have options. They are keenly aware when their manager cannot evaluate their work, cannot protect them from irrational demands, and cannot recognize the difference between excellent and mediocre output. Strong engineers leave. Weaker ones, sometimes, stay. Over time, this creates a self-reinforcing mediocrity spiral that is very difficult to reverse.
A technically disengaged leader creates a feedback vacuum. Without someone who can read the code, the architecture decisions, the test coverage — and have an informed view — teams can drift for months in costly directions before anyone notices. The later the correction, the higher the cost.
The strongest engineering leaders — those who consistently build high-performing, high-retention teams — tend to share a counterintuitive quality: they don't fully step back from the code.
This doesn't mean they're top of the commit leaderboard. It means they write code often enough to stay calibrated. They review pull requests not just to approve them but to genuinely understand the choices being made. They attend technical design sessions as participants, not observers. They can — when needed — sit down and work through a problem with an engineer, not just assign it and check in at the next stand-up.
This is what it means to be a technical leader who is also an individual contributor (IC). The IC role isn't about volume of output. It's about maintaining the hands-on understanding that makes every other leadership function — mentoring, architecture review, cross-functional communication, prioritization — more effective.
The Agile movement, for all its genuine contributions to software delivery, introduced a generation of "servant-leader" rhetoric that sometimes enabled the very problem it claimed to solve. When leadership is reframed purely as removing blockers and facilitating ceremonies, it becomes easy to be technically disengaged and still feel useful.
Stand-ups, retrospectives, sprint reviews — these rituals create a comforting structure of activity that can mask a fundamental absence of technical engagement. A Scrum Master who has never written production code can run a textbook sprint ceremony and still be completely unable to tell whether the team is building the right thing, the right way, at a sustainable pace.
Agile ceremonies are necessary but not sufficient. What fills the gap between process structure and genuine leadership is technical credibility — the kind that only comes from sustained engagement with the actual work.
Concretely, effective technical leadership in a software team looks something like this:
The leader participates in architecture discussions with opinions, not just open-ended questions. They can read a pull request and offer substantive feedback — not just "LGTM." They have an informed view on build-versus-buy decisions, not because they ran a spreadsheet, but because they've lived through the consequences of both. They know what a good test suite looks like versus a fragile one. They recognize the difference between a team moving fast and a team accumulating risk.
This doesn't require being the most senior engineer on the team. It requires sustained engagement. The leader who spends two hours a week genuinely doing technical work — not reviewing PowerPoints, but writing or reviewing actual code — will, over time, maintain the intuition that makes them effective. The leader who stops entirely will, equally over time, lose it. And the team will know before the leader does.
None of this is an argument against interpersonal skill. Empathy, communication, conflict resolution, coaching — these matter enormously. A technically brilliant leader who is dismissive, poor at feedback, or unable to navigate organizational politics will still fail, often spectacularly.
The point is that soft skills are necessary but not sufficient. The most effective engineering leaders are technically credible and humanly skilled. They understand the code and the people who write it. They can debate a technical trade-off and, in the same meeting, help a junior developer feel safe raising a concern.
The binary — "technical" versus "people" leader — is a false one. It exists largely because organizations find it convenient to promote technically weak people into leadership roles and justify the decision with soft-skill rhetoric. It's worth asking, each time you see that pattern, who it actually serves.
If you're building or evaluating an engineering organization, the key signal isn't years of management experience. It's evidence of sustained technical engagement after moving into leadership. Ask candidates: what was the last piece of code they wrote? What's the last pull request they reviewed substantively? What technical decision in the past six months are they most uncertain about?
Candidates who can answer these questions concretely — with specificity, with appropriate humility — are the ones most likely to lead effectively. Those who gesture vaguely at "strategy" and "alignment" and immediately redirect to org charts may be telling you, accurately, that they have stopped doing the work that makes them qualified to lead people who do it.
Promote the engineers who make the people around them better. Promote the tech leads who bring problems upward with clarity rather than filtering them out of existence. Promote the people who are visibly respected by the senior engineers on the team — because senior engineers, more than anyone else in the organization, can tell the difference.
Great engineering leadership is not a choice between technical depth and human skill. It is, at its best, a deliberate cultivation of both — a refusal to use the language of leadership as cover for disengaging from the work that makes the team possible. Lead from the front. Stay in the code. Your team will feel the difference, even if they never say so directly.