Goal
The path to "チームトポロジー"
Here is the reading path leading up to this book, derived from its dependencies and ordered from the fundamentals.
The path so far (10 books)
Why read this first: After grasping the basics of readability such as naming and function decomposition, you move on to binding them into principles of why. Clean Code connects individual techniques into a coherent system of craftsmanship and design principles.
Why read this first: After adopting the pragmatic mindset of keeping code healthy, you ground those attitudes in concrete quality standards at the function and class level. Clean Code systematizes what good code is through principles and worked examples.
Why read this first: Once quality at the function and class level is second nature, the next step is to design the direction of dependencies and boundaries across the whole system. Clean Architecture provides the principle of pushing details outward and keeping business rules at the core.
Why read this first: Once you can design boundaries inside a system, you face the next decision: whether to split those boundaries into separate processes—services. Monolith to Microservices, guided by the pragmatic 'monolith first' principle, systematizes the motivations, methods, and pitfalls of decomposition.
Why read this first: Once you have a vocabulary of architectural characteristics and trade-offs, you apply that judgment to the concrete case of distributed systems. Microservices demand a design that deliberately breaks coupling in exchange for independent deployment and autonomy.
Why read this first: Once you understand microservice principles, you advance to realistic strategies for migrating from an existing monolith. Most successes peel services off a monolith incrementally, so you also learn when not to distribute from the start.
Why read this first: Once you can draw bounded contexts, you map those boundaries onto team structure. Aligning contexts with teams lowers cognitive load and speeds the flow of value.
Why read this first: As you carve out services, the question becomes whether the unit of decomposition matches the cognitive load of a team. The inverse Conway maneuver reorganizes teams to fit the architecture you want.
Why read this first: 'The Phoenix Project' lets you experience the chaos of IT operations through a novel, internalizing why DevOps is needed. Once you feel the problem, the royal road is to learn the solutions as systematic practices in 'The DevOps Handbook' by the same author team (Gene Kim et al).
Why read this first: Even if you adopt DevOps as a technical practice, fast flow won't emerge while the org structure stays siloed. Skelton & Pais's 'Team Topologies' presents organizational design that turns Conway's Law to your advantage via four team types and interaction modes, aligning the two wheels of technology and organization.