This article is an excerpt from the Shortform book guide to "The Unicorn Project" by Gene Kim. Shortform has the world's best summaries and analyses of books you should be reading.
Like this article? Sign up for a free trial here.
Why are so many employees unproductive at work? How does poor management cause an inefficient work environment?
The Unicorn Project by Gene Kim follows the narrative of Maxine Chambers, a lead developer in Parts Unlimited’s software development department within IT. Through Maxine’s eyes, Kim illustrates the characteristics of both unproductive and healthy workplace cultures, with an emphasis on how the former can be turned into the latter.
Let’s look at the story of Chambers to inspire you to be more productive at work.
From Being Unproductive to Efficient and Healthy
In the story, Maxine goes from the frustration of being part of an ineffective department that’s unproductive at work to joining a group of company rebels who secretly work to institute better practices, eventually setting an example for the rest of the company to follow.
Our story begins as Maxine finds out she’s been unjustly blamed for a payroll system failure. As punishment, she’s exiled to work on an online sales tool called the Phoenix Project that everyone in IT despises. Though management considers the Phoenix Project essential to dragging Parts Unlimited into the digital age, it’s been stuck in development hell for years. When Maxine arrives at her new workplace, the situation is even worse than she’d imagined.
(Shortform note: In The Unicorn Project, Kim doesn’t explain the Phoenix Project’s actual purpose. In the novel The Phoenix Project, it’s described as an enormous software system that will unite online and in-store sales, collect customer data, speed up product delivery, and enable targeted promotions. Since its inception, Phoenix has grown thanks to demands from the retail, marketing, and security departments. By the time The Unicorn Project begins, the Phoenix Project’s software has become so complex that no one understands it enough to make it work.)
The Phoenix Project office is a dismal cube farm where developers work in isolation from each other. The culture is one in which there’s no feedback, no visible progress, and no risks taken to foster innovation because people fear they’ll be punished if something goes wrong. While programmers develop separate Phoenix features, there’s no standard environment for developers to work in, no way to test the code they write, and no Phoenix documentation to help newcomers begin. Maxine’s initial task is to write that documentation, but she finds it impossible to even install a pre-release version of Phoenix on her laptop.
(Shortform note: In layman’s terms, a software development environment is made up of the computer hardware, operating systems, and other applications within which software is designed before implementation. Such environments are used to create software, test it, and model how it will be implemented into end-users’ devices. The version Maxine tries to install on her laptop is referred to as a “build”—an executable version of the current work in progress that should run as it would if used by consumers. A build can either be created all at once, as when you install a new program on your computer, or incrementally added to a previous build, as when you update software to a newer version.)
At a company meeting, the CEO announces that there will be no further delays in rolling the Phoenix Project out for the public—despite the fact that there hasn’t been a single successful test of the system. Everyone in IT knows that in its current state, Phoenix can’t possibly work, but rather than working toward a viable solution, IT’s development and operations divisions are at each other’s throats. Meanwhile, Maxine meets a sympathetic colleague named Kurt from quality assurance. He invites her to an after-hours meeting of coworkers who routinely bend and break company rules to actually get things done.
(Shortform note: As depicted by Kim, Parts Unlimited’s IT department is split into four competing groups: development (Dev), operations (Ops), quality assurance (QA), and security. The Dev group is responsible for generating new software, databases, and online interfaces, whereas Ops is responsible for maintaining the company’s existing hardware and software while installing and implementing new products from Dev. QA is responsible for testing Dev’s software to make sure it works as intended on any system it’s meant to run on, whereas IT security protects company and user data from unauthorized access as well as making sure that a company’s data management systems stay in compliance with government regulations.)
An Underground Movement
Through the secret group that Maxine joins, Kim gives the first glimpse of what a productive IT department looks like. Kurt’s rebels include people from Dev, Ops, and QA who willingly work together. In reaching out to help colleagues like Maxine, their collective mission is to undermine Parts Unlmited’s culture of division in which its departments compete for resources, protect their own interests, and lose sight of the needs of the business as a whole. Kim argues that the growth of a toxic company culture is self-inflicted—a company’s production workflow bogs down because management and workers allow it to happen.
(Shortform note: In The Phoenix Project, Kim, Behr, and Spafford go into more detail about two types of hurdles that slow work down. The first is unplanned work such as emergency repairs to systems that halt production when they fail. Unplanned work generates more unplanned work because it takes time away from maintenance and improvements that would prevent similar emergencies in the future. The second type of stoppage is a bottleneck—the one link in the chain that limits the speed of the entire production process. A bottleneck could be a specific workstation, a cumbersome procedure, an approval committee, or even one person.)
At the moment, the rebel group is small, and there’s nothing they can do to save the Phoenix Project. Its deployment goes even worse than expected. Databases are corrupted, orders get lost, and even the company’s internal networks crash. The company executives who lobbied for the rollout try to fix the blame on IT while the departmental managers focus on self-protection instead of problem-solving. Meanwhile, IT can’t get anything done because every system change and bug fix has to go through a Kafkaesque approval process.
(Shortform note: As Kim shows with the Phoenix Project crash, blame and bureaucracy can halt meaningful progress at the worst possible time. In Factfulness, Hans Rosling argues that blame arises from a desire to avoid pain and simplify bad situations by not digging into their systemic causes. Bureaucracy, on the other hand, acts as a barrier to communication. In Hit Refresh, Microsoft CEO Satya Nadella recounts how he had to bypass his company’s bureaucratic structure to hear from front-line workers and break through departmental walls that were preventing effective collaboration.)
The Rebels Strike Back
The disruption caused by the Phoenix Project meltdown creates an opening for the rebels to expand their operations. By formalizing their behind-the-scenes network, Kurt and Maxine merge the functions of different departments to create a cycle of feedback and progress. They do this by self-organizing into a new team, tackling a system bottleneck that’s slowing Phoenix down, and eventually detaching that bottleneck from the Phoenix software altogether.
While IT scrambles to keep Phoenix working, Kurt lobbies for Maxine and the rebels to become a new product development team that incorporates testing into the development process instead of waiting to do it after the fact. This bypasses the complicated ticketing system that ostensibly lets IT track progress but, in practice, prevents work by segregating the steps of software creation between multiple departments. It’s a risky move to short-circuit Parts Unlimited’s bureaucracy that, if it fails, could get them all fired.
(Shortform note: While Kim presents the rebels’ actions as a daring step in the right direction, there are dangers inherent to circumventing a system’s hierarchical structure. In Thinking in Systems, Donella H. Meadows warns that if a subgroup such as Kurt’s rebellion optimizes work for its own needs and neglects the larger organization—such as by taking resources away from other teams—the organization as a whole could fail. In a healthy system, Meadows suggests that the hierarchy should be structured to improve the work of smaller teams and help them coordinate instead of pitting them against each other as in the case of Parts Unlimited.)
Maxine’s first mission is to salvage Data Hub, a patched-together legacy system that Phoenix relies on to pull customer and product information from separate databases spread throughout the network. Data Hub is slow and antiquated, but so many of the company’s systems run through it that replacing it would be a logistical nightmare. Though its deficiencies are a major bottleneck preventing Phoenix from working, Kim writes that upgrading and maintaining Data Hub has never received support from on high because management gives apps and features higher value than the underlying systems that support them.
Kurt’s rebels make it a priority to create a working environment that developers can use to test their changes to Data Hub. This new, slimmed-down test environment spreads through the rest of Dev and QA, whose members start working in conjunction with each other. They even rearrange their cubicles so developers and testers can work side by side, providing rapid feedback and speeding up their progress. Kim illustrates that it’s not just efficiency that improves—team members start taking joy in their work.
The Unicorn Revolution
Now that the rebels have an official assignment, it’s time to put their ideas to the test. By using quick feedback, error correction, and rapid deployment, the Unicorn team is able to achieve a solid, measurable business outcome—increased customer engagement and sales. They do this by keeping their project small and focused, incorporating testing as part of development and deployment, and turning every failure into a lesson for improvement.
Kim is clear that Unicorn isn’t meant to be a giant, monolithic project like Phoenix—the name simply refers to the seasonal promotions project. The point is to address a specific business goal where Phoenix failed and to do so as efficiently as possible. Once the Unicorn team shows off their new software, they’re energized by seeing how their work will have a direct impact on the business and their customers. A successful demonstration earns the project a green light to deploy before Black Friday, but that doesn’t mean Unicorn’s work is done.
(Shortform note: Why does the Unicorn team feel so motivated when their previous work on the Phoenix project had felt like endless drudgery? The answer may be the autonomy they’re given to design and set the Unicorn project into motion. In Drive, Daniel H. Pink argues that autonomy motivates team members by empowering them to choose the direction of their work. This creates a direct link between a person’s output and their internal values. Autonomy gives employees free rein to be creative and come up with solutions that top-down management often overlooks. Rather than hampering efficiency, autonomy lets employees come up with better ways to achieve business goals than a manager would think of.)
The Unicorn team sends a trial run of promotional emails to 1% of Parts Unlimited’s customers. This already differs from Kim’s depiction of the Phoenix rollout, which was attempted with no pretesting whatsoever. When customers start to place promotional orders, glitches occur, but each problem is fixed by a group of programmers whose changes are uploaded to the system immediately. Despite the hiccups, the test is successful, though Maxine warns that the volume of promotions—and their associated glitches—will be much higher when the full rollout happens.
(Shortform note: Maxine’s advice has roots far back in the early days of computer programming. In 1975’s The Mythical Man-Month, Frederick P. Brooks points out that not only does every piece of software have errors, but fixing those problems creates even more errors that will show up further down the road. Brooks says that you should expect errors to crop up—as Maxine does in the story—and recognize that endless debugging leads to diminishing returns. Eventually, you have to deploy your software, whether or not it’s 100% perfect.)
———End of Preview———
Like what you just read? Read the rest of the world's best book summary and analysis of Gene Kim's "The Unicorn Project" at Shortform.
Here's what you'll find in our full The Unicorn Project summary:
- Why the work of IT services must align with a company's goals
- How an IT department can turn itself around after failure
- The three pillars of IT management: workflow, feedback, and constant improvement
