在Jeff看来，团队里最重要的事情，是人与人之间地协作和沟通！所有的问题，其实都是人的问题。“不管什么问题，那总是人的问题”-温伯格。即，让你和团队陷入困境的最快的方法，就是认为技术是决定性的因素，而且你相信你能轻易解决其它方面的问题。事实上，正是你所认为的“其它方面的问题”，最可能让你和团队止步不前。
这一章里，Jeff主要列举以下几个要点：
1. 领导须以身作则
团队，首先要有的就是纪律，也就是由大家共同讨论协商并决定的标准。每个团队都需要一个领导，带领大家去遵守并有效执行这些标准。以身作则，从以下几个方面树立示范带头作用（有时候也是因为他们没有时间和权力强制其他成员执行，只得“身先士卒”）：
a) 保持谦虚，总是先假定你是错的，特别是你在骄傲（这是非常不好地一面）地宣布你的发现之前，你应该努力确保你的观察结果是正确的，以维护你良好的信誉。
b) 提出建设性的批评时要小心，要注意方式方法。开发人员更容易接受非正式的建议和具有巧妙引导性的问题，而不是把同样的内容以电子邮件（或大声吼）的方式发送给整个开发小组。扩大受众面很可能会引起开发者的防御或逆反。团队其它成员会猜测你的动机，如果有人认为你贬低别个，是为了抬高自己，哦，那你就要遭了！
c) 要想赢得信誉和尊敬，最好的方法就是努力工作，并且取得实实在在的成绩。特别是不能“光说不练”，例如群发“最佳实践”、“银弹在这儿”等。如果你想建议什么，你应该为些付出行动，做好充分准备。当然，这并不能保证团队（或部分其他成员）对你的倡议一一呼应，而且还可能徒劳无功，但是团队（或大部分成员）会意识到：你付出了努力，你在积极向前。
d) 要学着在乎别人，真心地去帮助别人。无论是为了激励一些人，还是为了推动项目的前进，团队中的成员始终需要帮助和关心。“我不想别人是因为怜悯面帮助我，我不想别人是因为自私而帮助我，我想要别人对我做的是，真正的爱我--当然不是那种Gay之性情，而是真正的对人性的关怀，让我人心里感受到这份真诚和关爱”。让那些受帮助之人，必须相信你是真的关心他们，事实上你也是这么做的。“黄金准则”适用于此。
黄金准则（Golden Role）：一条公正的准则，它引导人们要“像你希望别人如何对待你那样去对待别人”，换句话说，你希望别人如何对待你，你就怎样去对待别人。
2. 程序员与系统管理员应该协作
要确保程序员和系统管理员不把时间花费在内斗上，面要用他们的超自然的能力，一起来完成一个不合作就无法达到的共同目标，派给他们的任务，应该是足够艰巨的--一个需要他们完全组合并使用他们的独特技能才能完成。让每个人都能把精力专注于各自擅长的事情上，一个健康的团队里，每个人都会觉得自己的能力源上了用场，而不是被浪费了。
注：其实，我真没有明白，此处的“系统管理员”到底是什么角色！
3. 结对编程与代码审查
结对编程的优势在于它的即时性：当负责复查的人就坐在你边上的时候，你是不可能忽略他的。大多数人在可以选择的情况下（如事后的代码审查），都会选择息事宁人，但是在结对编程中，是不可能的。结对编程的两个人总是有不同的技能，面这些技能是可以传递的，当一个人向另一个展示一些技巧、精妙的变通方案的时候，这实际上也是一种临时培训。更重要的是，两个都完全了解代码，这对谁（特别是公司）都是一个好处。
代码审查和结对编程有类似之外，作用也有几分相似。当然，一个公司从零开始，建设代码审查制度也是一个痛苦的过程，可能会有很多抱怨，但代码的质量以及可维护性方面，将有巨大的进步和提高。不过，代码审查也依赖于审查人员，有的时候，他们并不愿意“浪费个人时间”在代码审查上，直到某一天他们去维护这段代码，才会收到更多的反馈，甚至是怒气冲冲地抱怨，更甚至他们想推翻重来。“反正不是我的代码，才不管它到底有多臭”！
要保证有超过一双眼睛在看你所写过的代码！
4. 正确对待会议
应当以怀疑的态度去看待会议，把它当成是一种降低工作效率的风险，始终谨记：之所以开会，是因为我们需要它！会议原则参考：
a) 不超过一个小时！否则，我们就要再仔细审核下，是否会议牵涉的人太多了，是否讨论范围太宽范了，是否缺少必要的焦点？
b) 要有一个清晰的目标声明。要确定参会的每个人都很清楚会议的目的。
c) 开会之前预先做好功课。每个与会者都应当提前知道他们将要讨论和分享的内容，并且在走进会议室之前，已经做好了准备。
d) （尽力）把会议变成可选择的。不要“强制”任何人，必须参加这个会议。每一个出现在会议上的人，都应该是因为他们想要站在那里，或者需要他们站在那里。让每个人自行决定，是否需要参加这个会议。
e) 在会议结束时，要概括一下待办事项。会议要有一个专门的会议记录人员，并且，每个人最好在离开会场之前，概括并确认一下他们的待办事项。
让我们少说废话，快速干活，抓住工作重点。
5. 剔除团队的“坏苹果”
如果把一个坏苹果留在一筐好苹果里，结果你将得到一筐坏苹果，这就是“坏苹果”法则。一个人的态度将影响到一个团队，如果想使你的企业成功，那么你必须有一个积极进取的团队。
“坏苹果”会损害其他优秀开发人员的士气，如果团队主管不愿意直接并有效处理这些“坏苹果”，那么这些主管给团队带来的扰乱，比其它任何单方面的团队领导力问题都要严重，他们这是在玩忽职守，应该敢于调走甚至开除这些“坏苹果”。
如何确定“坏苹果”，以下几条仅供参考：
a) 掩饰自己的无知，而不是尽力去向团队其他成员学习。
b) 对个人隐私有着过度的渴望，“我不需要其他人审查我的代码”。
c) 很在意自己的地盘，很在意其他人动他们的代码。”我这几天比较忙，这个问题我（不是你）下周再解决”
d) 抱怨团队所做的决定，并在团队已经继续很久了，还在重拾此话题。
e) 团队其他成员，在讲他的悄悄话或地报怨他。
f) 不积极投入团队活动。
g) 沮丧的悲观主义者，经常说“随便”，“我无所谓”，“不关我的事（我自己加的）”。
当然，有时候，一个特别优秀的领导者，一个有较强沟通能力的人，一个可以四处询问、征求意见的人，同时确保每个人的意见都被认真对待的人，或许可以挽救或降低“坏苹果”所带来的影响。
仔细想想，有的时候，自己就是那个“坏苹果”！
6. 远程办公建议。
a) 只有高手才适合！
b) 要有每周一总结，包括：上周工作总结，本周工作计划，需要处理的问题或需要协调沟通之事项。
c) 详细简洁的会议纪要，参会人？讨论的主题？所做的决定？下一步工作计划？
d) 简单无噪声的邮件列表或BBS。