Quotes from Gene Kim

Organizations which design systems ...are constrained to produce designs which are copies of the communication structures of the organizations.. the larger an organization is, the less flexibility it has and the more pronounced the phenomenon

I've figured out that the trick to a long career in it Operations management is to get enough seniority to get good things done

One of the most important parts of any improvement initiative is to define a measurable goal with a clearly defined deadline, between six months and two years in the future. It

any improvements made anywhere besides the bottleneck are an illusion. Astonishing, but true! Any improvement made after the bottleneck is useless, because it will always remain starved, waiting for work from the bottleneck. And any improvements made before the bottleneck merely results in more inventory piling up at the bottleneck.

Murphy does exist, so you'll always have unplanned work, but it must be handled efficiently.

Repetition, especially for things that require teamwork, creates trust and transparency.

Broadly speaking, to acheive DevOps outcomes, we need to reduce the effects of functional orientation ("optimizing for cost") and enable market orientation ("optimizing for speed") so we can have many small teams working safely and independently, quickly delivering value to the customer

but to keep your head low enough to avoid the political battles that make you inherently vulnerable. I have absolutely no interest in becoming one of the vps who just give each other PowerPoints all day long.

Ensure releases can always be performed during normal business hours with zero downtime.

limit on [team] size ... ensures the team has a clear, shared understanding of the system they are working on. As teams get larger, the amount of communication required for everybody to know what's going on scales in a combinatorial fashion.

As the saying goes, if your colleague tells you they've decided to quit, it was voluntary. But when someone else tells you they've decided to quit, it was mandatory.

Another way we can enable more market-oriented outcomes is by enabling product teams to become more self-sufficient by embedding Operations engineers within them, thus reducing their reliance on centralized Operations.

If only we had a single view of the customer: top of funnel, bottom of funnel, as well as their complete history with the company. Not only what they purchased, but also what they did on our site, what they browsed, searched for, their credit card transactions, repair history … There's so much potential!

Safety is a precondition of work.

Alert fatigue is the single biggest problem we have right now…We need to be more intelligent about our alerts or we'll all go insane.

To achieve market orientation, we won't do a large, top-down reorganization, which often creates large amounts of disruption, fear, and paralysis. Instead, we will embed the functional engineers and skills (e.g., Ops, QA, Infosec) into each service team, or provide their capabilities to teams through automated self-service platforms that provide production-like environments, initiate automated tests, or perform deployments.

integrating the objectives of QA and Operations into everyone's daily work reduces firefighting, hardship, and toil, while making people more productive and increasing joy in the work we do.

And if we can't experiment, we can't learn!

While the foundation of DevOps can be seen as being derived from Lean, the Theory of Constraints, and the Toyota Kata movement, many also view DevOps as the logical continuation of the Agile software journey that began in 2001.

She flips to the second page. "The projects seem to fall into the following categories: replacing fragile infrastructure, vendor upgrades, or supporting some internal business requirement. The rest are a hodgepodge of audit and security work, data center upgrade work, and so forth.

Instead of merely documenting the specifications of the production environment in a document or on a wiki page, we create a common build mechanism that creates all of our environments, such as for development, test, and production. By doing this, anyone can get production-like environments in minutes, without opening up a ticket, let alone having to wait week.s

Make infrastructure easier to rebuild than to repair

DevOps isn't about automation, just as astronomy isn't about telescopes.

we typically segment the customer base, so we know what set of problems each faces.