Somewhere in the last fifteen years, Director of Engineering stopped meaning the person who makes the hardest technical decisions and started meaning the person who manages the process around engineering. The title didn't change. The job underneath it was hollowed out and rebuilt as something else entirely.

This isn't a feeling. It's measurable.

The Evidence

In 2017, researchers Benjamin Artz, Amanda Goodall, and Andrew Oswald published a peer-reviewed study across US and British longitudinal data. Their finding was unambiguous: a boss's technical competence is the single strongest predictor of a worker's job satisfaction. Not their communication skills. Not their coaching ability. Not their vision or strategy. Their competence in the actual work being done.

The study went further. Even when a worker stayed in the same job at the same company, a rise in the competence of their supervisor was directly associated with an improvement in the worker's wellbeing. Goodall's subsequent book Credible extended this across industries: organisations led by people with deep domain expertise consistently outperform those led by generalists. Expert leaders create the right environment because they've walked the walk — they understand what good looks like because they've done it.

This should have ended the debate. It didn't, because an older piece of research gave the process-management class a lifeline.

The Google Defence

Anyone pushing back on the case for technical leadership will reach for Google's Project Oxygen. The headline finding: when Google ranked the qualities employees valued in managers, technical expertise came last among eight traits. Coaching, communication, and career development all ranked higher.

This gets cited constantly by people who've never examined the context. Google's engineering managers were already strong engineers. Every one of them. Technical competence wasn't a differentiator because it was the floor, not the ceiling. Oxygen proved that soft skills matter on top of technical depth. It did not prove — and never claimed — that technical depth is optional.

Strip the technical baseline from Google's managers and Oxygen collapses. A director who can't review code isn't going to coach anyone through an architectural problem. A leader who doesn't understand the system can't give career guidance that amounts to more than "have you thought about getting a certification?" The interpersonal skills Oxygen identified only function when they sit on a foundation of competence. Without that foundation, coaching becomes platitude and communication becomes noise.

The Google defence doesn't protect the non-technical engineering leader. It condemns them.

How the Job Was Hollowed Out

It happened because scaling was hard. When companies grew from ten engineers to a hundred, they needed people to manage the complexity — hiring pipelines, sprint ceremonies, cross-team coordination, stakeholder reporting. Real problems.

The mistake was calling the people who solved those problems engineering leaders. They were operations managers with engineering titles. Once the title was detached from the function, the career path followed. You could reach Director of Engineering without ever having made a hard architectural call, without ever having debugged a production outage, without ever having looked at a pull request and known — from experience — that it would break under load.

The process became the product. Standups, retros, planning sessions, refinement, estimation, story points. An entire apparatus of activity that creates the appearance of order while quietly dissolving accountability. Who made the decision to use that framework? The process. Who chose that architecture? The team. Who's responsible when it fails? Nobody identifiable.

The evidence that this process delivers results on its own terms is, at best, mixed. Even Scrum's co-creator Jeff Sutherland acknowledges that roughly 47% of agile transformations fail, with the best available data showing only 42% succeeding outright. A 2024 Engprax survey of 600 engineers suggested significantly higher failure rates for Agile projects — the exact numbers are debatable, but the direction isn't. Nobody credibly argues that the process era has been a delivery success story.

The process was never designed for delivery. It was designed for reporting — for giving someone three levels up a coloured dashboard that said things were on track. Delivery happened despite the process, driven by the engineers who carried the technical weight while the director managed the calendar.

What AI Exposes

Small teams and AI change what leadership means. Permanently.

When three engineers with AI can deliver what twenty delivered before, the director whose value was coordinating twenty people has no function. Their calendar management, their stakeholder updates, their sprint facilitation — all of it evaporates with the headcount it was built to manage.

But there's a trap here too. The 2024 DORA State of DevOps report — the industry's most comprehensive study, drawing on over 39,000 professionals — found that AI adoption correlates with worsened software delivery performance. The reason isn't bad code. It's that batch sizes increase when AI is used, and larger changesets are riskier. The 2025 DORA report went further: in teams with weak foundations, AI amplifies chaos by speeding up unplanned work without improving reliability.

AI doesn't replace judgement. It demands more of it. The leader who never had technical judgement to begin with is now presiding over AI-accelerated chaos with no ability to see it, diagnose it, or fix it.

Meanwhile, DX research shows the average engineer gets only 19.6 hours of focused work per week — less than half the working week — with the rest consumed by meetings and fragmented tasks. The process apparatus isn't just failing to deliver. It's actively consuming the time that delivery requires.

DORA's own data confirms what the Goodall research predicts: transformational leadership improves productivity, satisfaction, and performance while reducing burnout — but the "move fast and constantly pivot" mentality that process-era leaders mistake for agility actually harms developer wellbeing and overall performance. Stable priorities and clear technical direction beat constant ceremony every time.

The Uncomfortable Maths

No other serious profession abandons its core skill as people progress.

A head surgeon still operates. A lead architect still designs buildings. A senior barrister still argues cases. A principal engineer at a structural firm still reviews load calculations. The idea that seniority means you stop doing the thing you're supposed to be expert at is unique to software engineering leadership, and it was always a mistake.

It happened because of shortages. There weren't enough experienced engineers to fill every leadership role, so companies filled them with people who had adjacent skills — project management, stakeholder communication, process design. These were presented as transferable leadership qualities. They aren't. They're support functions. The core skill of an engineering leader is engineering, and no amount of sprint facilitation compensates for its absence.

The consequences are structural. A leader who never had the core skill can't review a pull request and provide architectural feedback — not style comments, but the kind of insight that prevents a system from breaking under load six months from now. They can't mentor — they can offer coaching templates, but they can't sit with a junior engineer and redirect their approach based on experience, because they don't have the experience. The Goodall research shows exactly why this matters: expert bosses create better environments because their competence is a resource the team draws on. A 1:1 with a technically hollow leader is a welfare check with a Jira review bolted on. The engineer leaves having gained nothing they couldn't get from a blog post.

They can't steer — they lack the depth to evaluate competing technical options, so they default to consensus or consultancy. They can't balance the compromises that every real system demands — performance against cost, security against speed, simplicity against capability — because they've never had to make those trade-offs with their own hands on the keyboard. They can't debug a production incident without waiting for someone else to tell them where to look. They can't say no to a feature on technical grounds because they don't have the technical authority to say it or the product understanding to defend it.

None of this is an unreasonable standard. This is the job. It has always been the job.

These scars take years. The judgement takes decades. You can't send a process manager on a two-week architecture course and get a technical leader back. The Goodall research is unambiguous about what this costs: lower job satisfaction, higher quit rates, weaker organisational performance. The DORA data tells us what happens when you add AI to that environment: accelerated chaos, larger batch sizes, more risk, no one at the top with the competence to see it.

The people who have this depth are not always the ones with the titles. They're often the senior engineers who've been quietly making the real decisions while the director ran the meetings — choosing the database, designing the API, mentoring the juniors, carrying the on-call pager. Without the authority, the compensation, or the credit.

The age of small teams and AI will correct this, because it has to. The scaffolding is collapsing. The headcount that justified process leadership is shrinking. What remains is the work itself — architecture, security, scalability, product, delivery — and only people who can actually do that work will be fit to lead it.

The question for every company is simple: do your engineering leaders engineer?

If the answer is no, AI isn't going to save them. It's going to expose them.