主题在升华了哈，由人的重要性，说到人才的重要性了。文中列出了苹果公司乔布斯的案例 从孩子气的在苹果公司‘胡作非为’，到后来的出ceo，大刀阔斧的传奇故事！
仔细想一想确实差不多，没有一个合适的时机，成功绝非轻而易举，况且我们现在处的世界，还站着巨人肩膀上呢，想成功除了自身的能力外，一个机遇是多么重要，设想，在一个公司你能力出众，可你上级就是压着你，不让你上级的上级发现你这个人才，那你也只能就是能力出众而已！好的组织支持增加少量或者大量的额外人手，允许形成新的团队或者把人加到现有的团队中去。这里已经从人过渡到了组织了，毕竟个人力量是有限的。这里作者接下来的意思就是，个人的产出和团队的产出了，我们不能想当然的认为团队的产出会比个人更高，这里有很多因素的，比如一个人就可以单独完成的项目，只要假以时日就能出成绩，而且这个项目专人负责，后期维护也只需要找到这个人就行， 如果让一个团队来做，首要分配每个人的负责范围，再者。。。。随着团队规模的增长，增加成员所带来的额外沟通负担呈线性特征。换句话说，人增加得越多，每个成员的单位沟通和协调成本也就越大。其实很多时候我们都不以为然，但是这么浅显的现象，我们不在其位不谋其政啊，我身边的同事就深有体会啊，一天他的上级家里有事情，要他来协调和沟通和外面的团队对接，一天下来，他说不止一行代码没写，简直就是位置都没怎么坐热啊，跑来跑去的，不是这里有需要和开发人员讲解的，就是那块和需求争论得失。
这就涉及到团队多大才沟通起来流畅的问题了？两张披萨饼团队规则：任何一个团队的规模不能大过两张披萨饼能所喂饱的人数。我想这就和起初的孙子说的 斗众和斗寡的核心了，一个团队的大小多大才合适，才能让指挥起来像指挥一个人一样了。任何一个持续成长的公司最终都需要解决系统、组织和流程的扩展性问题。
职能型团队
在一个采用瀑布型开发方法的职能型组织中，研发的责任显然落在工程团队上。因为软件工程师都向工程部门的负责人汇报，质量保证工程师均向质量保证部门的负责人汇报，所以非常容易制定，发布，遵循和执行标准。
职能型或者直线型结构的问题包括缺乏单一的项目负责人和跨职能部门的沟通效果不佳。项目很少只发生在一个职能部门内。大多数软件研发项目，特别时通过网络交付的服务，总是需要不同技能的人来共同完成任务。
在职能型组织中，跨部门沟通出奇难。例如，软件工程师想告诉质量保证工程师，必须进行某个测试以验证功能是否正常。为此，软件工程师很可能要浪费宝贵的时间，在质量保证的管理层级中上下求索，知道找到负责的测试同学。工程师可能会依赖现有的设计规范文档，通过流程来传递这些信息。可以想象，研发和测试之间，写一个20页长的测试规范比面对面对话要带来多少额外的负担。
另外一个挑战是，团队之间的冲突。这个团队没有能按时完成任务和那个团队交付的产品存在错误，这些都是那些按照职能型结构组织起来的团队在合作时经常听到的抱怨。工程师们想要有归属感和被同伴接受，其他不同的人（测试工程师，产品经理，甚至运维）经常被当作圈外人士，而不被信任，甚至有时候被成为公开的敌对目标。
好处是同质性，责任简单清晰，有标准可议。不利的地方包括没有单一的责任人和沟通不顺畅。
目前，我们遇到了类似的问题，虽然，有纵向的团队在一起做事，但是太过临时，相当于是把职能型团队微观化了。团队成员之间交流少，开发流程更接近瀑布模式 。