本书的核心是定义了四类基本团队拓扑：
- 流动式团队、赋能团队、复杂子系统团队、平台团队；
流动式团队
什么是“流动式团队”？
- 它对应一条单一、有价值的工作流，这也许是一个产品、一项服务、一组功能特性、一个用户故事或者一组用户画像。
- 流动式团队是组织中最主要的团队类型，其他基本团队拓扑的目标都是为了减轻流动式团队的负担。
- 与“流动式团队”相反的是按照“项目”组织开发工作。
“流动式团队”的必要能力，包括但不限于
- 应用的安全性、商业和技术的可行性分析、设计和架构、开发和编码、基础设施和可运维性、度量和监控、产品管理、测试和质量保证、用户体验；
为什么要叫做”流动式团队“而不是”产品团队”或“特性团队“：
- “流动”一词有着更广泛的含义，它有助于强化组织对流动性的关注，从而确保流动的顺畅；
- 并非所有的软件都有产品或者特性这样的概念，但是总是可以从流动性的角度出发；
流动性团队的预期的行为：P94。
赋能团队
什么是“赋能团队”？
- 赋能团队由特定技术领域或产品领域的专家组成，它们给流动式团队提供“调研、学习、实践”新技术的能力。团队进行调研工作，尝试不同的方案，并在工具、实践、框架、技术栈等方面给出高质量的建议。
- 赋能团队应该尽可能避免自己成为知识的“象牙塔”：
- 不应该干涉其他团队的技术选择，而是要帮助团队理解并遵循组织级的技术约束；
- 应该提高流动式团队的自主性，而不是推广自己手动已经有的解决方案；
“赋能团队”的预期行为：
- 赋能团队要主动了解流动式团队的需求，在深入协作时建立定期检查点和联合沟通机制；
- 赋能团队要保持它们的专业能力保持在浪潮之巅（在过去，这常常被视为架构师或者创新团队的使命）；
- 它们既要传播好消息，也要传播坏消息；
- 当流动式团队难以直接使用某些服务时，赋能团队应该充当内外部的服务代理；
- 不仅要促进自身团队内的学习，也要在流动式团队之间扮演组织内促进共享必要知识的角色。
与实践社区（Communities of Practice, CoP）:
- 共同点：它们都能提高团队的认知和能力；
- 区别：赋能团队每天的工作就是赋能，而实践社区则是一个相对松散的组织，每周甚至每个月才会搞一次活动；
复杂子系统团队
复杂子系统团队负责构建和维护系统中严重依赖专业领域知识的子系统。它们的设立目标是降低包含或使用复杂子系统的系统中各个流动式团队的认知负荷。
与传统“组件团队”的关键区别：
- 当某个子系统依赖于大量特定领域知识时才会建立“负责子系统团队”；
- 团队成立完全是基于认知负荷驱动的，而非出于组件共享的目的；
“复杂子系统团队”的预期行为：
- 根据当前的开发阶段来安排响应的工作：在早期紧密合作，后期关注接口；
- 应该显著提高流动式团队的交付速度和质量；
- 需要根据需求优先级合理安排并完成交付。
平台团队
平台团队的目标是使流动式团队能够以高度自治的方式交付工作。平台团队提供的内部服务使得流动式团队无须开发底层服务，从而降低认知负荷。
平台团队应该聚焦于提供少量、高质量的服务，而不是提供大量存在可用性和质量缺陷的服务。
“平台团队”的预期行为：
- 与“流动式团队”密切合作，理解“流动式团队”的需求；
- 团队依赖于快速原型技术，应该尽早地引入流动式团队成员以获得快速反馈，从而得知哪些有效而哪些是无效的；
- 需要重点关注服务的可用性和可靠性，并将平台视作为一种产品，需要定期回访用户以确定服务的可用性，以及服务是否依然满足用户的需求；
- 如果可以的话，平台团队自己也应该是服务的用户，可能的话，也应该依托于其他团队负责的下层平台；
- 平台团队应该明白提供的新的内部服务应该像创新曲线那样被各个流动式团队逐步引入，而不是一蹴而就的；
一个平台团队内部也可以像一个组织一样嵌套地由四类基本团队拓扑构成；
设计团队拓扑的注意事项
避免变更流程中的团队竖井：
- 应该避免只由单一职能的人员组成的团队，很多组织都创建了这样按照人员专长分组的孤岛，也被称为职能竖井（比如：QA、DBA、UX、ETL、运维 等），这种模式并不理想；
- 一个工作流中的不同阶段和任务应该由同一个团队负责，避免不同团队间的交接；
一个优秀的平台应该“够用就好”：