What is *The Phoenix Project* by Gene Kim about?

*The Phoenix Project* is a business novel that follows IT manager Bill Palmer as he rescues Parts Unlimited from collapse by overhauling chaotic IT operations. Through DevOps principles like automation, collaboration, and workflow optimization, Bill transforms unplanned work, bottlenecks, and siloed teams into a streamlined system. The book uses a fictional narrative to teach real-world strategies for aligning IT with business goals.

Who should read *The Phoenix Project*?

This book is ideal for IT professionals, DevOps engineers, and managers seeking to improve organizational efficiency. It’s also valuable for executives navigating digital transformation, as it illustrates how broken processes hinder innovation. Gene Kim’s storytelling makes complex concepts like continuous delivery and systems thinking accessible to non-technical readers.

Is *The Phoenix Project* worth reading?

Yes—it’s a foundational DevOps text with over 1 million copies sold. The novel format simplifies technical ideas like the Three Ways of DevOps and the Theory of Constraints, offering actionable insights for reducing IT bottlenecks. Its Shingo Publication Award and enduring relevance in tech education underscore its impact.

What are the key concepts in *The Phoenix Project*?

- **The Three Ways**: Flow (optimizing workflows), Feedback (rapid issue resolution), and Continual Learning (experimentation). - **Theory of Constraints**: Identifying bottlenecks like Brent, the overburdened engineer. - **Unplanned work**: How reactive firefighting derails strategic projects.

How does *The Phoenix Project* use the Theory of Constraints?

The book applies Eli Goldratt’s theory by depicting Brent as a bottleneck—his unique skills cause delays when overloaded. By redistributing Brent’s responsibilities and documenting solutions, the team increases throughput. This mirrors Goldratt’s focus on aligning resources with systemic goals.

What is the significance of Brent’s role in the story?

Brent symbolizes single points of failure in IT systems. His constant firefighting highlights the risks of tribal knowledge and poor documentation. Resolving his overload through cross-training and escalation protocols becomes pivotal to Parts Unlimited’s turnaround.

How does *The Phoenix Project* address unplanned work?

Unplanned work—like constant server outages—consumes 90% of IT’s capacity, stifling innovation. The solution involves prioritizing planned work, creating escalation policies, and using Kanban boards to visualize workflows. This shift enables the team to focus on strategic initiatives like the Phoenix rollout.

What are the Three Ways of DevOps in *The Phoenix Project*?

1. **Flow**: Streamlining deployments to accelerate value delivery. 2. **Feedback**: Implementing monitoring to quickly detect issues. 3. **Continual Learning**: Cultivating a culture of experimentation and blameless post-mortems.

피닉스 프로젝트

IT, DevOps, 그리고 비즈니스의 성공을 돕는 소설

진 킴, 케빈 베어, 조지 스파포드

3.38(8 Reviews)

피닉스 프로젝트 개요

IT 부서의 최악의 악몽이 DevOps 문화를 혁신한 흥미진진한 비즈니스 소설이 되었습니다. 50만 부 이상 판매된 **프로젝트 피닉스(The Phoenix Project)**는 전 세계 기술 팀의 운영 방식을 변화시켰습니다. 팀 오라일리(Tim O'Reilly)는 이 책을 "실패한 모든 IT 프로젝트를 위한 필수 필독서"라고 부릅니다.

전달 방식을 선택하세요

한 권의 책, 다양한 듣기 방식.

피닉스 프로젝트의 같은 아이디어를 담았습니다. 나에게 맞는 목소리, 깊이, 속도를 고르고 언제든 바꿔 보세요.

1장

When IT Becomes a Battleground: The Phoenix Project's Wake-Up Call

In a world where technology drives business success, The Phoenix Project stands as a landmark novel that transformed how organizations think about IT operations. Published in 2013 by Gene Kim, Kevin Behr, and George Spafford, this business novel has sold over 400,000 copies and become required reading in MBA programs, computer science departments, and corporate boardrooms worldwide. Its influence extends beyond IT departments-even Wall Street Journal has recognized its impact on modern business practices. The book follows Bill Palmer, an IT operations manager suddenly promoted to VP, as he navigates a perfect storm of technical disasters that threaten to sink his company. Through his journey, readers discover powerful principles that bridge the gap between IT operations and business value-principles that have since sparked the global DevOps movement transforming how companies deliver technology.

2장

The Perfect Storm: When Everything Falls Apart

Bill Palmer is having the worst day of his professional life. Reluctantly promoted to VP of IT Operations at Parts Unlimited, an automotive parts manufacturer and retailer, he's immediately thrust into crisis mode. The company's critical Phoenix Project-an e-commerce initiative meant to restore profitability-is years behind schedule and millions over budget. The payroll system has mysteriously crashed, threatening to leave thousands of employees unpaid, with the finance department already fielding panicked calls from workers living paycheck to paycheck. And the CEO, Steve Masters, has just informed him that if they don't turn things around in 90 days, the board might outsource the entire IT department to an offshore provider, potentially affecting hundreds of jobs. As Bill races to understand the payroll failure, he discovers a chaotic IT environment where changes happen without proper controls or documentation. A security-related "tokenization" application was rushed into production without adequate testing, corrupting employee data across multiple systems and creating inconsistencies between HR and payroll databases. The storage area network (SAN) is displaying cryptic error messages in Japanese characters after a failed firmware upgrade, which was attempted during peak business hours without proper backup procedures in place. The company's most knowledgeable engineer, Brent, is constantly pulled in different directions by competing priorities from various departments, creating a critical bottleneck that affects every project and system maintenance task. The situation deteriorates further when Bill learns the company faces 952 IT general control deficiencies in their SOX-404 audit, including two potential material weaknesses that could trigger SEC reporting issues and impact investor confidence. The audit findings reveal missing change management procedures, inadequate access controls, and insufficient disaster recovery planning. With Phoenix deployments causing repeated store system outages affecting retail operations across multiple time zones, customer credit card data being leaked through unsecured development environments, and the board considering splitting up the company to salvage shareholder value, Bill finds himself in an impossible position-trying to keep critical systems running while simultaneously transforming how IT operates. What makes The Phoenix Project so compelling is how accurately it portrays the dysfunctional relationship between IT and business that exists in countless organizations. The firefighting mentality that prioritizes quick fixes over sustainable solutions, the blame game between development and operations teams, the impossible demands from business units who don't understand technical constraints, and the mounting technical debt from years of shortcuts-these aren't fictional problems but daily realities for IT professionals worldwide. The book resonates deeply with its readers because it reflects common experiences: the late-night emergency calls, the stressed-out teams, the technical decisions made under pressure, and the constant struggle to balance innovation with stability. As one reader commented after finishing the book, "It's like they've been hiding in our building, documenting our daily struggles."

들리는 모든 단어를 눈으로 확인하세요

피닉스 프로젝트의 각 단어가 오디오에 맞춰 실시간으로 강조되어 편하게 따라 읽을 수 있습니다.

3장

The Four Types of Work: Revealing the Hidden Factory

During a pivotal chance meeting with Erik Reid, a seasoned manufacturing expert and potential board member, Bill receives his first fundamental lesson in understanding IT operations. Erik takes Bill on an enlightening visit to the company's manufacturing plant, using this tangible environment to demonstrate why IT is failing - it doesn't recognize or properly manage the four distinct types of work flowing through its "factory." This manufacturing analogy becomes the cornerstone for understanding IT operations in a new light. Standing on a catwalk overlooking the bustling factory floor, Erik delivers a masterclass in how manufacturing was revolutionized by controlling work-in-process inventory through three key principles: Theory of Constraints (focusing on identifying and addressing bottlenecks), Lean production (eliminating waste and improving flow), and Total Quality Management (ensuring quality at every step). He introduces his transformative "Three Ways" philosophy: first, creating fast flow from Development to Operations to deliver value quickly; second, shortening and amplifying feedback loops to identify and fix quality issues early; and third, fostering a culture of continuous experimentation and learning to improve processes systematically. As Bill implements a new change management process using a visual system of index cards on a board - a simple but effective Kanban-style approach - he experiences a crucial epiphany. The first three types of work emerge clearly: business projects (strategic initiatives like Phoenix), internal IT projects (infrastructure improvements and technical debt reduction), and changes to existing systems (updates, patches, and modifications). However, it takes a severe crisis - a major credit card processing outage - for Bill to fully grasp the fourth and most insidious type: unplanned work, the firefighting that consumes resources and derails planned activities. This unplanned work, as Erik later emphasizes, is "the most destructive type of work" in any IT organization. Like matter meeting antimatter, it completely obliterates planned work with devastating efficiency. Each emergency pulls key resources like Brent, the indispensable engineer, away from critical projects, creating a vicious cycle where important strategic work never reaches completion. The constant interruptions not only delay projects but also create additional technical debt that generates more unplanned work in the future. The novel masterfully illustrates how unplanned work isn't merely an inconvenience - it's a glaring symptom of deeper systemic problems in the IT value stream. When Bill implements a "Brent protection plan" to shield his key engineer from interruptions and keep him focused on Phoenix, the change management board reveals another disturbing reality: sixty percent of scheduled changes aren't completing successfully, creating a growing backlog of work-in-process (WIP). Erik describes this accumulation as "the silent killer" - a mounting technical debt that threatens to overwhelm the entire system. Through these experiences and challenges, Bill learns that effectively managing IT requires understanding and controlling these four work types, just as manufacturing plants must meticulously control their inventory and production flow. This framework provides readers with a powerful analytical tool to examine their own IT operations and identify where constraints are creating bottlenecks that impede progress and efficiency. The parallel between manufacturing and IT operations becomes increasingly clear: without proper work management, both systems will inevitably face declining productivity and mounting chaos.

4장

The Phoenix Disaster: When Deployment Becomes a Death March

The Phoenix deployment scenes provide some of the book's most visceral moments, capturing the anxiety and chaos familiar to anyone who's participated in a high-stakes software release. Despite Bill's improvements to change management processes, the Phoenix deployment becomes a nightmare that keeps the team working through the night, highlighting how even well-intentioned processes can fail catastrophically under pressure. What begins as a scheduled four-hour deployment stretches into a crisis when the database migration fails after completing only thirty percent of the required steps. The team discovers that Brent had made an undocumented production database change weeks earlier for one of Sarah's business intelligence modules, creating a conflict with Phoenix's changes. This seemingly minor oversight cascades into a major crisis, requiring the team to manually rename database columns affecting hundreds of files and support scripts. The situation is further complicated by the tight timeline, with stores opening in mere hours and millions in potential revenue at stake. The scene perfectly captures the tension between Development and Operations that plagues many organizations. Chris's development team creates code without understanding operational realities, while Operations lacks visibility into what's changing until it's too late. This disconnect manifests in multiple ways: developers testing in environments that don't match production, changes being made without proper documentation, and a lack of automated testing to catch conflicts early. The result is a system so fragile that each deployment becomes a high-risk event requiring heroics to succeed. The human cost of this dysfunction becomes evident as the team struggles through the night. Brent's undocumented changes, though well-intentioned, reveal the dangers of tribal knowledge and the absence of proper change management protocols. The development team's frustration with operations' "bureaucracy" and operations' distrust of development's "reckless" changes exemplify the cultural divide that exists in many IT organizations. What makes this scenario so compelling is how it demonstrates the consequences of poor flow in the IT value stream. Without proper environment parity between development, testing, and production, without automated testing, and without small, frequent deployments, each release becomes increasingly dangerous. The Phoenix deployment illustrates how large, infrequent releases amplify risk exponentially. As Erik later explains, large batch sizes create high variability that cascades through systems, resulting in long lead times and poor quality. The team's reliance on manual processes and heroic efforts becomes a self-perpetuating cycle, making each subsequent deployment more risky. The Phoenix disaster serves as a turning point in the narrative, forcing the organization to confront fundamental questions about how they deliver technology. It illustrates that deployment problems aren't just technical issues but symptoms of organizational dysfunction that requires rethinking the entire development and operations relationship. This crisis becomes the catalyst for implementing DevOps practices, including automated testing, continuous integration, and improved communication channels between teams.

피닉스 프로젝트에서 더 많은 것을 얻으세요

매일 새로운 인사이트를 10만 개 이상의 레슨에서 만나보세요
단어가 강조되어 오디오와 실시간으로 동기화됩니다
내 라이브러리를 저장하고 모든 기기에서 이용하세요

5장

The Three Ways: A New Philosophy for IT

At the heart of The Phoenix Project is Erik Reid's "Three Ways" philosophy-principles that provide a framework for understanding how to improve IT performance. These principles, drawn from Lean manufacturing, become Bill's guide for transforming Parts Unlimited's dysfunctional IT department. The First Way focuses on optimizing flow from left to right-from Development to Operations to customers. Bill implements this by making work visible through kanban boards, limiting work-in-process, reducing batch sizes, and identifying constraints like Brent. When Patty creates a service request board with columns for "Ready," "Doing," and "Done," she transforms laptop replacements from an unpredictable process to one with consistent, reliable delivery times. The Second Way emphasizes creating fast feedback loops from right to left. Bill implements this by improving incident response procedures, conducting blameless postmortems, and implementing monitoring systems that detect problems before customers notice. When John suggests integrating security teams with development rather than inspecting security after deployment, he's applying Second Way principles to shift quality earlier in the process. The Third Way focuses on creating a culture of continual learning and experimentation. This manifests when the team implements "Chaos Monkey" exercises that randomly kill processes to ensure system resilience, and when they adopt a scientific approach to improvement with explicit hypotheses and experiments. Erik's insistence that "practice creates habits that lead to mastery" reflects this principle. What makes the Three Ways powerful is how they provide a coherent philosophy that addresses both technical and cultural aspects of IT transformation. They're not just abstract concepts but practical guides for action that Bill applies throughout his journey. When he protects time for infrastructure improvements, he's applying the Third Way. When he implements change management processes, he's applying the First Way. When he improves monitoring to detect problems earlier, he's applying the Second Way. The Three Ways have since become foundational concepts in the DevOps movement, providing organizations with a framework for understanding how to improve their technology value streams. They've proven applicable across industries and technology stacks, from startups to enterprises, from web applications to mainframes.

6장

Breaking Down Silos: The Birth of DevOps at Parts Unlimited

One of the book's most powerful themes is the transformation of adversarial relationships between Development and Operations into collaborative partnerships. This journey begins with a painful recognition of the "core, chronic conflict" between these groups: Development is incentivized to deliver changes quickly, while Operations is rewarded for stability and uptime. This fundamental tension manifests in numerous ways, from blame-shifting during outages to resistance against new deployments, creating a toxic environment that ultimately harms the business. The breakthrough comes when Bill, Chris, Wes, and Patty form the "Unicorn" SWAT team to deliver critical revenue-generating features faster than the main Phoenix project allows. By bringing together developers, operations staff, QA, and security from the beginning, they create what Erik later describes as a "super-tribe" that transcends traditional silos. This cross-functional team structure proves revolutionary, allowing them to address problems holistically rather than throwing issues "over the wall" between departments. The novel brilliantly illustrates how this collaboration transforms their work. When the team maps out their deployment process, they discover over a hundred steps spanning Development and Operations, with most having problems in previous launches. The mapping exercise reveals shocking inefficiencies: manual handoffs, inconsistent environments, and redundant approval processes that added weeks to delivery times. Together, they identify environment availability and deployment packaging as key constraints and develop solutions that benefit both groups, including automated environment creation and standardized deployment procedures. The results are dramatic: the Unicorn team progresses "remarkably well" with a clean code base decoupled from Phoenix. Brent and William create build procedures that simultaneously generate identical development, QA, and production environments-something unprecedented that allows developers to be productive immediately. These standardized environments eliminate the common "it works on my machine" problem and reduce deployment failures by 60%. Sprint intervals shrink to two weeks, allowing faster planning and execution, while deployment times decrease from days to hours. What makes this transformation believable is that it doesn't happen overnight or without resistance. Wes initially resists security's involvement, viewing it as another bureaucratic hurdle. Developers are skeptical about operations' concerns, dismissing them as overly cautious, while operations sees developers as reckless. The cultural differences between groups (Bill describes developers as "indie musicians" compared to operations' disciplined approach) create tension and miscommunication. However, through shared goals, joint problem-solving sessions, and accumulated successful deployments, these groups gradually learn to work together effectively. This journey from silos to collaboration mirrors the real-world emergence of DevOps as a movement that bridges traditional IT divides. The novel shows that DevOps isn't just about tools or processes but about creating a shared understanding and responsibility for delivering technology that serves business needs. The transformation at Parts Unlimited demonstrates how breaking down organizational barriers, aligning incentives, and fostering a culture of collaboration can lead to dramatic improvements in both speed and reliability of software delivery.

들리는 모든 단어를 눈으로 확인하세요

피닉스 프로젝트의 각 단어가 오디오에 맞춰 실시간으로 강조되어 편하게 따라 읽을 수 있습니다.

7장

From Months to Minutes: The Deployment Revolution

Perhaps the most radical concept Erik introduces is the idea of performing ten deployments per day-a goal that initially seems impossible to Bill. When Erik reveals that companies like Flickr were achieving this back in 2009, deploying at rates a thousand times faster than industry standards, it challenges fundamental assumptions about how software should be delivered. Other tech giants like Amazon and Google were also pushing thousands of changes into production daily, demonstrating that rapid deployment wasn't just theoretical but achievable at scale. The novel traces Bill's journey from skepticism to understanding as he learns how to create a "deployment pipeline" where everything-not just code but everything needed to build environments-goes into version control. This includes database schemas, configuration files, environment variables, and even documentation. The entire environment creation process must be automated to reduce setup times and eliminate errors. This approach, known as "Infrastructure as Code," ensures that environments can be recreated consistently and reliably, eliminating the "works on my machine" syndrome that plagues many development teams. This transformation becomes real when the Unicorn team adopts these practices. They start with weekly deployments and progress toward daily releases, with smaller batch sizes enabling quick changes and A/B testing. By breaking down large releases into smaller, more manageable chunks, they reduce risk and complexity. This dramatically improves their market responsiveness, allowing them to experiment with customer promotions and quickly adapt based on results. The team implements feature flags to control feature rollouts and dark launches to test new functionality with minimal risk. The Thanksgiving promotion demonstrates both the power and challenges of this approach. The unprecedented response crashes their e-commerce systems, but their improved processes allow them to quickly implement solutions: adding servers, optimizing database queries, and moving large graphics to a content distribution network. The team's ability to make rapid, controlled changes enables them to respond to the crisis in real-time. By Monday, they've not only resolved the crisis but helped create the company's first profitable quarter in over a year, proving the business value of their new deployment capabilities. What makes this storyline compelling is how it connects technical practices like continuous integration, automated testing, and infrastructure as code to business outcomes like faster time to market and increased revenue. The novel shows how automated testing at all levels - unit, integration, and performance - creates a safety net that enables rapid change. It demonstrates that deployment frequency isn't just a technical metric but a competitive advantage that allows organizations to respond more quickly to market changes and customer needs. The ability to deploy quickly becomes a key differentiator in the market, enabling companies to outmaneuver competitors and better serve customers. This message has resonated deeply with organizations struggling with slow, painful deployment processes. The novel's vision of rapid, reliable deployments has inspired countless IT transformations, with companies across industries working to reduce their deployment lead times from months to minutes. Success stories from diverse sectors - from financial services to retail - show how these principles can be applied beyond just software companies, creating a new standard for operational excellence in the digital age.

8장

Beyond Technology: The Human Side of Transformation

While The Phoenix Project contains plenty of technical detail, its most powerful insights concern the human aspects of IT transformation. The novel explores how trust, leadership, and organizational culture determine whether technology initiatives succeed or fail. This theme emerges powerfully during an off-site meeting where Steve asks everyone to share personal histories to build trust. Chris reveals his struggle with infertility and premature twins. Wes shares his failed relationships and weight issues. Patty discloses her background as a touring musician with an arrest record. Bill reluctantly discusses his alcoholic father and his determination to be a better parent. These vulnerable exchanges transform the team's dynamics, creating psychological safety that enables honest communication about work challenges. This high-trust environment becomes essential when they later need to make difficult decisions about project priorities and resource allocation. The novel also explores different leadership styles through characters like Steve (the demanding but ultimately supportive CEO), Sarah (the politically savvy but self-interested SVP), and Bill himself, who evolves from a reluctant leader to someone capable of challenging executives when necessary. When Bill stands up to Steve during the invoicing crisis, declaring "I can't be held responsible for this FUBAR situation," it represents a crucial moment in his leadership development-one where he establishes boundaries around what his team can reasonably accomplish. Perhaps most importantly, the book examines how organizational culture shapes technology outcomes. Erik introduces Bill to Dr. Ron Westrum's three organizational culture types: pathological (fear-based), bureaucratic (rule-based), and generative (mission-focused). The novel shows Parts Unlimited's journey from a pathological culture where problems are hidden and blame is assigned, toward a generative culture where information flows freely and failures become learning opportunities. This transformation is evident in how the team handles incidents. Early in the book, outages trigger finger-pointing and defensiveness. By the end, they've implemented blameless postmortems and rehearsed procedures that allow them to respond calmly and effectively to problems. When John evolves from a security obstructionist to a collaborative partner who integrates security into daily work, it represents a cultural shift that improves both security outcomes and development speed.

피닉스 프로젝트에서 더 많은 것을 얻으세요

매일 새로운 인사이트를 10만 개 이상의 레슨에서 만나보세요
단어가 강조되어 오디오와 실시간으로 동기화됩니다
내 라이브러리를 저장하고 모든 기기에서 이용하세요

9장

The Phoenix Rises: Transformation and Triumph

The novel's final chapters show how Parts Unlimited's IT transformation drives broader business success. The Unicorn project's promotions break sales records, leading to the company's first profitable quarter in over a year. The board withdraws its proposal to split the company, and analyst firms raise the stock price targets. What makes this conclusion satisfying is that it doesn't present a perfect ending-challenges remain, and new problems emerge. When their largest competitor starts offering custom build-to-order kits, the team must confront another constraint: their outsourced mainframe manufacturing resource planning system. Rather than accepting this limitation, they propose breaking the outsourcing contract early to bring the application back in-house-an audacious but necessary step to maintain competitive advantage. The novel ends with Steve offering Bill an unexpected opportunity: a two-year fast track with rotations through various business functions, potentially leading to the COO position. Steve's reasoning captures the book's central insight: "In ten years, every COO will come from IT backgrounds because they truly understand how the company works." This prediction-that technology leadership is becoming business leadership-has proven increasingly accurate in the years since the book's publication. Erik's final appearance brings the story full circle. The mysterious mentor reveals he plans to become a major investor in Parts Unlimited, believing their IT transformation predicts business success. His request that Bill write "The DevOps Handbook" to help improve the lives of IT workers everywhere breaks the fourth wall in a meta-reference to the actual companion book that Gene Kim later published. The Phoenix Project's enduring appeal lies in how it transforms abstract technical concepts into a human story of struggle and redemption. Through Bill Palmer's journey, readers see not just how to implement DevOps practices but why they matter-how they can reduce the stress, overtime, and frustration that plague IT departments while simultaneously improving business outcomes. As the novel concludes with Bill facing a new situation with "newfound calm and inner peace," it offers a hopeful vision: that by applying the right principles, organizations can transform IT from a source of frustration and constraint into an engine of innovation and competitive advantage. This message continues to resonate with readers worldwide, making The Phoenix Project not just a novel about IT transformation but a roadmap for business success in the digital age.

★★★★★

피닉스 프로젝트 완독을 축하합니다

100만 명 이상의 학습자가 사랑합니다

“23일째 매일 사용하고 있어요. 이제 제 일상의 한 부분이 되었습니다.”

jayallen

피닉스 프로젝트의 핵심 주제

devops movement
theory of constraints
it operations management
lean manufacturing principles
technical debt reduction

피닉스 프로젝트의 명언

Unplanned work is 'the most destructive type of work' in any IT organization.
It's like they've been hiding in our building, documenting our daily struggles.

피닉스 프로젝트의 등장인물

Bill PalmerIT operations manager promoted to VP
Steve MastersCEO of Parts Unlimited
BrentBrilliant engineer and critical bottleneck
Erik ReidBoard member candidate and manufacturing expert

저자 소개

진 킴(Gene Kim), 케빈 베어(Kevin Behr), 조지 스파포드(George Spafford)는 IT 및 데브옵스(DevOps) 분야의 획기적인 저서인 『프로젝트 피닉스: IT, 데브옵스, 그리고 비즈니스 성공을 위한 소설(The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win)』의 공동 저자입니다.

베스트셀러 작가이자 데브옵스 사상적 리더인 진 킴은 IT 모범 사례를 발전시키는 데 핵심적인 역할을 하는 조직인 트립와이어(Tripwire)와 IT 레볼루션(IT Revolution)을 설립했습니다. 비즈니스 소설과 기술적 통찰력을 결합한 이 소설은 IT 혁신, 지속적인 개선, 그리고 기술과 조직 목표의 일치라는 주제를 탐구하며, 이는 고성능 기술 팀에 대한 진 킴의 20년 연구에 뿌리를 둔 개념들입니다.

진 킴의 전문성은 『데브옵스 핸드북(The DevOps Handbook)』과 『액셀러레이트(Accelerate: The Science of Lean Software and DevOps)』에서도 잘 드러나며, 이 책들은 『프로젝트 피닉스』에서 소개된 원칙들을 더욱 확장합니다. 데브옵스 엔터프라이즈 서밋(DevOps Enterprise Summit)과 같은 행사에서 자주 기조 연설을 맡는 그의 작업은 《월스트리트 저널(The Wall Street Journal)》과 《포브스(Forbes)》 등에도 소개된 바 있습니다.

퍼듀 대학교(Purdue University) 학자인 스파포드는 진 킴의 오랜 협력자로서 학술적 엄밀함을 더합니다. 이 책은 100만 부 이상 판매되었으며, 10개 이상의 언어로 번역되어 기술 및 비즈니스 교육 분야에서 널리 활용되고 있습니다.

피닉스 프로젝트 요약 다운로드

피닉스 프로젝트 요약을 무료 PDF 또는 EPUB으로 받으세요. 인쇄하거나 오프라인에서 언제든 읽을 수 있습니다.

다른 사용자들도 좋아한 책

The Unicorn Project

Gene Kim

The Devops Handbook

Gene Kim & Jez Humble & Patrick Debois & John Willis & Nicole Forsgren

Wiring the Winning Organization

Gene Kim & Steven J. Spear

Phoenix King

Aparna Verma

Empowered

Marty Cagan & Chris Jones

Making Things Happen

Scott Berkun

Accelerate: The Science of Lean Software and DevOps

Nicole Forsgren

Program

Eric Kapitulik & Jake MacDonald

이 책에 대한 FAQ

더 알아보기

학습 계획

The High-Performance Manager's Playbook

This playbook is essential for new and mid-level managers struggling to balance execution with strategic leadership. It provides the tactical tools needed to shift from doing the work to driving results through others and protecting deep work.

2 h•4 섹션

학습 계획

Build a High-Performing Project Team

In today's fast-paced environment, the ability to rapidly align a group and lead them through conflict is a critical leadership skill. This plan is ideal for project managers and emerging leaders who need to transform individual contributors into a cohesive, high-impact unit from kickoff to completion.

1 h•3 섹션

학습 계획

The High-Growth Leadership Playbook

In fast-scaling environments, traditional management often leads to burnout and missed deadlines. This playbook is designed for high-growth leaders who need to shift from tactical oversight to strategic empowerment to sustain team performance. It provides the psychological and behavioral tools necessary to build a self-sustaining, high-energy culture.

2 h•4 섹션

학습 계획

Bridge the Business-Tech Gap

In modern software development, technical excellence is only valuable if it drives business success. This plan is designed for engineers and product leaders who want to stop being 'order takers' and start becoming strategic partners by aligning their architecture with organizational goals.

1 h 12 m•3 섹션

학습 계획

Strategic PMO Leadership for Startups

In today's rapidly changing business landscape, PMOs leading innovative projects face unique challenges that traditional project management approaches often fail to address. This learning plan equips project managers with the startup mindset, risk management strategies, and communication skills needed to successfully navigate uncertainty while demonstrating business acumen to senior stakeholders.

3 h 24 m•4 섹션

학습 계획

Master One Project to Prevent Burnout

In an era of constant connectivity, professionals often mistake busyness for productivity, leading to chronic exhaustion. This plan is designed for high-achievers and creative professionals who need to reclaim their focus and prevent burnout by mastering the power of single-project excellence.

4 h 22 m•4 섹션

학습 계획

Rapid Deployment and Digital Persuasion

This plan is designed for entrepreneurs and developers who need to launch products fast while ensuring they actually convert users. It combines the technical speed of prompt-based engineering with the psychological rigor of influence design to create a competitive edge in the digital economy.

2 h•4 섹션

학습 계획

The 30-Minute Discovery Playbook

In fast-paced retail environments, technical teams often struggle to articulate the business value of observability. This playbook is essential for sales engineers and technical leaders who need to master concise discovery and align technical pain points with executive priorities.

1 h 30 m•3 섹션

샌프란시스코에서 컬럼비아 대학교 동문들이 만들었습니다

LOVED BY

1,000,000+ curious minds.

4.7

avg rating

1M+ learners

"Instead of endless scrolling, I just hit play on BeFreed. It saves me so much time."

@Moemenn

"I never knew where to start with nonfiction—BeFreed’s book lists turned into podcasts gave me a clear path."

@Chloe, Solo founder, LA

117

"Perfect balance between learning and entertainment. Finished ‘Thinking, Fast and Slow’ on my commute this week."

@Raaaaaachelw

"Crazy how much I learned while walking the dog. BeFreed = small habits → big gains."

@Matt, YC alum

108

"Reading used to feel like a chore. Now it’s just part of my lifestyle."

@Erin, Investment Banking Associate , NYC

254

"Feels effortless compared to reading. I’ve finished 6 books this month already."

@djmikemoore

"BeFreed turned my guilty doomscrolling into something that feels productive and inspiring."

@Pitiful

4.5K

"BeFreed turned my commute into learning time. 20-min podcasts are perfect for finishing books I never had time for."

@SofiaP

"BeFreed replaced my podcast queue. Imagine Spotify for books — that’s it. 🙌"

@Jaded_Falcon

201

"It is great for me to learn something from the book without reading it."

@OojasSalunke

"The themed book list podcasts help me connect ideas across authors—like a guided audio journey."

@Leo, Law Student, UPenn

483

"Makes me feel smarter every time before going to work"

@Cashflowbubu

웹에서 BeFreed가 어떻게 논의되고 있는지 더 보기

샌프란시스코에서 컬럼비아 대학교 동문들이 만들었습니다

LOVED BY

1,000,000+ curious minds.

4.7

avg rating

1M+ learners

"Instead of endless scrolling, I just hit play on BeFreed. It saves me so much time."

@Moemenn

"I never knew where to start with nonfiction—BeFreed’s book lists turned into podcasts gave me a clear path."

@Chloe, Solo founder, LA

117

"Perfect balance between learning and entertainment. Finished ‘Thinking, Fast and Slow’ on my commute this week."

@Raaaaaachelw

"Crazy how much I learned while walking the dog. BeFreed = small habits → big gains."

@Matt, YC alum

108

"Reading used to feel like a chore. Now it’s just part of my lifestyle."

@Erin, Investment Banking Associate , NYC

254

"Feels effortless compared to reading. I’ve finished 6 books this month already."

@djmikemoore

"BeFreed turned my guilty doomscrolling into something that feels productive and inspiring."

@Pitiful

4.5K

"BeFreed turned my commute into learning time. 20-min podcasts are perfect for finishing books I never had time for."

@SofiaP

"BeFreed replaced my podcast queue. Imagine Spotify for books — that’s it. 🙌"

@Jaded_Falcon

201

"It is great for me to learn something from the book without reading it."

@OojasSalunke

"The themed book list podcasts help me connect ideas across authors—like a guided audio journey."

@Leo, Law Student, UPenn

483

"Makes me feel smarter every time before going to work"

@Cashflowbubu

"Instead of endless scrolling, I just hit play on BeFreed. It saves me so much time."

@Moemenn

"I never knew where to start with nonfiction—BeFreed’s book lists turned into podcasts gave me a clear path."

@Chloe, Solo founder, LA

117

"Perfect balance between learning and entertainment. Finished ‘Thinking, Fast and Slow’ on my commute this week."

@Raaaaaachelw

"Crazy how much I learned while walking the dog. BeFreed = small habits → big gains."

@Matt, YC alum

108

"Reading used to feel like a chore. Now it’s just part of my lifestyle."

@Erin, Investment Banking Associate , NYC

254

"Feels effortless compared to reading. I’ve finished 6 books this month already."

@djmikemoore

"BeFreed turned my guilty doomscrolling into something that feels productive and inspiring."

@Pitiful

4.5K

"BeFreed turned my commute into learning time. 20-min podcasts are perfect for finishing books I never had time for."

@SofiaP

"BeFreed replaced my podcast queue. Imagine Spotify for books — that’s it. 🙌"

@Jaded_Falcon

201

"It is great for me to learn something from the book without reading it."

@OojasSalunke

"The themed book list podcasts help me connect ideas across authors—like a guided audio journey."

@Leo, Law Student, UPenn

483

"Makes me feel smarter every time before going to work"

@Cashflowbubu

"Instead of endless scrolling, I just hit play on BeFreed. It saves me so much time."

@Moemenn

"I never knew where to start with nonfiction—BeFreed’s book lists turned into podcasts gave me a clear path."

@Chloe, Solo founder, LA

117

"Perfect balance between learning and entertainment. Finished ‘Thinking, Fast and Slow’ on my commute this week."

@Raaaaaachelw

"Crazy how much I learned while walking the dog. BeFreed = small habits → big gains."

@Matt, YC alum

108

"Reading used to feel like a chore. Now it’s just part of my lifestyle."

@Erin, Investment Banking Associate , NYC

254

"Feels effortless compared to reading. I’ve finished 6 books this month already."

@djmikemoore

"BeFreed turned my guilty doomscrolling into something that feels productive and inspiring."

@Pitiful

4.5K

"BeFreed turned my commute into learning time. 20-min podcasts are perfect for finishing books I never had time for."

@SofiaP

"BeFreed replaced my podcast queue. Imagine Spotify for books — that’s it. 🙌"

@Jaded_Falcon

201

"It is great for me to learn something from the book without reading it."

@OojasSalunke

"The themed book list podcasts help me connect ideas across authors—like a guided audio journey."

@Leo, Law Student, UPenn

483

"Makes me feel smarter every time before going to work"

@Cashflowbubu

웹에서 BeFreed가 어떻게 논의되고 있는지 더 보기

지금 바로 학습 여정을 시작하세요

3장

피닉스 프로젝트

개요피닉스 프로젝트 개요

한 권의 책, 다양한 듣기 방식.

When IT Becomes a Battleground: The Phoenix Project's Wake-Up Call

The Perfect Storm: When Everything Falls Apart

들리는 모든 단어를 눈으로 확인하세요

The Four Types of Work: Revealing the Hidden Factory

The Phoenix Disaster: When Deployment Becomes a Death March

피닉스 프로젝트에서 더 많은 것을 얻으세요

The Three Ways: A New Philosophy for IT

Breaking Down Silos: The Birth of DevOps at Parts Unlimited

들리는 모든 단어를 눈으로 확인하세요

From Months to Minutes: The Deployment Revolution

Beyond Technology: The Human Side of Transformation

피닉스 프로젝트에서 더 많은 것을 얻으세요

The Phoenix Rises: Transformation and Triumph

피닉스 프로젝트 완독을 축하합니다

피닉스 프로젝트의 핵심 주제

피닉스 프로젝트의 명언

피닉스 프로젝트의 등장인물

저자 소개

피닉스 프로젝트 요약 다운로드

다른 사용자들도 좋아한 책

이 책에 대한 FAQ

What is The Phoenix Project by Gene Kim about?

Who should read The Phoenix Project?

Is The Phoenix Project worth reading?

What are the key concepts in The Phoenix Project?

더 알아보기

1,000,000+ curious minds.

1,000,000+ curious minds.

한 권의 책, 다양한 듣기 방식.

When IT Becomes a Battleground: The Phoenix Project's Wake-Up Call

The Perfect Storm: When Everything Falls Apart

들리는 모든 단어를 눈으로 확인하세요

The Four Types of Work: Revealing the Hidden Factory

The Phoenix Disaster: When Deployment Becomes a Death March

피닉스 프로젝트에서 더 많은 것을 얻으세요

The Three Ways: A New Philosophy for IT

Breaking Down Silos: The Birth of DevOps at Parts Unlimited

들리는 모든 단어를 눈으로 확인하세요

From Months to Minutes: The Deployment Revolution

Beyond Technology: The Human Side of Transformation

피닉스 프로젝트에서 더 많은 것을 얻으세요

The Phoenix Rises: Transformation and Triumph

피닉스 프로젝트 완독을 축하합니다

다른 사용자들도 좋아한 책

더 알아보기

피닉스 프로젝트 개요