Skip to content

Knowledge base

Engineering Manifesto

An engineering manifesto states the values a team weighs every decision against: tech follows business, move fast and fail fast, low technical barriers, coverage of non-functional aspects, and full ownership. Teams apply them with common sense and discuss any deviation openly with the teams it affects.

Written by

Updated:

Software Engineering 5

Our position. We hold that agents did not change the operating model of software engineering; they exposed whether a team had one (AI-native teams (opens in a new tab)).

The five values come from OTTO’s public Tech Manifest (opens in a new tab) (Apache-2.0), written for systems under real business pressure. Values describe what a team considers important and where it puts emphasis, and they guide daily work and decisions.

The eleven Architecture Principles turn these values into concrete decisions.

Why should tech follow business?

The entire purpose of engineering effort is to create business value. All technical decisions must support the business. The sooner, the better.

Business requirements shift. Roadmaps change. We support that instead of resisting it. The whole team has the responsibility to develop business ideas, not only product-focused team members. Teams build products for partners and customers, not just software artifacts.

Business value can only be gained by delivering software to production. Documents and concepts have no inherent value on their own.

We value the benefit for the company higher than the benefit for our team or ourselves.

Why move fast and fail fast?

We value quick iteration in short build, measure, learn cycles. Failing fast is a strongly recommended practice, often realized with fully automated pipelines, to surface mistakes as early as possible in the development process.

Teams must contain the necessary people and authority to build features and products with as few dependencies as possible to other teams. We consider the constraint that system boundaries mirror communication structures and split domains in a way that allows for loose coupling and increased team autonomy.

Uncertain business requirements become clearer and tangible when teams start to build and deploy potentially shippable software products. A running system with minimal functions is more valuable than discussing concepts.

We appreciate refactoring and follow pareto principles to fulfill business requirements. Iterative design and feedback loops with partners and customers tend toward customer-focused solutions.

Software is designed to fail. Outages are not fully preventable. We focus on mean time to recovery instead of optimizing mean time between failures.

How do teams keep technical barriers low?

Although we strive for independent teams, teams are not alone. We help each other and reduce technical barriers. We increase knowledge exchange and value standardization of technologies and processes across teams, where beneficial. We prefer open standards above proprietary ones.

How much care do non-functional aspects need?

We put a special focus on non-functional aspects of our software. We consider the criticality and maturity of a product when deciding the level of effort required for resilience.

We react with urgency if problems are detected. We apply security best practices to all applications. We measure performance even in high load scenarios and ensure appropriate response times.

Infrastructure setup is highly automated to ensure we can rebuild the whole environment in case of disaster recovery. Quality is a non-negotiable dimension and achieved by following the test pyramid.

What does full ownership demand of a team?

Teams are responsible for supporting, monitoring, alerting, operating, and retiring everything they build and maintain, including quality aspects. You build it, you run it.

Responsibilities and ownership must always be clear and public. Everything used in production or shared across multiple teams must be owned.

We strive for aligned autonomous cross-functional teams: a team should fulfill its assignment as autonomously as possible, but should also align on concepts and technical solutions with other teams where synergies could be beneficial.

Teams are also responsible for their costs and strive for optimization.

Resources

Posts

Tools and repositories

  • Tech Manifest (opens in a new tab) - otto-de’s engineering values manifesto, the source of this page’s five values, written for systems under business pressure; Apache-2.0, archived repository.