The Unicorn Project: A Novel about Developers, Digital Disruption, and Thriving in the Age of Data

by Gene Kim

Everyone around here thinks features are important, because they can see them in their app, on the web page, or in the API. But no one seems to realize how important the build process is. Developers cannot be productive without a great build, integration, and test process.

She reflects upon the difference between a great day and a bad day. A great day is when she’s solving an important business problem. Time flies by because she’s so focused and loving the work. She’s in a state of flow, to the point where it doesn’t feel like work at all.

So why does the ticketing system here feel so awful? We’re all part of Parts Unlimited, so why does everything feel like I’m dealing with a government bureaucracy or an uncaring vendor?

Each decision is a commitment to support it for years or even decades—these are decisions that go far beyond just one team.

“The importance of lead times in software delivery is tantamount, as Senseis Dr. Nicole Forsgren and Jez Humble have discovered in their research,” Erik says. “Code deployment lead time, code deployment frequency, and time to resolve problems are predictive of software delivery, operational performance, and organizational performance, and they correlate with burnout, employee engagement, and so much more.

“Build responsibility moved from Dev to QA to interns. Tech giants like Facebook, Amazon, Netflix, Google, and Microsoft give Dev productivity responsibilities to only the most senior and experienced engineers. But here at Parts Unlimited, it’s the exact opposite.”

‘technical debt is what you feel the next time you want to make a change.’

There are many things that people call technical debt, but it usually refers to things we need to clean up, or where we need to create or restore simplicity, so that that we can quickly, confidently, and safely make changes to the system.

“Sometimes it’s a build and test system that doesn’t give fast feedback to developers, or when...

“Sometimes it’s when simple components become complected, and you can no longer reason about it or change it without immense effort or risk of catastrophe. Sometimes it’s when decision-making processes or the organizational structure loses locality, f...

the First Ideal of Locality and Simplicity. We need to design things so that we have locality in our systems and the organizations that build them. And we need simplicity in everything we do. The last place we want complexity is internally, whether it’s in our code, in our organization, or in our processes. The external world is complex enough, so it would be intolerable if we allow it in things we can actually control! We must make it easy to do our work.”

“The Second Ideal is Focus, Flow, and Joy. It’s all about how our daily work feels. Is our work marked by boredom and waiting for other people to get things done on our behalf? Do we blindly work on small pieces of the whole, only seeing the outcomes of our work during a deployment when everything blows up, leading to firefighting, punishment, and burnout? Or do we work in small batches, ideally single-piece flow, getting fast and continual feedback on our work? These are the conditions that allow for focus and flow, challenge, learning, discovery, mastering our domain, and even joy.”

The Third Ideal is Improvement of Daily Work. Reflect upon what the Toyota Andon cord teaches us about how we must elevate improvement of daily work over daily work itself.

The Fourth Ideal is Psychological Safety, where we make it safe to talk about problems, because solving problems requires prevention, which requires honesty, and honesty requires the absence of fear. In manufacturing, psychological safety is just as important as physical safety.

And finally, the Fifth Ideal is Customer Focus, where we ruthlessly question whether something actually matters to our customers, as in, are they willing to pay us for it ...

The First Ideal—Locality and Simplicity The Second Ideal—Focus, Flow, and Joy The Third Ideal—Improvement of Daily Work The Fourth Ideal—Psychological Safety The Fifth Ideal—Customer Focus

Maxine is impressed that Tom can even reproduce the problem at all. Someone once called these problems “heisenbugs,” referring to the quantum physics phenomena where the act of observation changes the nature of reality itself.

As Erik stares at the wall for several moments, Maxine suddenly realizes why Steve talks about workplace injuries at every Town Hall. He knows he can’t directly influence everyone’s daily work. However, Steve can reinforce and model his desired values and norms, which he does so effectively, Maxine realizes.

Oh, great, Maxine thinks. On top of everything else, we’re also suffering from Stockholm syndrome.

Over the decades, Maxine has tried to explain to non-technical people how frightening code merges are. Her best description is having fifty screenwriters simultaneously working on a Hollywood script when they haven’t decided who the main characters are, or what the ending will be, or whether it’s a gritty, detective story or a bumbling sleuth with a sidekick. They break up the writing responsibilities between all the writers, and each writer works on their part of the script in isolation, typing away in Word for weeks at a time. Then, right before the script needs to be finalized, all fifty writers get together in a room to merge all their work back together into a single story.

Maxine loves it when everyone merges their changes frequently to the ‘master branch,’ such as once per day. That way, the size of the changes being merged are never allowed to get too large. Small batch sizes, like in manufacturing, create a smooth flow of work, with no jarring disruptions or catastrophes.

Who profits from all of this? Who benefits by oppressing everyone in the technology organization? Maxine doubts that Chris or Bill are the wardens of this endless sea of prisons. If anything, they’re prisoners too.

you’re looking at a renegade group of engineers who want to solve big problems that actually matter to the business. Our attempts to go through the normal channels haven’t worked, so here’s our chance to work directly with the business instead of through technology middle managers. If we succeed, we get credibility. We’d love your endorsement supporting these new ways of working.”

Agile Prime Directive. No one is at fault. Everyone did the best they could, given what they knew.

“Just what does it take to build great products? And how can we as developers help?”

“It usually begins with understanding who our customers are, both current and desired. Then we typically segment the customer base, so we know what set of problems each faces. Once we know that, we can understand which of those problems we want to solve, based on market size, ease of reaching them, and so forth. Once we know that, we think about pricing and packaging, offer development, and more strategic issues, such as the overall profitability of the product portfolio and how it affects the achievement of strategic goals.

“In order to speak clearly, you need to be able to think clearly. And to think clearly, you usually need to be able to write it clearly.”

In hindsight, giving the team a unique name is probably long overdue. She’s always loved the Tuckman phases of teams, going through form, storm, norm, and perform. She’s ready to start norming and performing!

“For those of you not in technology, ‘technical debt’ is what creates hardship, toil, and reduces the agility of our software engineers,”

“It’s like a spreadsheet that’s grown over years to the point that you can’t change it anymore without breaking formulas or introducing errors.

“Are we playing to win and to establish the technical supremacy we need to keep up with what the business needs, or do we just keep limping along, shackled to things built decades ago, and tell our business leadership to throw in the towel and stop having good ideas?”

Left to their own devices, development teams will often optimize everything around themselves. This is just the parochial and selfish nature of individual teams. And that’s why you need architects, thinks Maxine.

the only way they could have achieved what they had was by creating a culture where people felt safe to experiment, to learn and make mistakes, and where people make time for discovery, innovation, and learning.

“It’s been true for hundreds of years and probably thousands more: employee engagement and customer satisfaction are the only things that matter. If we do that right, and manage cash effectively, every other financial target will take care of itself.”

“During my manufacturing days in the 1990s, I had to oversee a massive reskilling of the workforce,” he says. “We made huge investments to make sure every worker could survive and thrive in a new era where everyone was being paid not to just use their hands but also their heads. It was one of the most fulfilling and rewarding things I’ve ever done. We must do the same with the technology workforce.

“Our future depends on innovation,” he says. “That doesn’t come from process. It comes from people.”

Just like the tech giants, they’ve decided to open source various technologies that don’t create competitive advantage, and now many are becoming industry standards.

Technology needs to be embedded in the business, not external to it or merely “aligned with it.”

there is finally a career ladder for individual contributors and brilliant technologists without having to become managers.

this is surely the nature of this new economy. The power to disrupt the customer experience is no longer just the domain of the FAANGs: the Facebooks, Apples, Amazons, Netflixes, and Googles,”

“Instead, it is within reach of almost any organization that wants to disrupt the market. And who better to disrupt things for the benefit of customers than the organizations that already have a decades-long relationship with them?

“We are at the dawn of the Age of Software and Data.

fast and big will win almost every time. The Unicorn Project has shown us that.”