What I read, and what it actually changed

The most useful non-technical book I have read for technical work. Once you accept that improving a non-bottleneck is motion without progress, you stop optimizing whichever part of the pipeline is easiest to optimize. The constraint is almost never writing the code, it is review, testing, or waiting on a human, and that is the whole reason I care whether a pipeline finishes in fifteen minutes.

The four types of work is the model I still reach for, and the uncomfortable one is unplanned work. Once you see that unplanned work crowds out exactly the work that would have prevented it, you understand how a team can run flat out and go nowhere. It is the clearest account I have read of why toil compounds instead of staying constant.

This is what gave me numbers to argue with instead of taste. Deployment frequency, lead time, change failure rate, and time to restore are the four I actually track. The finding that elite teams deploy more often and fail less is what killed the move-fast-versus-be-careful framing for me, and it is why my strategy page leans on the research rather than on my own preferences.

I am not doctrinaire about ceremonies, and plenty of Scrum in practice is theatre. The retrospective is the part I would keep at gunpoint. It is where improving the work stops being a thing everyone agrees with and gets an actual slot on the calendar, which is the only version of it that survives a busy quarter.

It taught me the difference between a goal and a metric, which is the difference between "improve reliability" and a number a team can be publicly wrong about. Anything that cannot be wrong is not a target, it is a sentiment, and that distinction runs through what I think a strategy has to contain.

The infrastructure version is that the tool your team is best at is the one you will defend longest past its usefulness. Competence becomes a reason to stay. It is why I try to name the reason for a migration before starting one rather than after, and why "we already know this tool" belongs in the cost column of that decision rather than the argument for keeping it.

Larson is where I learned what an engineering strategy is supposed to look like, which is why my strategy page opens by saying a strategy is not a roadmap. His argument that decisions have to be written down to survive turnover is a fair description of why this site exists in the shape it does.

There is no framework for the call where every option is bad, and Horowitz is honest that the actual skill is continuing to function anyway. The part that transfers directly to incidents is his case for telling people the truth early instead of managing the message, which is the same reason a culture that punishes bad news stops receiving it.

The error budget stopped being jargon here and became the thing that ends the ship-fast-versus-stay-up argument, because it turns reliability into a number both sides already agreed to. It is why my observability playbook says SLOs do the arguing for you, and why I treat toil as something to attack on a budget rather than something to absorb.

It cured me of thinking a managed service removes a failure mode. It relocates one, usually somewhere with less visibility and no runbook. Everything eventually fails, so the real question is whether the system degrades or collapses, which is the assumption sitting underneath why I want logs, metrics, and traces separately.

This one made me more conservative rather than less. Newman is clear that microservices buy organizational independence with operational complexity, and that splitting a system before you can see inside it turns one hard problem into many. Start with the monolith, split for a reason you can name, and get the instrumentation in first, because logging is the prerequisite, not the follow-up ticket.

The strangler fig is now my default shape for any migration, not just service decomposition. Put the new thing beside the old one, route a thin slice of real traffic at it, keep the old path warm, and widen only once the slice is boring. That is the same instinct as blue/green with a rollback you have actually tested, applied over months instead of minutes.

Confirmed the thing my whole Terraform playbook is built on, which is that state is the product rather than a side effect of running apply. It is also where I settled the question of separate directories over a pile of workspaces; the difference shows up the first time you have to change one environment without touching another.

The reconciliation loop is worth taking even if you never run Kubernetes. Declare the desired state, let a controller converge toward it, and stop writing procedures that assume they know the starting point. It is the same model as Terraform, and it is why I think in terms of desired state rather than deployment steps even on ECS, which is where I actually work.

This gave me precise language for something I already half-believed. A mock-heavy test welded to its implementation is a liability that reports itself as an asset, because it fails on every refactor and passes through every real bug. It is the backbone of the argument that a test nobody trusts is worse than no test at all.

Duke separates decision quality from outcome quality: good decisions produce bad outcomes all the time, and grading the decision by the result teaches people to avoid decisions rather than to make better ones. This is the argument for blameless postmortems that finally convinced me, and it is why how I debug starts from stating what I expect to be true and how confident I am, rather than hunting for the change that makes the symptom stop.

The habit I took from this is putting a number on a hypothesis during an incident and revising it out loud as evidence arrives. "Probably the database" cannot be wrong and therefore teaches nobody anything. "Seventy percent the database, and here is what would change my mind" is an actual debugging step that the next person can pick up.

Availability bias is the one that shows up on call. The outage you handled last month feels like the most likely explanation for this one, and it usually is not. Knowing the name of a bias does not disable it, but it is enough to make me check the boring hypothesis before the interesting one, and to distrust the story that arrives too quickly.

Applied to infrastructure, this is the case for practicing failure on purpose. A rollback nobody has run is a hypothesis, not a plan, and a system that has never been stressed is only assumed to be fine. It is why I would rather a deploy be reversible in five minutes than perfect on the first attempt, and why blue/green only counts if you actually keep the old version warm.

The operational reading is short: whoever ships should carry the pager. Not as punishment, as feedback. A team insulated from its own three in the morning will keep designing systems that produce them, because the cost lands somewhere they never have to look. It is half of why I think culture is a delivery variable rather than a soft one.

Gawande's point is that checklists are not a beginner's crutch. They are for the expert under pressure who knows the system well enough to skip a step. That reframed runbooks for me: the audience is me at 2am, not a new hire in week one. It is why I treat runbooks as a byproduct of doing the work rather than a documentation project that never gets scheduled, and why automation should write its output for the person reading it at 2am.

The finding that stuck is that companies scale sub-linearly, like organisms, and eventually stall. The infrastructure translation is that coordination overhead grows faster than headcount, so the clever system that one person holds in their head becomes the bottleneck the moment the team doubles. It is a large part of why I prefer boring and composable over clever.

This is the design principle behind every playbook on this site. "Deploys must be reversible in five minutes" travels between teams, survives contact with a bad week, and can be argued with. A forty-page standard does none of those things. It is also why each playbook here leads with an opinion rather than a procedure.

The scheduling chapter is quietly an operations book. Thrashing is real, context switching has a measurable price, and a system run at full utilization has no slack left to absorb anything at all. That is the error budget argument arrived at from queueing theory instead of from Google, and two independent routes to the same conclusion is worth more than one.

The line I quote most is "don't live with broken windows." Small unfixed ugliness is a signal that quality is optional here, and the signal compounds. The other half is automating anything you have done more than twice, which is why pipeline logic belongs in scripts rather than YAML and why a script that is not safe to run twice is not finished.

That one sentence reframed infrastructure decisions for me. The question is not whether this works, it is what it will cost to keep working for five years while people come and go. It is the reason I care that a Terraform plan stays something a human will actually read and that modules are components rather than environment copies.

The curse of knowledge is why most runbooks fail. The person who wrote it could not see the steps they were skipping, because those steps had stopped being steps. Now I write documentation and postmortems for a reader who does not have my context, which is the same reason automation should say what it did in full sentences.

Unglamorous, and it improved my writing more than anything else on this shelf. Precision is not decoration in this job: an incident update, a commit message, and a failure classification all get read fast by someone who did not want to be reading them. Naming what class a failure belongs to is a writing problem before it is an engineering one.

This is what I use when an infrastructure proposal has to land with people who do not run infrastructure. Concrete beats abstract every time, and one specific story about one specific outage moves a budget conversation further than any risk matrix. Getting funding for reliability work is a communication problem, which is part of what a strategy has to do.

Reassuring for somebody who arrived at infrastructure by way of data analysis and marketing, but the useful part is the argument rather than the comfort. Infrastructure is a wicked domain, and being spread across IaC, pipelines, containers, and observability is a way of having more transferable patterns than any one of them would supply, not a failure to pick a lane.

Operations work is mostly repetition that teaches nothing, because you are performing what you already know while under pressure. Deliberate practice means choosing the thing you are bad at on purpose, with feedback, when the stakes are low. Concretely that means rehearsing the rollback rather than trusting the document that describes it.

The uncomfortable finding is that the study methods that feel effective are the ineffective ones. I run spaced repetition on the things I need cold at 3am rather than assuming I will look them up, and it is the same reason I think a runbook should occasionally be executed rather than only written.

The distill step is the one that earns its keep: notes you have never compressed are notes you will never reread. This is the system behind how I keep working notes, and it turned out to be the prerequisite for getting real work out of an assistant, because a model with access to organized context is a different tool from one you paste into.

Mollick is where the framing on my AI workflow page comes from: the model is something you brief, not something you invoke. His rule about always inviting AI to the table is also why I now try it on tasks I am confident it will fail, because I have been wrong about which ones those are often enough to stop trusting the prediction.