Chris Austin > Recent Status Updates

It's hilarious that they talk about the DORA report showing that AI use reduces stability and productivity, and they describe this as the DORA Anomaly. No, it's not an anomaly, you're just wrong and confirmation bias is at work.

There are a few pieces of good advice in the book, but the majority is fluff and hype

More bad takes. Vibe coding does not easily make most enterprise devs 10x, unless they were 0.1x to start. It accelerates in some areas, hurts in others, but 10x is wrong.

This quote bugs me, "It's unpredictable, like a slot machine, and sometimes you get a bad pull. That's no reason to give up."

Don't play slot machines. They're designed to be addictive and feel like you're close to winning.

This is so lazy: "Yes, there are certainly security concerns with this, but we have confidence that the industry will create solutions that...". Hope is not a strategy.

Also a bit frustrating to have this comment, ".. requires an OAuth authorization header, whatever that is". Not learning about auth while building systems will go so poorly. Ugh.

A very shallow book so far, with bad takes in a few spots. The worst was on page 39, where they talked about the 2024 DORA report, which said that every 25% increase in genai adoption correlates with 7% worse stability and a 1.5% slowdown in throughput. They described this as the "DORA Anomaly" since it was "at odds with our common experience". This is just confirmation bias.

First 60 pages are skippable.

"Nobody should be writing code by hand anymore if they don't have to" is such a bad take. It's also written by people who stopped writing code, so there's an inherent bias.

I truly hate the term Vibe Coding and am dismayed by the mismatch between hype and reality in the industry right now. I've appreciated Gene's other books though, so I'm giving this book a go to see if it has value for me.

There are some good notes, though I'm not getting as much value out of it as I expected. This book really needed more time with an editor, as the writing can be awkward and rushed.

I was looking forward to the sections on NPV and optionality, but they're weak.

I'm enjoying this overall and it has excellent notes about the way layers of requirements are added through new legislation, while existing requirements are not tidied, resulting in an overly complex mess.

The section on GPS had some weird assertions though, which makes me question the technical accuracy in other areas. Comparing UDP and XML+SOAP is a bit odd, and the complexity is overstated.

I'm a little frustrated that their approach to IFS relies very heavily on visualization. I don't visualize, and they haven't offered non-visual alternatives yet.

A decent book overall, though it focuses heavily on hiring executives. There is some outdated thinking, e.g. around body language, and some pieces feel adversarial - e.g. the section around "what will your former bosses say WHEN we call them".

I disagree strongly with: "Don't hire the generalist, hire the specialist". It depends on the problems you need to solve, and depends on whether the person is leading or an individual contributor. I value specialists, but I also need breadth in candidates so they can be effective in a cross functional team, and are able to have some shared context.

The example is misleading. He hired the wrong skillset.

There have been some good sections, and I've taken useful notes, but overall I'm disappointed. They're trying to simplify org problems into Slowification/Simplification/Amplification, but in doing so their shallow case studies sometimes miss important details. The Team of Teams example bothered me - exceptional operators were assigned to diplomatic missions to build trust, not just to amplify signals.

Still a bit slow/shallow for my tastes, which is disappointing since I love the Idealcast podcast by Gene Kim and usually find IT Revolutions books to be excellent.

The slowification/simplification/amplification model is good, though it's staying too shallow, and missing references to things like value stream mapping. I'm taking some useful notes, but mostly from things that it reminds me of.

A bit slow so far. I haven't gotten as much value from it as expected (I had high expectations because of the authors). Thus far I prefer the pacing and style of Sooner Safer Happier.

I've written more while reading this book than I usually do, partly because it has several worksheet exercises that need reflection. I've already made meaningful changes for my team because of the book. The section on cognitive dissonance was particularly helpful.

I wish there was an updated version of this book that covered more modern Swift. The content is good overall and was likely excellent when it was first released. I'm finding myself checking whether some techniques that seem like hack fixes to me are still necessary with the current version of Swift.

The early parts of this book are decent and led to some useful reflection, but it starts to wander a lot later on and often takes multiple pages to convey a simple idea. There was a 3 page section that basically said, "say things simply instead of hiding behind the complexity of your words". It's extremely story driven, with a lot of stories from the author's life, even when the story wasn't necessary.

Thus far I've read ~5 pages of targeted content in 47 pages of paper. Far too much emphasis on writing academic papers - that is not the stated subject for this book, so it should not have been the dominant subject.

My current note taking habits align with this for the most part so far, but there have been a few useful notes. Fairly boring and repetitive so far. Hoping it improves.

Not impressed with the writing style so far. The chapter has a bullet list of what will be covered, followed immediately by a paragraph that basically says the same thing. The examples haven't been explained particularly well yet, but hoping they improve in future chapters

Great quote: "If you want to cut a man's hair, it is better if he is in the room" (a Senegalese proverb)

The book has improved and had some useful notes that weren't captured by the reviews I've read, and some later work on OKR missed some pieces I appreciated in this book.

I'd still recommend people read Sooner, Safer, Happier since it's more actionable and covers more.

Very little actionable content so far, and the examples all go against the advice that the KRs should be quantifiable and not simply boolean. The focus so far seems to be providing context for why OKRs were created, which is useful, but it's a bit too heavy on historical anecdotes for my tastes. A bit like a recipe site that tells you their life story before listing ingredients.

I love this quote from The Art of Action, "Strategy is a deployable decision-making framework, enabling action to achieve desired outcomes, constrained by current capabilities, coherently aligned to the existing context."

An elegant way to express that strategies are meant to guide decisions in complex emergent systems, they are not simply a plan with known steps.

Chapter 10 is a bit light on details, and the breakdown of sociotechnical problems was oversimplified, which is very disappointing. I would have preferred to skip this subject since other books cover it well - "Sooner, Safer, Happier" is my top recommendation, along with "Agile Conversations" and "Team Topologies"

The example maps would be better if there was more narrative around them, and if the text used the same labels as the map. The examples often aren't explained, and some labels aren't defined. There's also too much emphasis on serverless - I'm reading this for Wardley Mapping, not a serverless sales pitch.