Skip to content

1.0 Introduction to Part 1: People

Software is built by people, and people are organized by culture, structure, and process. So before we talk about code, architecture, or tooling, this part looks at the human system that produces all of it: the shared values a team lives by, the way it divides itself into teams, how it grows careers, how it coordinates day to day, and how it makes and remembers decisions. Everything else in the book rests on these foundations. A brilliant architecture built by a fearful, fragmented, or forgetful organization will not survive contact with reality.

For large teams, these foundations stop being intuitive and become structural. Practices that spread by osmosis among eight people in one room fall apart among eight hundred spread across the globe. So you have to make culture explicit, design team boundaries on purpose, put growth expectations in writing, move coordination from hallway chats to durable documents, and record decisions so their reasoning outlives the people who made them.

Enterprise and government organizations feel each of these pressures at full strength. They work at scale, under audit and oversight, across long timelines, and with a mix of permanent staff, contractors, and vendors. A system you build today may run for a decade, maintained by people who never met you. In these settings the foundations in this part are not soft skills or nice-to-haves. They are the machinery of institutional memory, accountability, and risk management.

Chapters in this part

  • 1.1 Software engineering values: The shared beliefs and everyday behaviors that actually govern how software gets built, centered on psychological safety, blameless learning, clear ownership, a writing culture, and sustainable pace.
  • 1.2 Team topologies and organizational design: How dividing people into teams shapes the software they can build (Conway's Law: organizations produce systems that mirror their own communication structures), using stream-aligned, platform, enabling, and complicated-subsystem teams to minimize cognitive load and reduce cross-team dependencies.
  • 1.3 Roles, career ladders, and growth: Building explicit, calibrated career frameworks with parallel individual-contributor and management tracks, so leveling, promotion, hiring, and pay are fair, consistent, and defensible at scale.
  • 1.4 Ways of working: How teams coordinate, plan, and deliver day to day, favoring principles over rituals and defaulting to asynchronous, docs-first, outcome-focused practices that scale across time zones and mixed workforces.
  • 1.5 Decision-making and governance: Balancing team autonomy against organizational alignment through paved roads, right-sized review, reversible-versus-irreversible thinking, and managing technical debt as a portfolio.
  • 1.6 Decision records: How to write, store, and sustain decision records, most commonly architecture decision records (ADRs), so the reasoning behind a choice survives staff turnover and satisfies audit, and how to make decisions discoverable and even testable.
  • 1.7 Engineering standards and exceptions: How an organization authors, publishes, enforces, and evolves its engineering standards, and how it handles deviations through a governed, documented exceptions (waiver) process so standards stay credible without becoming rigid.

How these chapters interrelate

These chapters form a single throughline. Values define what an organization cares about. Structure and roles determine who does the work and how they grow. Ways of working govern how people coordinate. Governance and decision records preserve the reasoning behind their choices. The dependencies run in that order. The writing culture and psychological safety of chapter 1.1 are preconditions for the honest calibration in chapter 1.3, the docs-first collaboration in chapter 1.4, and the durable decision records in chapter 1.6. The team boundaries designed in chapter 1.2 are your main lever for scaling coordination in chapter 1.4, which openly prefers reducing the need for coordination over adding heavier frameworks. Chapters 1.5 and 1.6 are a deliberate pair: the first sets governance philosophy, the second turns it into a sustained practice.

The reach of this part extends across the whole book. The team topologies of chapter 1.2 shape the platform engineering of chapter 8.4 and the reliability ownership of chapter 9.1. The decision records introduced here recur wherever significant choices are made, from architecture fundamentals in chapter 3.1 to build-versus-buy and procurement in chapter 10.3, and their fitness-function assurance connects to the delivery pipelines of chapter 8.1. The blameless learning of chapter 1.1 underpins the incident management of chapter 9.3, and the defensible, documented decision-making established throughout this part is exactly what the risk, audit, and assurance work of chapter 10.2 depends on. Get the foundations right, and the rest of the book becomes far easier to apply.