From Lead Dev to Head of Software Development: Fast Tracks, Real Shifts, Practical Moves

Opening yourself up to leadership often means the title arrives after the responsibilities. The job you get is not the job you trained for; and that’s the point.

Table of contents

Introduction

If you’d said I’d be Head of Software Development at 36, I’d have assumed someone needed a brave volunteer. It happened through a mix of timing, trust, and doing the work before the label. This is for anyone who’s been moved up quickly; excellent engineer, solid lead, suddenly “Head”. I’ll stick to the useful bits: what changed, what broke, what I fixed, and what I’d do on day one.

A short timeline (context, not mythology)

• Engineer → Lead → Head by 36.
• The remit expanded before the title; I operated at the level for months, then the badge followed.
• Today I lead client-facing Software Development and DevOps in a UK digital consultancy, across multiple clients and regulated contexts.

What actually changes when you go from Lead to Head

• Scope: from a product/team to cross-team standards, hiring, budgets (of sorts), and delivery governance.
• Time horizon: from sprint commitments to quarterly/annual outcomes tied to revenue, risk, and reputation.
• Influence: correctness matters less than alignment; the job is outcomes through others.
• People work: hiring, feedback, performance, coaching, conflict; this is not “overhead”; it is the job.
• Credibility: you still need technical judgment, but your leverage is systems: architecture decisions, standards, operating cadence.

Snapshot: I manage full-stack .NET engineers, DevOps, and test; accountable for delivery governance, presales/bids, capability docs, and cross-practice collaboration.

Real struggles I hit (and what worked)

1) Letting go of “doing”

Pull: jumping into PRs and debugging.
Counter: cap hands-on to ~10% where it multiplies others (design docs, spike reviews, gnarly incidents). The rest is architecture/standards, decision records, and enabling. Delegate with explicit outcomes and acceptance criteria.

2) Translating tech to business

Gap: brilliant detail; weak narrative.
Move: report in risk, cost, time, customer outcome. Keep a RAG with a two-minute plain-English brief for execs or important stakeholders where necessary.

3) Hiring at pace without cloning yourself

Risk: “mini-me” teams collapse under change. (As much as you think that’s the ideal outcome, it rarely is.) Move: simple competency matrix; structured interviews; relevant practicals; culture-add not culture-fit.

4) Predictable delivery without strangling teams

see-saw: chaos vs. control.
Move: define guardrails (CI/CD, automated tests, Definition of Done, observability, application of best practices and processes for managing and resolving incidents). Let teams choose the tooling inside them. Anchor improvement in a small, visible metric set inspired by DORA research (deployment frequency, lead time/change flow, time to restore, failure rate).

Note: this is not about adding more process for process’s sake; it’s about creating a lightweight framework that enables teams to deliver with confidence. The DORA research is something I’m planning on trialling out, so take that recommendation with a pinch of salt.

5) Tricky conversations

Discomfort: under-performance, promotions, pay. Move: prep facts and examples; use a coaching frame; be specific, time-bound, and follow through. Loop HR in early when it’s serious.

Note: A lot of these scenarios relate to understanding the hierarchy of needs for each individual. This means recognising their motivations, fears, and aspirations, and tailoring your approach accordingly. Sometimes you have to make difficult trade-offs between individual and team needs or even, when you feel it’s justified, skip a few levels of the hierarchy and go to those who can help manage the situation.

6) Calendar entropy

Symptom: zero deep work. Move: meeting-free blocks; documented escalation paths; office hours; async updates. Guard “maker time” like you would revenue.

7) Staying strategic

Trap: living in delivery detail.
Move: one-page strategy updated quarterly: problem, bets, measures, risks. Tie team OKRs (Objectives and Key Results) to that. Reserve time with sales/product to align pipeline and capacity.

A 90-day operating system for new Heads

Day 0–30 (learn & map)

• Stakeholder map (sponsors, sceptics, power-users); start 1:1s and skip-level 1:1s on a sensible cadence (~6–8 weeks).
• Baseline delivery with a lightweight metric set (e.g., DORA “four keys”) and qualitative risks.
• Draft the first cut of guardrails (CI/CD, test strategy, DoD, incident play-book).

Day 31–60 (early wins & cadence)

• Deliver two visible improvements (e.g., gated deploys to prod; better time to SoW output).
• Stand up the leadership spine: seniors own code review health, standards, and mentoring.
• Start a weekly operating review: metrics, risks, decisions, blockers.

Day 61–90 (institutionalise)

• Publish the team charter and interfaces with other practices.
• Tighten the hiring loop and interview rubric.
• Confirm next-quarter bets, owners, and review rhythm.

Impostor syndrome: extended, practical, and honest

Fast promotions surface two things at once: bigger scope and reduced certainty. That cocktail feels like fraud; especially when you’re managing former peers or representing the practice in rooms where stakes are commercial, not technical.

What typically triggers it

• Scope jump: decisions now span finance, risk, hiring, and client outcomes.
• Information asymmetry: everyone assumes you know everything; you don’t.
• Identity shift: you’re no longer “the best coder” (Not that I’d say I ever was, although I am award winning - so humble); you’re accountable for the system that ships.
• Context switching: dozens of small calls instead of a few deep ones.

Reframe the feeling

• The original research called it the impostor phenomenon: a common pattern of self-doubt among high achievers. It’s real, and it also interacts with environment and bias. Don’t over-medicalise normal leadership anxiety; do fix broken environments.

A pragmatic toolkit

These are a handful of things that I have found to be somewhat useful whenever I’ve had this particular feeling.

• Proof file: maintain a private log of shipped outcomes, tough decisions, client notes, and thank-yous. Review before high-stakes sessions.
• Decision journal: for consequential calls, log the context, options, reasoning, and expected signals. This reduces “I got lucky” narratives.
• Peer council: two or three managers outside your line for honest calibration. This is critical, you need to be able to vent, discuss, and learn from those who have the same lived career experience as you.
• Sponsor ≠ mentor: a sponsor advocates for you when you’re not in the room; identify one and make the ask.
• Cadence beats bravado: weekly 1:1s with directs; skip-levels every 6–8 weeks for ground truth.
• Name the gap: “I don’t know yet; here’s how we’ll find out” defuses pressure and sets a learning plan.
• Mind the system: watch for culture or process issues that manufacture impostor feelings (poor documentation, chaotic priorities, lack of psychological safety).

Signals you’re coping well

• You’re making fewer hero decisions and more repeatable ones.
• Your directs bring you fewer surprises and more options.
• Stakeholders stop talking about “Joe’s projects” and start talking about “how the team delivers for clients.”

On credentials and credibility

My grounding is C#/.NET, Azure PaaS, CI/CD, testing, and delivery in regulated contexts. That background gives practical authority in code/design reviews and in client rooms. The bigger credibility loop comes from hiring well, setting clear outcomes, running fair processes, and speaking commercial language. Tie engineering change to customer and business impact; use delivery research (e.g., DORA) to keep improvements honest and measurable.

Resources for accelerated leaders

A short, high-signal list for anyone who’s stepped up faster than expected:

• The First 90 Days — role transitions, learning agenda, early wins, stakeholder alignment.
• The Manager’s Path (Camille Fournier) — concrete guidance from tech lead to CTO.
• The Making of a Manager (Julie Zhuo) — human, tactical first-time manager playbook.
• Resilient Management (Lara Hogan) — people systems, BICEPS core needs, and practical scripts.
• Outcomes over Output (Josh Seiden) — align work to behaviour change and business impact.
• Accelerate / State of DevOps Reports (DORA) — what to measure and why it matters.
• Harvard Business Review on impostor syndrome — individual vs systemic factors; useful critique.
• Manager Tools: One-on-Ones — nuts-and-bolts cadence that scales.

Hopefully some of these will become part of your toolkit as you navigate your own journey much as I did.

Closing notes

Moving from Lead to Head is less about becoming the smartest person in the room and more about building the room where smart work happens safely, repeatedly, and predictably.

Keep your hands close enough to the code to smell smoke, but far enough to build the fire-breaks. Align relentlessly, measure what matters, and invest in people and systems. The title will follow; the impact will stay.