#cookebooks: The Systems Bible, by John Gall (3rd ed.): destiny is largely a set of unquestioned assumptions

#cookebooks: The Systems Bible, by John Gall (3rd ed.): destiny is largely a set of unquestioned assumptions

Score

4.5 out of 5

What's the premise?

Failure is the default mode of systems. We should take a much more humble and realistic view of the extent to which systems solve problems - recognising that, in fact, the deployment of a system to "solve" a problem may cement the problem (as something so significant that it needs a system to solve it) and distract attention from the real issue (what caused the problem to arise in the first place).

As the book states:

Systems are seductive. They promise to do a hard job faster, better and more easily than you could do it by yourself. But if you set up a system, you are likely to find your time and effort now being consumed in the care and feeding of the system itself. New problems are created by its very presence ... You become anxious and push on it to make it work. Eventually you come to believe that the misbegotten product it so grudgingly delivers is what you really wanted all the time. At that point, encroachment has become complete. You have become absorbed. You are now a systems-person.

What did I learn from it that I can apply now?

The style of this book is deliberately and conspicuously odd. It is hyper-literate and florid. It is absurd. But: a clear-eyed reader will not allow this to distract them from the essential truths it contains - for example:

  • A system represents someone's solution to a problem; the system itself does not solve problems
  • Do it with an existing system if you can; do it with a small system if you can
  • Almost anything is easier to get into than out of
  • A temporary patch will very likely become permanent
  • The ghost of the old system continues to haunt the new
  • The chart is not the patient (i.e. if the system tells you that a person is healthy, but your own eyes tell you he or she is dying, then trust your eyes)
  • A complex system that works is invariably found to have evolved from a simple system that worked (and, in parallel: a complex system designed from scratch never works, and cannot be made to work - you have to start over, beginning with a working simple system)
  • Perfection of planning is a symptom of decay; loose systems last longer and function better
  • A system that ignores feedback has already begun the process of terminal instability
  • Bad design can rarely be overcome by more design, whether good or bad
  • Plan to scrap the first system - you will anyway
  • The meaning of a communication is the behaviour that results; it is impossible to not communicate
  • Knowledge does not keep any better than fish; the most urgently needed communication decays fastest

TLDR: don't build systems, but instead solve the problems you encounter directly. I knew these things, like you know these things; but to have all of them set out in a book you can read in an hour is a powerful thing.

Should you read it?

Reader, I promise you that I do not read all books thinking "yes but what does this mean for legaltech???" - but it is hard to read this specific book without concluding that it is an absolutely essential text for anyone who finds their inbox bombarded by landfill CLM vendors and AI bullshitters various, beckoning the time-pressed GC through their wardrobe and into a world where the 5000 sales people screaming at them 24/7 are magically converted by the power of a VC-friendly sticky SaaS legal ecosystem into grateful chorus of net promoters. Obviously, small systems are better than large systems. Obviously, we place too much faith in systems as a tool to solve problems (and pay insufficient attention to the problems created by systems). Obviously systems are not just their technology but also the people who become subsumed within them.

It's not completely perfect:

  • the hardcopy is insanely priced, which meant I had to buy it on Kindle (*).
  • the style is divisive. Several folks on Goodreads absolutely despise this book "I really struggled to find a way to put into words why I hated this book" - lol). I would say that there are parts of it which sing, and parts of it which merely hum along (particularly as it starts to abstract out in the final third of the book).

Would I read it again?

Yes sir. Even while taking a brief detour into fiction (Hari Kunzru's Red Pill - 1.3/5, deeply pretentious; Jia Tolentino's I Would Be Doing This Anyway - 2.4/5, a bit "will this do?") and history (Vincent Bevins' The Jakarta Method - 5/5, shocking, expansive), I kept diving back into this book to meditate on its observations.

========

*a little note on method: turns out I have next to zero recollection of Kindle books after I have read them. Highlighting and note taking using the in-Kindle functionality does not help. In contrast, I can blast through a paper copy of a book, turn over a page corner to mark an interesting passage on a page and, once I have finished, I will have a solid chance of recalling exactly what caused me to linger on that passage when I go back to those corner-turned pages. So, from now on: all hard copies.

Alex Hamilton

CEO of Radiant Law and author of SIGN HERE: the enterprise guide to closing contracts quickly

1 年

I wrote a piece applying Systemantics to CLMs ?? agree The System Strikes Back https://www.dhirubhai.net/pulse/system-strikes-back-alex-hamilton

回复
Paul Lacey

AI Agents for Expert Teams

1 年

Thanks, Andrew Cooke - not read this. How often is this true: "A temporary patch will very likely become permanent". Reading your bullets, this could very easily translate into product design principles (kind of obvious, being a system in itself, but neat.)

要查看或添加评论,请登录

Andrew Cooke的更多文章

社区洞察

其他会员也浏览了