Swizec Teller - a geek with a hatswizec.com

    The Phoenix Project recap

    On my run today I finally finished The Phoenix Project. Long book, 14 hours 😅

    Here's what I learned about "managing IT systems"

    https://twitter.com/Swizec/status/1130254521966317569

    My edition had something like 3 or 4 chapters of The Devops Handbook tacked on the end. That was pretty neat.

    Yes, The Phoenix Project is ultimately a devops book kinda aimed at traditional businesses that don't consider IT a core competency.

    It's 2019. IT is always a core competency.


    You can learn a lot from devops even if you're a dev not an ops.

    Like The Goal, The Phoenix Project is also based on the theory of constraints.

    https://twitter.com/Swizec/status/1122733989012226049


    Your goal when managing the IT process from start – requirements collection – to finish – delivering value in production – should be to improve throughput. It's okay to slow down parts of the system if that improves overall throughput.


    Your project isn't done when you're dev complete and you toss your code over the wall.

    Your project is done when it's in production. It is your job as developer to help with that part. Move config into code. Move infrastructure into code. Develop on production-like systems.


    Reducing batch sizes improves throughput.

    The smaller and less disruptive that deploys are, the more of them you can do.

    The more you deploy, the faster you can see if it's working.

    The faster you see if it works, the faster you can experiment.

    The faster you experiment, the better you respond to the market.

    1 deploy per feature is best. If it breaks, you roll back 1 feature and the rest keeps chugging along.


    Automate deployments. Humans are slow and error prone.

    Let humans focus on designing and improving the system that does the tedious parts automatically.


    Your job is to deliver business value.

    Engineers like to forget that.


    Kanban boards are the best tool we know to visualize how well the system works as a whole.

    Tasks that aren't on the board don't exist. Each work center should have a single point of entry for new work.


    There are 4 types of work:

    • the work itself
    • work that manages work

    • changes

    • putting things in production

    I think? This was difficult to tease out in this format.


    Your clients might get excited that you can take on a whole lot of work. But what they really want is a predictable delivery timeline.

    WIP is killer. Avoid.


    Overall, The Phoenix Project was a great read. The characters were relatable, the lessons were easy to discern, and it's changed the way I think about my work.

    You should give it a read 🤘

    Did you enjoy this article?

    Published on May 19th, 2019 in Technical,

    Learned something new?
    Read more Software Engineering Lessons from Production

    I write articles with real insight into the career and skills of a modern software engineer. "Raw and honest from the heart!" as one reader described them. Fueled by lessons learned over 20 years of building production code for side-projects, small businesses, and hyper growth startups. Both successful and not.

    Subscribe below 👇

    Software Engineering Lessons from Production

    Join Swizec's Newsletter and get insightful emails 💌 on mindsets, tactics, and technical skills for your career. Real lessons from building production software. No bullshit.

    "Man, love your simple writing! Yours is the only newsletter I open and only blog that I give a fuck to read & scroll till the end. And wow always take away lessons with me. Inspiring! And very relatable. 👌"

    ~ Ashish Kumar

    Join 15,883+ engineers learning lessons from my "raw and honest from the heart" emails.

    ⭐️⭐️⭐️⭐️✨
    4.5 stars average rating

    Have a burning question that you think I can answer? Hit me up on twitter and I'll do my best.

    Who am I and who do I help? I'm Swizec Teller and I turn coders into engineers with "Raw and honest from the heart!" writing. No bullshit. Real insights into the career and skills of a modern software engineer.

    Want to become a true senior engineer? Take ownership, have autonomy, and be a force multiplier on your team. The Senior Engineer Mindset ebook can help 👉 swizec.com/senior-mindset. These are the shifts in mindset that unlocked my career.

    Curious about Serverless and the modern backend? Check out Serverless Handbook, for frontend engineers 👉 ServerlessHandbook.dev

    Want to Stop copy pasting D3 examples and create data visualizations of your own? Learn how to build scalable dataviz React components your whole team can understand with React for Data Visualization

    Want to get my best emails on JavaScript, React, Serverless, Fullstack Web, or Indie Hacking? Check out swizec.com/collections

    Want to brush up on modern JavaScript syntax? Check out my interactive cheatsheet: es6cheatsheet.com

    Did someone amazing share this letter with you? Wonderful! You can sign up for my weekly letters for software engineers on their path to greatness, here: swizec.com/blog

    Want to brush up on your modern JavaScript syntax? Check out my interactive cheatsheet: es6cheatsheet.com

    By the way, just in case no one has told you it yet today: I love and appreciate you for who you are ❤️

    Created by Swizec with ❤️