1.0 Introduction to Part 1: People
Software is built by people, and people are organised 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 organisation 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 organisations 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 behaviours that actually govern how software gets built, centred 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: organisations produce systems that mirror their own communication structures), using stream-aligned, platform, enabling, and complicated-subsystem teams to minimise 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 levelling, 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, favouring 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 organisation 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.
1.8 Hiring, interviewing, and onboarding: Building the team deliberately through inclusive sourcing, structured and calibrated interviews that reduce bias, and a real onboarding plan that gets new engineers productive and belonging quickly rather than sinking or swimming.
1.9 Distributed and remote work: Operating across locations and time zones by defaulting to asynchronous, written, documentation-first collaboration, designing deliberate overlap and handoffs, and judging people on outcomes rather than on hours or visibility.
1.10 Engineering effectiveness and developer productivity: Measuring and improving how effectively engineers can do their best work using multidimensional frameworks (SPACE and developer experience) instead of single gameable numbers, and removing the friction and toil that slow teams down.
1.11 Engineering management: The craft of managing engineers rather than the career ladder itself: the one-on-one, feedback, and coaching loop, delegation, humane performance management, and being measured as a multiplier of the team rather than by your own output.
1.12 Diversity, equity, inclusion, and belonging: Building a team where difference is present, treated fairly, actively included, and made to feel it belongs, because inclusive teams build better software and because it is right, with honest measurement and no tokenism.
1.13 Mentoring, coaching, and knowledge sharing: Growing people and spreading expertise on purpose through mentoring, coaching, and sponsorship, communities of practice, internal talks, pairing, and documentation-as-teaching, so knowledge outlives any individual and bus-factor risk stays low.
How these chapters interrelate
These chapters form a single throughline. Values define what an organisation 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.