The patterns that decide whether a tech leader succeeds are already in motion. Most leaders learn to see them about five years too late.

A different discipline, not a natural extension

Technology leadership is not the natural extension of technical competence. It is a different discipline, and the confusion between the two is one of the most consistent sources of organizational friction in engineering.

Practical Tech Leader is a working manual for the engineers, architects, and managers who have crossed — or are crossing — that line. It is organized around the five domains that define the actual scope of the job:

1. Navigating the technology landscape without confusing novelty with value.
2. Running software development as a system, not a series of heroics.
3. Bridging the gap between technical credibility and organizational effectiveness.
4. Hiring, retaining, and leading the people who make everything else possible.
5. Leading through the AI transition — where the same patterns now compound faster than any previous technology cycle allowed.

Each domain stands on its own. The interactions between them are where most of the interesting complexity — and most of the failure — actually lives.

Engineers with responsibility they were not trained for

This book is written for:

• Senior engineers moving into their first formal leadership role.
• New managers still carrying the instincts of the job they were promoted out of.
• Tech leads, staff engineers, and architects with organizational influence but no clean playbook for using it.
• Directors and VPs who inherited a system they did not design and need a sharper model of how it actually works.
• Anyone who took the promotion and then discovered the proof system stopped compiling.

If you have ever suspected that the leadership advice available to you was either too abstract to act on or too motivational to trust, this book was written for you.

Four commitments it keeps

Most technology leaders fail not because they can’t code — but because they can’t see

They miss the invisible costs their decisions impose on their teams. They frame structural problems as people problems. They optimize for signals that are measurable rather than signals that matter. And they do all of this with the best intentions, because no one ever made the dynamics legible enough to recognize in real time.

The Practical Tech Leader draws on four decades inside technology organizations to name what actually determines whether an engineering leader succeeds — and why the same failure modes appear, with eerie consistency, across different companies, industries, and technology cycles.

Organized around the four domains that define effective tech leadership — the technology landscape, software development, organizational leadership, and people systems, and how the AI transition is reshaping all four — this is not a motivational guide. It offers no frameworks designed to make hard things feel easy.

What it offers instead is a clearer model of how these systems actually work: how technologies mature, how security failures are really organizational failures, why hiring is the highest-leverage decision a leader makes, and why the team’s experience of a decision is almost always invisible from the leader’s position.

The final section confronts what the AI era means for engineering leadership — not as an abstract future, but as a live operating condition that changes the cost structure of every decision a tech leader makes.

The patterns here are testable. The mechanisms are stable. And the value of seeing them early, before the compounding cost becomes visible, is larger than any individual decision or practice accounts for.

This is the book for leaders who want an accurate map — not a comfortable one.

Eight chapters, named

Each of these is a chapter or a named mechanism in the book. They are representative of the voice and the approach.

1. The Open-Loop Leader

   Why every "yes" an executive says is a lightweight cognitive thread for them and a persistent unfinished task for the team downstream — and what the asymmetry does to your best people over time.

2. The 90/10 Rule

   Why hiring is the single highest-leverage decision a leader makes, and why active management cannot close the gap that a bad hire opens.

3. Shame-Resilient Postmortems

   How to run an incident review so it produces learning rather than theater, and why most "blameless" postmortems are not actually blameless.

4. The Identity Transition After Promotion

   Why the proof system that rewarded your technical excellence stops compiling the day you become a leader, and why top performers are hit hardest by the transition.

5. Managing Up When the Leader Above You Is Wrong

   The mechanics of what makes a call hard to reverse, the timing most people get wrong, and how to build a case that actually moves the decision.

6. AI Is a Redesign Problem, Not a Replacement Problem

   Why layering AI onto an existing workflow produces the worst outcomes in both the old and the new paradigm, and what the six-hour day has to do with sustainable deployment.

7. The Approval Economy

   What gets quietly lost when the act of building is replaced by the act of approving AI-produced work — and the question that did not get asked on the analyst call.

8. Change Has a Burn Rate Too

   Why the fourth reorganization hits harder than the first, why smaller changes hit harder than big ones, and how to measure adaptation load before you lose the people carrying it.