Sam
Newman

There is a particular kind of technical author who writes the book everyone recommends but few admit to having read cover-to-cover. Sam Newman is not that author. Engineers actually read his books - and then argue about them at standups, in Slack threads, and at conference after-parties. "Building Microservices," his first O'Reilly title from 2015, did something rare: it gave a name, a shape, and a set of hard-won principles to an architectural movement that had been gathering momentum without a proper map. Newman drew the map. The industry printed it and put it on the wall.

What made the book land was not that it championed microservices as a universal truth. It did the opposite. Newman spent as many pages explaining when not to use microservices as he did explaining how to implement them. The honest accounting of trade-offs - latency, operational complexity, service coupling, the hidden costs of distributed transactions - earned the book its staying power. It aged better than the hype it was born into.

Newman runs Sam Newman and Associates from London, a consulting and training practice he founded in 2016 after 12 years at ThoughtWorks. Twelve years is a long time anywhere in tech. During that stretch, he worked across cloud computing, continuous delivery, and systems architecture at a time when all three were still finding their vocabulary. He helped train early AWS adopters, contributed to the intellectual foundations of continuous delivery, and co-created tools that solved problems people did not yet have names for.

One of those tools was DBDeploy, co-created in 2006 with Graham Tackley and Nick Ashley - among the first open source approaches to managing database schema changes in a version-controlled, automatable way. Before infrastructure as code was a bumper sticker, Newman and colleagues were solving the boring, load-bearing problem of "how do we change the database without breaking everything." DBDeploy was presented at XP Day 2006 in London. It was, in retrospect, a prototype of an entire discipline.

Around the same time, he co-created the Lego XP Game with Andy Yates - a hands-on simulation for teaching Agile and Extreme Programming principles to teams using actual Lego bricks. It has since been run at conferences and workshops worldwide, thousands of times over. This is worth pausing on: a piece of software rarely gets run that many times. An educational game built from plastic bricks and good instructional design has outperformed the usage metrics of most enterprise tools.

In 2019, Newman published "Monolith to Microservices," a practical companion volume to his first book. Where the original told you what microservices were, the second told you how to get there from wherever your organisation was currently standing - which was usually "somewhere complicated, with a codebase nobody wants to touch." The book is a catalogue of decomposition patterns, migration strategies, and real talk about the organisational politics that make technical decisions hard even when the architecture is clear.

His third book, "Building Resilient Distributed Systems," is due from O'Reilly in June 2026 and is already in early access. It covers the territory that sits between "the system is working" and "everything is on fire" - timeouts, retries, idempotency, incident management, and the sociotechnical realities of keeping complex systems alive under load. The book arrives at a moment when the industry has spent a decade decomposing monoliths and is now reckoning with the operational complexity that decomposition creates. Newman, characteristically, is already one book ahead of the conversation.

His conference talk titled "The Definition Of Insanity" - on timeouts, retries, and idempotency - was performed at NDC London 2025. The title is a reference to the commonly misattributed Einstein quote about repeating the same action and expecting different results. In distributed systems, the same action repeated is often exactly what you want: a retry. The trick is knowing when. Newman's talks tend to work like this: a sharp title, a counter-intuitive entry point, and then a careful unpacking of why the obvious answer is usually incomplete.

He is also the originator of one of the most useful single sentences in modern tech management: "Even Spotify doesn't use the Spotify model." This observation - that engineering organisations should be wary of copy-pasting org structures from companies with entirely different constraints, cultures, and scales - encapsulates a broader point about Conway's Law and the relationship between organisational structure and system architecture. Newman has been making this point patiently for years, across books, talks, and blog posts. The fact that he still has to make it is a testament to how persistent the cargo-culting instinct is.

Newman's independence matters to how he works. Not affiliated with a consultancy's sales pipeline, not writing for a vendor's blog, not trying to position a product. He advises on microservices, cloud architecture, and continuous delivery because that is what he knows better than most people alive, and because the problems remain genuinely hard. The consulting work, the books, the talks, and the podcast all point at the same thing: helping engineering organisations make better decisions under conditions of complexity and incomplete information.

His newsletter operates on a similar philosophy - low frequency, worth opening when it arrives. He has written publicly about valuing readers' inboxes over his own desire to be visible. For an author with 25 million+ books downloaded, that restraint is notable. It is also very on-brand. Newman's whole career has been about identifying what actually matters - in architecture, in organisations, in writing - and cutting away the rest.

There is a particular kind of expertise that only comes from being in rooms where the software broke, watching why it broke, and thinking carefully about what systemic conditions made the breakage both likely and hard to recover from. Newman has been in enough of those rooms, across enough different organisations and technology stacks, that his pattern recognition is genuinely calibrated rather than theoretically confident. That is the difference between his work and the consultant who read his books. The books themselves are full of this distinction: here is the theory, here is what actually happens, here is the gap between them, here is what to do about it.

He is currently working out of London, speaking at the world's leading software conferences, and finishing a book about resilience. If past form is any guide, it will be worth reading carefully, arguing with productively, and keeping within arm's reach of the terminal.