LibraryFoundationsThe Five Ideals

F-03FOUNDATION

The Five Ideals

Gene Kim's framework from The Unicorn Project. The conditions that separate organizations where developers love their work from those where they are perpetually firefighting.

Sources:The Unicorn Project — Gene KimThe DevOps Handbook

Video Lesson

A video lesson for this topic is in development. The library articles and mission exercises cover the same material in the meantime.

01

Origin: The Unicorn Project

In 2019, Gene Kim published The Unicorn Project — a companion novel to The Phoenix Project that tells the same story from the developer's perspective. Where the Phoenix Project focuses on IT operations and flow, the Unicorn Project focuses on developer experience and what makes great engineering organizations.

Through the protagonist Maxine, Kim articulates five ideals — principles that characterize organizations where developers can do their best work. These are not practices or tools. They are the conditions that make practices and tools possible.

The Three Ways describe how work should flow. The Five Ideals describe the organizational conditions that make that flow possible. You need both.

02

Overview

I

Locality and Simplicity

II

Focus, Flow, and Joy

III

Improvement of Daily Work

IV

Psychological Safety

V

Customer Focus

03

The five ideals in depth

I

Locality and Simplicity

Small teams, simple systems, local decisions

Changes should require as few people, teams, and systems as possible. When a feature requires coordination across five teams and thirty approval gates, the system has too much coupling. Locality means a team can make a change end-to-end. Simplicity means the architecture supports it.

In practice

A single team owns an entire microservice
Deploying a feature does not require a change request to three other teams
The codebase is simple enough that a new engineer can be productive in days
II

Focus, Flow, and Joy

Deep work, fast feedback, engaged engineers

Engineers do their best work when they have uninterrupted focus, fast feedback on their changes, and a sense that their work matters. Context switching, interrupt-driven work, and slow pipelines destroy all three. This ideal is about creating the conditions for developer excellence.

In practice

Developers can make a change and see it in production the same day
Meetings are batched to protect deep work time
Automated tests and deployment give fast feedback without human gatekeeping
III

Improvement of Daily Work

The system improves, not just the product

Paying down technical debt and improving processes is at least as important as building features. When organizations only ship features, technical debt compounds until it makes the system unmaintainable. The Third Ideal is about making deliberate time for improvement — Kaizen applied to the development process itself.

In practice

Teams reserve capacity each sprint for tech debt reduction
Post-mortems produce systemic fixes, not just timeline corrections
Infrastructure improvements are treated as first-class work
IV

Psychological Safety

Speak up, fail safely, learn openly

Teams only improve when members feel safe to raise problems, share bad news, and admit mistakes without fear of punishment. In psychologically unsafe environments, problems are hidden until they become crises. Psychological safety is not about being nice — it is a prerequisite for organizational learning.

In practice

Blameless post-mortems focus on system improvement, not blame
Engineers can raise concerns about schedule pressure without consequence
Failure is treated as a learning opportunity rather than a firing offense
V

Customer Focus

Every decision is evaluated against customer value

The ultimate purpose of software delivery is delivering value to users and the business. Teams that lose sight of this optimize for the wrong things: internal metrics, process compliance, or team convenience. Customer focus keeps the system oriented toward outcomes, not outputs.

In practice

Feature teams talk directly to customers
Metrics include customer satisfaction, not just delivery speed
A fast pipeline that ships the wrong features is still a failure
04

The Five Ideals vs. the Three Ways

The Three Ways and the Five Ideals are complementary, not competing. The Three Ways are a framework for understanding how work flows through a system. The Five Ideals are a framework for understanding the organizational and cultural conditions that enable or inhibit that flow.

Three Ways

·Describes how work should move
·Technical and process principles
·Flow, feedback, learning
·The 'what' of DevOps

Five Ideals

·Describes the conditions for good work
·Organizational and cultural principles
·Safety, focus, simplicity, customer
·The 'why' and 'who' of DevOps

A team can implement every practice in this library and still fail if the organizational conditions are wrong. Psychological safety, locality, and customer focus are prerequisites, not afterthoughts.

05

Diagnosing your organization

The Five Ideals are diagnostic tools. When delivery is slow or painful, the ideals often reveal why. Common failure modes:

Changes require weeks of coordination

Locality & Simplicity

The architecture has too much coupling. Teams cannot make end-to-end changes independently.

Engineers hate deployments

Focus, Flow, Joy

Deployments are painful because they are infrequent and large. Automate and increase frequency.

The same problems recur repeatedly

Improvement of Daily Work

There is no capacity for systemic fixes. Improvement work is always de-prioritized for features.

Problems are hidden until they are crises

Psychological Safety

People are afraid to raise bad news. Create explicit channels for surfacing problems without blame.

Teams optimize for velocity, not value

Customer Focus

Teams are measured by outputs (features shipped) rather than outcomes (problems solved for users).

06

Further reading

The Unicorn Project — Gene Kim

The source. Follow Maxine through a struggling enterprise IT organization. The Five Ideals emerge from the narrative.

The Phoenix Project

The companion novel. Bill's perspective on the same organization — more operational, less developer-focused.

An Elegant Puzzle — Will Larson

Systems of Engineering Management. The organizational conditions (locality, autonomy, safety) explored from an engineering leadership perspective.

Psychological Safety — Amy Edmondson

The Fearless Organization. The research behind the Fourth Ideal. Why psychological safety predicts team performance.