Skip to content

Instantly share code, notes, and snippets.

@robinbraemer
Created July 16, 2025 07:55
Show Gist options
  • Select an option

  • Save robinbraemer/456d488bda6dc526f663a25b1aa78a50 to your computer and use it in GitHub Desktop.

Select an option

Save robinbraemer/456d488bda6dc526f663a25b1aa78a50 to your computer and use it in GitHub Desktop.
  1. The First Way: Flow (Systems Thinking)

    • Emphasizes the optimization of the entire system's flow of work, not just individual silos. The goal is to accelerate the movement of work from development through operations to the customer.
    • Practices include making work visible (e.g., Kanban boards), limiting work-in-progress, reducing batch sizes, and removing constraints or bottlenecks[2][4][3].
  2. The Second Way: Feedback Loops

    • Focuses on creating short, constant feedback loops at every stage of development and operations, so errors and quality issues are detected early and improvements are made continuously.
    • Practices include shift-left testing, quick reviews, embedding knowledge where needed, and encouraging collaboration between departments[2][4][3].
  3. The Third Way: Continual Learning and Experimentation

    • Promotes a culture of safe experimentation, learning from both successes and failures, and constant improvement.
    • Practices include allowing time for improvement, rewarding risk-taking, and institutionalizing practices that encourage learning at all levels of the organization[2][4][3].

These principles are widely adopted as a framework for successful DevOps organizations, aiming to bring together people, process, and technology to deliver value to customers in a reliable and continuous way.

There is also a political concept known as The Third Way, which refers to a centrist political approach blending right-wing and left-wing politics, but in most IT, business, and organizational contexts, The Three Ways refers specifically to the DevOps principles discussed above[5].

The Phoenix Project - Reading Notes

Key Themes & Connections to cnap.tech

Organizational Change

  • Bill's promotion = sudden leadership change, chaos everywhere
  • Company almost failing because of Phoenix Project delays
  • Connection to cnap.tech: Small teams also face sudden changes when adopting new deployment tools
  • Change is messy, people resist it even when it's obviously needed

Digital Transformation Struggles

  • Old way: everyone works in silos, throws stuff over the wall
  • IT vs Business units constantly fighting
  • Real insight: Technology change isn't just about the tech - it's about how people work together
  • Phoenix Project fails because of communication gaps, not technical issues

Team Collaboration Breakdown

  • Dev team vs Ops team = constant conflict
  • Nobody talks to each other properly
  • Brent = the hero/bottleneck person (every team has one)
  • Psychology angle: People protect their turf, scared of being blamed

Work Psychology Observations

Psychological Safety

  • Beginning: People afraid to speak up about problems
  • Bill's team meetings = people finally start being honest
  • Key moment: When team admits they've been hiding issues to avoid blame
  • Creates environment where people can say "this is broken" without getting fired

Change Resistance

  • Developers hate ops people changing their code
  • Operations team resists automation because they think it'll replace them
  • Psychology: People resist change when they feel threatened or don't understand benefits
  • Sarah (developer) initially pushes back on DevOps practices

Team Dynamics

  • Siloed departments = tribal mentality
  • Dev vs Ops = classic us vs them
  • Tuckman's stages: Team goes through forming, storming, norming, performing
  • Trust building takes time, can't be rushed

Stress & Burnout

  • Constant firefighting mode
  • Brent working 80+ hour weeks
  • Burnout symptoms: People making more mistakes, getting sick, quitting
  • Crisis mode becomes normal = toxic culture

General Insights (Beyond IT)

Systems Thinking

  • Problems aren't isolated - everything connects
  • Fix one bottleneck, another appears
  • Universal principle: Organizations are complex systems, not machines

Leadership Patterns

  • Bill learns to step back, see bigger picture
  • Good leaders create safety for teams to experiment
  • Applies everywhere: Whether it's tech teams or restaurant kitchens

Communication Breakdowns

  • Information gets lost between departments
  • Assumptions kill projects
  • General rule: Most "technical" problems are actually communication problems

Connections to cnap.tech Project

Technical Side

  • DevOps principles = faster, safer deployments
  • Automation reduces human error
  • Continuous integration/deployment concepts

Human Side

  • Small teams using cnap.tech will face same resistance to change
  • Need to make adoption feel safe, not threatening
  • Documentation and training matter more than features

Platform Design Implications

  • Make it obvious how different roles work together
  • Reduce blame culture through better visibility
  • Simple onboarding to reduce change resistance

Questions for Check-in Discussion

  1. How do the psychological safety concepts apply to other industries?
  2. What's the difference between individual stress and systemic organizational stress?
  3. How can technology platforms like cnap.tech actually support better team dynamics?
  4. Are there cultural differences in how teams handle change?

Random Thoughts

  • The mentor character (Erik) = classic wise teacher trope, but his systems thinking lessons are solid
  • Book feels a bit male-dominated, would be interesting to see how diverse teams handle these challenges
  • Phoenix Project = phoenix rising from ashes metaphor, but also shows how things can burn down first
  • Wonder if remote teams have different dynamics around these same problems

Analysis - Connecting to Psychology Theories

Psychological Safety (Edmondson)

  • Scene: Board meeting where Bill finally admits Phoenix is failing
  • Theory connection: Creating environment where people can admit problems without punishment
  • Beyond IT: Same pattern in hospitals (medical errors), manufacturing (safety incidents), any high-stakes environment

Change Resistance (Kotter's Model)

  • Scene: Operations team pushing back on automation tools
  • Theory connection: People resist when they don't see urgency or personal benefit
  • Universal pattern: Whether it's new software, new processes, or organizational restructuring
  • Key insight: Need to create urgency first, then show benefits

Team Development (Tuckman)

  • Forming: Bill's new team, everyone cautious
  • Storming: Dev vs Ops conflicts, blame games
  • Norming: Start of collaboration, shared goals
  • Performing: Successful Phoenix delivery
  • Works everywhere: Sports teams, project groups, startup teams

Burnout & Stress (Maslach)

  • Brent's situation: Classic burnout - exhaustion, cynicism, reduced accomplishment
  • Systemic issue: Organization depends on heroes instead of good processes
  • General application: Any role where people become single points of failure

Transformation Patterns (Non-Tech Applications)

Manufacturing Example

  • Same silos: Design vs Production vs Quality
  • Same bottlenecks: Key people everyone depends on
  • Same communication gaps: Departments not talking

Healthcare Example

  • Doctors vs Nurses vs Administration
  • Patient handoffs = information loss
  • Crisis mode = normal mode (sound familiar?)

Small Business Example

  • Founder vs Employees vs Customers
  • Growth creates new bottlenecks
  • Scaling requires letting go of control

Cultural Factors in Organizational Change

Hierarchy vs Flat Structure

  • Book shows American corporate culture
  • Wonder how this plays out in more hierarchical cultures (German companies?)
  • Or more collaborative cultures (Nordic countries?)

Blame Culture vs Learning Culture

  • Phoenix Project starts with blame culture
  • Transformation = shift to learning culture
  • Some cultures naturally more blame-focused than others

Individual vs Collective Orientation

  • Book focuses on individual heroes (Bill, Brent)
  • Collective cultures might handle transformation differently
  • Team success vs individual success
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment