3. World-Class Engineering

Software engineering …

• … is a continuous creative problem-solving and decision-making process.

• … requires to keep a huge complex system in mind for hours.

• … is all about steadiness: Context and flow-states grow slowly and are disrupted easily

• … is not additive but requires a holistic view. Improving software may need changing foundations and always requires an eye on the overall structure of the building.

• … is about managing your time professionally. After hours coding is usually as damaging as lack of commitment.

We make conscious decisions regarding what quality level we need in what context.

• Quantity ≠ quality

  • The less code we have in the system, the better - it becomes easier to extend, change and maintain.

  • Productivity should be measured in business impact, not lines per hour.

• We build quality upstream in the process (definition of ready, pull criteria, collaborative definition of test cases) to prevent bugs, and rework downstream.

• The squad owns quality. It’s not offloaded to anybody, e.g. QA engineers.

• We run automated tests before releasing to eliminate untouchable code, and the need for code freezes or “Full Release Tests”.

• We release early and often.

• We measure bugs per feature and overall bug lead time (LT) to continuously improve our quality.

• We pair on almost every feature to improve knowledge sharing and code quality.

• We value observability, and fail early in order to adapt more effectively.

We come together to have fun and share knowledge

• Day-to-day: refinements, technical planning sessions, squad events).

• Outside squads: chapter meetings, Code Cafés, Lunch Tech Talks, Eng Reviews, Town Halls, meetups at Wunder, hackathons).

• Outside the office: Meetups, conferences, offsites, code retreats.

Engineers are effective in a healthy environment.

Area	What increases productivity?	What decreases productivity?
Mission & Focus	Clear and steady goals Clear and steady Why Limiting Work in Progress (WIP cap) Supporting 🌏 flow states	Inconsistent goals Strategic and tactical disruption Context switches Multitasking
Value Chain	The amount of spent effort per step increases downstream the feature lifecycle.	Problems need to be solved as far upstream as possible.
Ownership & Trust	Sense of Urgency Autonomy of How Trust Sense of impact Logic & predictability to the process Level playing field	Sense of powerlessness Micromanagement Frustration
Team	Maintained focus impact over time Caring for each other Positivity	Disruption Lack of commitment Negativity

Maslow’s Hierarchy of Needs

Check out the full article 🌏 Maslow’s Hierarchy of Needs for software developers.

The Sweet Spot Between Flexibility and Productivity

• Crunch times are exceptions. Engineers trust their manager and PO that there's enough time for recovery afterwards.

• Staffing decisions are being made with months as timeframe, not days, weeks or years.

The Project Management Triangle

🌏 The Project Management Triangle shows some basic principles of project management:

1. The quality of work is constrained by the project's budget, deadlines and scope (features).

2. To some degree it's possible to trade between constraints.

3. Changes in one constraint necessitate changes in others to compensate or quality will suffer.

Information is necessary. Irrelevant information is disruptive.

• Managers keep their teams in the know and filter what’s relevant.

• Team members give the benefit of the doubt and trust other departments and their managers to do their job.

• We constantly remind each other that zen is the most sane approach to the ambiguity and frequent change of a fast-growing startup.

Relevance of Information for Squad Members (descending)

1. Decided Staffing Changes

2. Signed deals

3. Deadlines

4. Changes in demand (markets, customers) & supply (VC, partners)

5. Prospect customers

6. Feature ideas

7. New product ideas

8. Undecided staffing changes