Executive Engineering: Practical Engineering Theory for Software Leaders

by Jack Danger

Unlock the foundational principles of engineering leadership. Success in your specific company, with your specific team and products, requires an understanding that goes deeper than merely adopting industry best practices.

Executive Engineering is a bird's-eye view of the software field that reveals how product velocity, tech debt, Agile frameworks, team charters, and product leadership all fit together and how to use these connections to deliver product value at maximum speed.

Drawing from the lessons of Silicon Valley startups, Jack Danger ties together the many little complexities of engineering leadership into a unified whole and empowers engineering leaders at any size company to deliver real value to customers faster.

In these pages you'll find practical tools

Measure and accelerate engineering velocityRepair the relationship between Product and EngineeringUncover hidden layers within your existing teamMake a portfolio of your technical debt

Genres: Leadership, Management, Technology

186 pages, Kindle Edition

Published April 8, 2024

Reviews

[Mindaugas Mozūras · Rating 5 out of 5]

Every executive needs to ensure their function costs less than the value it delivers

I loved "Executive Engineering" by Jack Danger. It's primarily meant for CTOs and VPs of Engineering and is mainly limited to topics specific to those roles. The book doesn't go into more general topics, which similar leadership books often do (e.g. hiring and performance reviews).

The best thing about this book is that it has a specific point of view, which is precisely what I want from these types of books. It doesn't try to provide general management theory. No, this book is how Jack Danger thinks about technical leadership and how he applies his thinking. The mental models and systems are clear and straightforward, and the examples of applying them seem to come from experience.

After reading, I immediately have some ideas of what I'll want to apply in my job over the next 12 months. I would recommend "Executive Engineering" for any senior software leader or someone who aspires to become one.

[Michal Porzozynski · Rating 4 out of 5]

Jack’s book is really about maximizing outcomes generated by engineering. He answers not an easy question about where we are in the value chain and how we, software leaders, can measure the effectiveness of our organization. The book connects the three amigos' rules of product engineering, a simple but powerful concept of setting organizational structure based on Jack’s theory of Technical Coherence, and finally, how to fund all of that. I think that fans of Team Topologies will find it useful as well. The chapter about financing technical debt is an important one – it gives a good overview of what this debt is (and what it is not) and gives practical advice on what to do with it.

The last part of the book is a bit hand-wavy. Especially the communication design part feels like a pick of the iceberg.

[John · Rating 5 out of 5]

"Executive Engineering" is the first book that really gives me a picture of what the CTO and Engineering leadership of a contemporary software company does in a way that feels real to my experience.

When I say a contemporary software company, I mean one with separate "Product", "Design", and "Engineering" departments. This was not always the case. I remember the first time I was in a company with product managers (perhaps midway through my career so far) and I just thought they were opinionated (maybe even bossy) project managers. My misunderstanding of this world order worked in my favor as I think I got a reputation as an engineer who cared about the product, where in reality I had never been in a circumstance where product requirements were not an engineering responsibility.

The book is short and bracing, making for a quick read. When summarizing it, I would risk covering it entirely except it will be much better written than I intend to bother with, containing a lot of subtleties. So, consider what follows an advertisement and not a replacement.

Summary

This book has four sections. The first two define and give a solution to how to structure a software engineering organization to deliver the value it needs to the organization. The third deals with when and how to defer technical improvements, giving the only reasonable definition of technical debt I've ever seen. The fourth then examines how guide the teams described above to effective work within them and across the organization.

Coherent ways to secure delivering sensible engineering output

The game for a software engineering division, as posed by this book, is to, on an ongoing and reliable basis, deliver potential (or projected) product value. The trick is that there are natural pressures to focus either on valueable features or on transferable engineering skills, neglecting the domain that specifies how these features integrate into a coherent whole that enables further valuable work instead of creating a drag of constant reintegration between components.

Once recognized, the approach to this is straightforward: identify all of the interfaces created by the software structure (all of them, including data science), identify shared domains between them, divide them up into layers (product, domain, and infrastructure), and staff pure infrastructure at the absolute minimum, domain at the maximum, and product area as it needs.

The great thing about this is that it'll not only shape the work, but drive conversation within "Engineering" and between "Engineering" and "Product" to the domain.

Technical debt as technical financing

Technical debt struck my as a poorly organized grab bag of software complaints until this treatment, which is ultimately about the bottom line and not technical preference.

For a given technical issue, it imposes ongoing costs (or risks, weighed chance of costs), that can change by various factors over time. To stop paying those costs, other costs by other factors must be incurred. There may be little risk until a payoff event (say, such as when a given version of a technology is no longer supported by a service provider). By identifying these attributes, you have a financially justified way of sequencing addressing ongoing costs (including living with them).

Making teams effective and meaningful

Focus teams on the experience you are trying to get them to deliver, so that they are not aligned with a particular technology or feature but users in particular situations. Pay attention to both the level of familiarity they have with the experiences they are working on and the necessary technologies for delivering those experiences, and see they are managed with the supervision appropriate to those competencies, with more frequent interactions needed to align and foster beginners in either the domain or the technology. End generic "working on", but instead classify all activities as one of "design", "alignment to design", or "incident response". Create consistently named channels defining both core working areas and cross-company interfaces, being sure that appropriate engagement is made with documents that are persisted and maintain domain value.

Conclusion

Overall, "Executive Engineering" has a really clean and specific practical view for software leaders, and is strongly worth engaging for anyone working in software engineering.

[Dawid Stronczak · Rating 5 out of 5]

I absolutely loved Executive Engineering by Jack Danger. Danger’s writing is clear and engaging, making complex engineering concepts incredibly accessible to leaders. Each chapter offers practical, hands-on frameworks—like modular team designs and feedback loop roadmaps—that I could implement immediately. The actionable checklists and decision matrices helped me streamline processes and boost team efficiency within days. I appreciated how Danger blends theory with real-world examples, keeping the book both informative and highly relevant. If you’re tired of abstract management advice, this book delivers concrete tools that genuinely improve organizational performance. A must-read for any executive eager to bring an engineering mindset to leadership.

[Vaidas · Rating 5 out of 5]

An opinionated take on engineering leadership that a lot of new leaders or leaders who had to learn as they went can take inspiration from. The advices feel sound, as they all address specific challenges that the growing organisation experiences.

Will be interesting to compare this book with The Engineering Executive's Primer by Will Larson.

[Andrzej Grzesik · Rating 4 out of 5]

Good mental models.
Short and to the point.
Read with mr Larson.

[cwww · Rating 5 out of 5]

clear and useful

Jack danger puts “what we all know” into coherent words and charts that drive forward discussions about eng org structure. Thank you for writing this!