From Technical Lead to Head of Delivery — The Skill Nobody Prepares You For
This post reached 25,000 impressions on LinkedIn — which tells me the observation resonates with engineers at every stage of the progression. I have expanded it here with the full mechanism, the failure modes I have observed across five organisations, and what the transition actually requires.
I began my career as a Technical Lead at Infosys in 2006, onsite in Tampa, Florida. The progression from that role to Head of Delivery and Engineering — across Infosys, L&T, Hexaware, Accenture, and now Inferyx — taught me one lesson above all others.
The higher you go, the less the technical decisions define your impact. The more the human and organisational decisions do.
This is not a new observation. It is stated in every leadership book and management programme. What those books and programmes consistently fail to convey is how difficult the transition is in practice — and why technically excellent engineers so reliably get stuck halfway through it.
What actually changes at each level
The progression from Technical Lead to Director is not a linear increase in the same kind of work. It is a series of genuine discontinuities — points where the skills that made you successful at the previous level become insufficient, and sometimes actively counterproductive, at the next.
At Technical Lead level, your primary value is solving technical problems directly and developing the engineers around you. You are close to the code, close to the architecture decisions, close to the day-to-day delivery challenges. You are the person who can look at a failing system and diagnose what is wrong. Your credibility comes from the quality of your technical judgement and your ability to develop junior engineers.
At Delivery Manager level, the problems you are solving change. You are now at the intersection of people, process, and technical problems. A delivery issue is rarely purely technical — it is usually a combination of a technical constraint, a process gap, a team dynamic, and a stakeholder expectation that are all entangled. Your job is to untangle them, resolve each layer, and maintain the conditions for the team to deliver consistently.
Technical skill is still necessary at this level. But it is no longer sufficient. A Delivery Manager who can diagnose a technical problem but cannot manage the stakeholder conversation, develop the team, or redesign the process around the constraint is incomplete in the role.
At Director level, the discontinuity is more radical. The problems at this level are organisational design, client relationship management, and strategic alignment. The technical and people layers need to function well — but your job is to create the conditions for that to happen, not to solve those problems directly.
The Director who reviews every architecture decision is not operating at Director level. The Director who personally manages every difficult client conversation is not operating at Director level. These are the signs of a technically capable person who has not completed the transition to the role.
The failure mode — and why it is so common
The failure mode I see most consistently in senior engineers promoted to leadership is this: they continue solving technical problems at two levels below their actual role.
Not because they are incapable of operating at the right level. Because technical problem solving is where they receive validation.
This is worth examining carefully. When a Director sits with an engineering team and solves a technical problem, several things happen simultaneously. The problem is resolved — which feels good. The engineers are impressed — which generates positive feedback. The Director feels competent and useful — which reinforces the behaviour. The entire loop happens in an afternoon.
Compare this to the work of strategic alignment. A Director spends two months building a relationship with a difficult client stakeholder, navigating conflicting priorities across business units, and gradually creating the conditions for a programme to move forward. The feedback loop is slow. The impact is invisible to most of the organisation. There is no moment of obvious success — just the gradual resolution of friction that was previously blocking delivery.
Both are real contributions. But one generates immediate visible validation and the other does not. Without deliberate self-awareness about this dynamic, leaders default to the behaviour that worked at the previous level — because that behaviour still generates the feeling of being effective, even when the organisation most needs something different.
The senior engineers who successfully make this transition are not those who lose interest in technical problems. They are those who develop a genuine capacity to find the slower, less visible work satisfying — who can look at a well-functioning team making good technical decisions without their input and recognise that as their contribution, not as evidence that they are no longer needed.
What the transition actually requires
Three things, in my experience across this progression:
A conscious reorientation of how you measure your own contribution.
The most important mental shift is this: your contribution is no longer the quality of your own technical decisions. It is the quality of decisions made by the people you lead.
If your team makes consistently better architectural decisions this quarter than last quarter — and you did not make those decisions yourself — that is your contribution. If a junior engineer escalated a problem to you, you coached them through the analysis, and they solved it — that is more valuable than if you had solved it directly. If a client relationship that was fragile six months ago is now stable and productive — and that happened because you invested time in building trust with the right stakeholders — that is your contribution.
None of these contributions appear on a technical architecture diagram. All of them compound over time in ways that direct technical contribution does not.
Deliberate withdrawal from the technical layer — not absence, but appropriate distance.
The transition does not mean losing interest in or engagement with technical decisions. It means changing how you engage with them. At Director level, the right engagement with a technical decision is usually a question, not an answer. "Have you considered the latency implications of this approach?" is Director-level engagement. Designing the alternative approach yourself is Technical Lead-level engagement.
The distinction matters because when a Director provides an answer rather than a question, two things happen. First, the thinking work that would have developed the engineer is bypassed. Second, the Director has taken responsibility for a decision that should sit lower in the organisation — which creates dependency and reduces the team's capacity to operate independently.
This is harder than it sounds for technically strong leaders. The technical answer is often obvious to them. The discipline is in recognising that the short-term efficiency gain of providing the answer is outweighed by the long-term cost of not developing the person who should be finding it.
Investing in the slow work — stakeholder trust, organisational design, strategic clarity.
The work that has the highest leverage at Director level is also the work that has the slowest and least visible feedback loop. Stakeholder trust built over months enables delivery that would otherwise be blocked. Organisational design that gives the right people the right scope creates compounding capability over years. Strategic clarity that aligns the team's effort with what the business actually needs prevents months of work in the wrong direction.
Investing in this work requires a tolerance for ambiguity and delayed gratification that is genuinely different from the rapid feedback loops of technical problem solving. It is not better or worse — it is different. The leaders who make this transition successfully are those who develop genuine appetite for the slower work, not those who tolerate it while waiting for an opportunity to return to the familiar.
What I wish someone had told me in Tampa in 2006
The trajectory from Technical Lead to Director is not a path of accumulation — more skills, more knowledge, more technical depth. It is a path of transformation — a genuine change in what you optimise for, how you measure success, and where you invest your attention.
The technical foundation matters and should be maintained. Domain depth compounds and remains a competitive advantage at every level. But the technical foundation becomes the floor, not the ceiling. What determines whether you operate effectively at Director level is whether you have built the human and organisational capabilities on top of it.
The engineers who make this transition well are not those who stop being engineers. They are those who expand their definition of what engineering leadership means — from designing systems to designing organisations, from solving technical problems to creating the conditions in which technical problems get solved by the right people at the right level.
That is the skill nobody prepares you for. And it is the one that, once developed, compounds in ways that technical skill alone cannot.
Frequently asked questions
What skills does a Technical Lead need to become an Engineering Director?
Three fundamental shifts: from solving technical problems directly to solving people-process-technical intersections; from individual delivery to organisational design and strategic alignment; and from measuring contribution by your own decisions to measuring it by the quality of decisions made by the people you lead. Technical skill remains necessary but becomes the floor, not the ceiling.
Why do senior engineers struggle when promoted to leadership?
Because technical problem solving is where they receive validation — it is familiar, visible, and generates immediate feedback. The harder work of organisational alignment and stakeholder trust building is slower and less visible. Without deliberate self-awareness, newly promoted leaders default to the behaviour that made them successful at the previous level, continuing to solve problems two levels below their actual role.
What does a Director of Engineering do differently from a Delivery Manager?
A Delivery Manager solves the intersection of people, process, and technical problems at team level. A Director solves organisational design, client relationship, and strategic alignment problems — creating conditions for the layers beneath to function well without direct intervention. The shift is from doing to enabling, from answering to asking, from solving to creating the conditions for others to solve.
How long does the transition from engineer to engineering leader take?
Technical skills can be acquired relatively quickly. The human and organisational skills — stakeholder trust, organisational design, creating conditions for others to make good decisions — compound over years of deliberate practice. Most engineers who make the transition successfully report two to three years of conscious effort to genuinely change how they measured their own contribution.
Found this useful? I write weekly on engineering leadership, technology career growth, and the lessons 24 years across five organisations taught me about what it actually takes to lead at scale. Subscribe to the newsletter — no spam, unsubscribe anytime.
Building a senior engineering leadership team or navigating your own transition? Explore my consulting services or get in touch directly.
Raj Thilak is Head of Technology for Data & Analytics with 24 years across Infosys, L&T, Hexaware, Accenture, and Inferyx. He began his career as a Technical Lead in Tampa, Florida and has led engineering organisations of up to 450 professionals. Based in Pune, India. rajthilak.dev
Found this useful? Subscribe for weekly insights.
Join the conversation
Loading comments...