为了确保团队中的每个人都能保持系统概念上的完整性，关于项目的书面规格说明是必不可少的。手册要描绘用户可见的一切，但不应支配实现的过程。光有规格说明也是不够的，会议也是必要的。书中提到的周例会会迅捷地给出一些问题的决策，但一些堆积的小问题会逐渐影响工作进度，这时候就应召开级别更高的月会或年会。
书中举例了巴比伦塔建造失败的例子来说明团队中交流的重要性。说明手册固然是个好东西，但是随着工程进度的推进难免会有一些新的想法，工作手册的及时更新就十分重要。此外，由于查看更新是一件非常麻烦的事情，故对变更的简单总结也很重要。对于较大型的项目，技术主管和产品负责人往往不是同一个人。在产品负责人作为总指挥，技术主管充当其左右手的模式下，声明技术主管的技术权威是非常重要的。当然，对小型团队，技术主管做总指挥，产品负责人做左右手也是不错的选择。巴比伦塔建造的失败，就是交流和组织失败的结果。
系统编程需要多长的时间？这是一个重要但难以估计的问题。一个非常重要的事实是：
工作量=常数*指令的数量^1.5
即对单个程序员来说，程序的规模越大，程序员的代码生产率就越低。所以在考虑系统编程时间耗费的时候，应考虑规模与时间的指数关系，而不是线性关系，这一点至关重要。另外书中指出，使用适当的高级语言，编程的生产率可以提高5倍。
作为项目经理，规模控制是必须的一部分。对于程序所耗的内存，应衡量它带来的易用性和性能是否值得。编程人员应学会技巧和战略上的突破来降低算法的复杂度。