Books and ideas — Chad Karannagoda

A working shelf rather than a reading log. These are the books I go back to when a problem at work turns out to be a familiar one: how to decide what to build, where a platform’s responsibility should end, and why an organisation adopts one thing and quietly refuses another.

Each entry records the single idea I actually use, and the point at which that idea stops being useful. None of them are summaries, and none of them are recommendations in the general sense. They are notes on what a book changed about how I work.

Carlota Perez

Technological Revolutions and Financial Capital

Why the value in a technology shift lands decades later, with whoever rebuilds the institutions around it.

Donella Meadows

Thinking in Systems

Short, plain, and the reason I look for the feedback loop before I look for the person who made the mistake.

Brian Christian

The Alignment Problem

A history of the distance between what we specify and what we meant, written before that became a procurement question.

Chip Huyen

Designing Machine Learning Systems

The book for people who think the model is the hard part. Most of the work is data, drift and interfaces.

Matthew Skelton and Manuel Pais

Team Topologies

The clearest available language for where a platform’s responsibility should end, which is the hardest line to draw.

Forsgren, Humble and Kim

Accelerate

The research that made delivery performance arguable with evidence, and unusually honest about its own method.

Melissa Perri

Escaping the Build Trap

Perri names the failure mode most product organisations are living in, and does not pretend a framework fixes it.

James Clear

Atomic Habits

Systems beat goals. I use it for delivery cadence and process design far more than for anything personal.

Richard Rumelt

Good Strategy Bad Strategy

A diagnosis, a guiding policy, coherent action. Most documents called strategy contain none of the three.