> For the complete documentation index, see [llms.txt](https://hanfak.gitbook.io/workspace/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://hanfak.gitbook.io/workspace/devops1/5-ideals.md).

# The 5 Ideals

## Ideal 1: Locality and Simplicity

* The organizational environment must support DevOps. We can measure it with the “Lunch Factor”: how many people do we have to talk to over lunch to get things done? Reduce the lunch factor to a minimum.
  * Have fewer teams that can deploy more often independently.
  * Have an architecture that allows a fast turnaround time.
  * Developers must be empowered to work independently including that most integration tests must be run without an integrated staging environment (note: done right, contract testing might be a means to achieve that).
  * Developers should not have to understand a big codebase.
  * Developers must have the authority to deploy code to production.
  * Developers must not have to wait for other business units to get things done for them (like enterprise architecture review, database schemas, …).

## Ideal 2: Focus, Flow, and Joy

* Developers should solve the business problem and not spend most of their time on configuration and infrastructure tasks.
  * Put the infrastructure into a platform.
  * Reduce the lead time between code check-in and feedback to a minimum to connect the cause to the effect; ideally, know within seconds if a feature works or not.
  * Do trunk-based development to reduce the PR review and merge overhead.

## Ideal 3: Improvement of Daily Work

* We can only improve if we get feedback, so we should put as much feedback into our daily work as possible to get a little better each day.
  * Toyota had a cord along the assembly line that is expected to be pulled by any worker that sees a problem (the Andon Cord. If it’s pulled, they have 55 seconds to fix the problem, otherwise, the assembly line stops. The cord is pulled something like 3500 times a day (talk about feedback).
  * Big companies like Microsoft, Google, and Amazon only survived their technical debts because at some point they froze feature development.
  * The build time of Nokia’s own operating system Symbian was 48 hours before they “pulled the cord” and went with another OS (didn’t help them in the long run, though…).
  * Always take 20% off the development cycle to fix (or avoid) tech debt.
  * Enable greatness by having some engineers solely concentrate on dev productivity.
  * Have a virtual Andon Cord to fix things right when they happen.

## Ideal 4: Psychological Safety

* Only a psychologically safe environment allows for new ideas, innovation, and to learn from errors. An environment where you get bullied for each production error does not support a fast DevOps cycle, because everyone wants to be 100% certain that it works, which results in big deployments with slow processes and more things that can go wrong per deployment.

## Ideal 5: Customer Focus

* focus on the things that bring value to the customers instead of building functional silos and long internal decision chains within the organization.