The patterns that decide whether a tech leader succeeds are already in motion. Most leaders learn to see them about five years too late.
Practical Tech Leader is a new book by Rebecca L. Sutter on the actual discipline of leading engineering organizations — the one that shares vocabulary with technical work but operates by different principles.
Join the list. No marketing noise. One email when the book ships.
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:
- Navigating the technology landscape without confusing novelty with value.
- Running software development as a system, not a series of heroics.
- Bridging the gap between technical credibility and organizational effectiveness.
- Hiring, retaining, and leading the people who make everything else possible.
- 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.
Not a motivational book. A legibility book.
Four commitments it keeps
It does not motivate. It does not offer frameworks designed to make hard things feel easy, or anecdotes selected to inspire. It tries to make organizational dynamics legible, on the assumption that a leader with an accurate model of what is happening can figure out what to do about it.
It names mechanisms, not vibes. Why high-performing teams go quiet. Why the Zeigarnik effect turns an executive’s casual "let’s explore this" into weeks of cognitive cost for the team that heard it. Why psychological safety is a lagging indicator of system design, not a cultural assertion. Why the person most punished by an open-loop leader is the same person whose departure will hurt most.
It is testable. Every observation in the book is specific enough that your own experience can either confirm it or contradict it. The contradictions are information. The patterns are not offered as universal laws. They are offered as models worth running against your own organization to see what holds.
It is the product of forty years inside technology organizations — from the earliest days of personal computing through the current moment of AI capability. Long enough for the same failure modes to repeat across enough contexts to become legible.
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
The book is in production. The list is open.
Practical Tech Leader is in final production and will be released in 2026. Join the notification list and you’ll get a single email the day it ships — plus occasional pre-release excerpts from the chapters above. No promotional churn.
We email you when the book is available. Nothing else. Unsubscribe any time.
That didn’t go through.
Something went wrong between your browser and the form handler. You weren’t added to the list. Try again, or email rebeccasutter@practicaltechleader.com directly.