Part 1

The first half of the book is chaos. Filled with unprofessionalism (Bill might be one of the worst!) and naivety. I think the most valuable thing I got from this part of the book is a list of red flags:

  • Colleges that, on purpose or not, bottleneck work to them (or get work bottlenecked to them by others).
  • IT department with no documentation.
  • Inexistent or broken change process.
  • Business believes a software will solve all their problems.
  • Other departments reaching out directly to certain people to lure them into doing their bidding (this steals teams capacity).
  • Security team instead of helping the business just uses resources for irrelevant work and blocks other teams from doing their work.
  • Leadership (CEO, CTO, etc) incapacitated of making impartial and fully aware decisions.
    • Incapacitation can happen from:
      • Pressure, e.g. stakeholders putting pressure to get quick results.
      • Sweet talking, e.g. VPs sweet talking them into being favourites to get their projects prioritized (based solely in their relationship).
      • False promises, e.g. VPs lying about progress to get their projects prioritized.

Part 2

In the second half of the book, which is after all major IT disasters and Bill and John individually going through their own internal journeys trying to get their heads out of their asses, very interesting ideas are presented in the book.

The topics that caught my attention are:

  • We only win when the business wins.
  • Identify types of work (this will help with the next bullet points 🙂). 4 types of work are presented in the book, however, please, don’t blindly try to work with these… keep in mind that you have to analyze your situation and use your best judgement to identify your “types of work”.
    • Business projects.
    • Internal projects.
    • Operational change.
    • Unplanned work.
  • Learn how to properly allocate time for each type of work and know/learn:
    • How to prioritize.
    • The teams capacity (so you know how to prioritize work).
    • When to push back (to protect the teams capacity for the right priorities).
  • Be proactive and seek to understand the business and other teams needs.
  • Identify repetitive work (patches, firewall changes, certain PRs, etc) and improve current processes.
  • Feedback:
    • Only a few people you trust will be able to give you honest feedback, listen to them and learn.
    • When giving feedback, be honest and truthful.

Part 3

In the last part of the book things were not so chaotic anymore and DevOps concepts are introduced. Some of the ideas in the book:

  • Fail fast - builds, tests, etc should fail fast so we can fix it asap (we can’t have a pipeline running for 40mins to see it fail just at the end lol).
  • Constant feedback - this is valid for software and teams. When building software you should build it constantly. When talking about teams “daily meetings” can help accomplish that.
  • You might have to throw everything into the garbage and restart again. But restart right.
  • Continuous Integration - keep commit cycles short.
  • Continuous Delivery - automate deployments to/for DEV, QA, SEC, etc.

Additional Conclusions

  • must build resilience and increase capacity in the team.