对于软件行业的从业人员，不论是管理者还是工程师，对于软件设计的重要性都应当有允分的认识，只有这样才有可能在团队中构建真正有意义的愿景。是的，具备出色软件设计能力的工程师少之又少，但这并不表明它不重要。相反，这种人的工作效能很有可能是普通工程师的百倍。
除了认识软件设计的重要性，整个团队还应当至力于打造适合的质量保证方法论。再次提醒一下，这里的“合适”是指“易用和够用”。项目组不论资源多充足、人多聪明，都比不过质量保证方法论来得实在和有效。一个拥有自已质量保证方法论的团队，可以预测，团队的个人生活质量以及团队的集体声誉和精神面貌都将与众不同。。
“通过技术方法解决技术问题而不是管理方法”是作者想强调的另一个重点，作者将这一思想命名为李云技术管理第一法则。项目开发是一个复杂的系统工程，但是其中很多问题其根源并不是来自于管理领域，而是技术领域。技术根本问题解决了，表面看起来是管理方面的问题都将迎刃而解。请不要相信管理是万能的，合理地运用团队的技术技能和管理技能才有可能打造出出色的团队，以及最终创造出高质的产品。
过份地强调风险是软件开发活动中阻碍团队提高的可怕障碍，请记住“李云技术管理第二法则：过分地强调风险其实是间接地承认自己无能，”这一点无论你是管理者还是工程师都一样。
从管理者的角度
作为管理者应当明白，如果将风险最小化、服从上级指示作为优先考虑的工作内容，那很难带出一支出色的工程师队伍。通常管理者的薪资也相对的高，站在管理者的角度，为了保证稳定的高收入，小心谨慎是应该的，但是别望了现任雇主提供高薪的同时，还希望管理者承担另外的责任和义务 —— 培养团队。只有团队培养好了，产品的质量才能随之“水涨船高”。
团队的培养，一定要给工程师们合适的“土壤”、一种允许工程师们适当犯错的环境，当然，总是犯相同的错就另当别论了。软件行业如果想做到什么事都百分百的正确和没有风险，那只能是什么都不做。一个敢想、敢做和敢当的团队，只会让管理者的工作更加的轻松，这样的团队每一个管理者都有机会获得，但必须由管理者自己去培养。
花时间培养对团队的信任是重中之重，请不要将“我信任我的团队”只作为口号，而内心却总是想着“这样让他们干可能会给我捅出篓子来哦”。对团队的信任其培养方式只能是让团队在一定范围内放手去干，一旦团队的能力强了对之的信任也就慢慢地有了，且很有可能形成一种良性循环。
管理者很有可能想培养自己的技术专家，技术专家的培养不是选中一个或几个人，然后给之机会去成长。对于技术专家的培养，应为更多的人乃至整个团队提供平台去发挥，而不用专门选择人选，具备技术专家潜力的工程师一定会在这种环境中自发地出现。另外，技术专家的培养需要长时间的观察。存在一类工程师，在管理者面前表现得很有想法，但真正做起技术来时却一般，且缺乏追求完美的精神。这种人能博得管理者对他的好印象，乃至让管理者认为他能被培养成技术专家，但一个对技术工作没有追求完美精神且付之于行动的工程师很难成为技术专家。为此，管理者在培养技术专家时，不防将“网”撒得大一点，给大家的时间也长一点。一个真正的技术专家不是管理者认命和培养出来的，而是团队自然而然集体选择出来的。“自然而然”体现在，当出现问题时大家都会主动去找他（潜在的技术专家）以获取有价值的帮助。
一个健康的团队需要有争论，管理者千万不要将消除争论作为自己的一个管理目标，从而追求一种表面的“平和”。软件行业中的科学成份有不少，如果对于技术的争论都不敢（很少工程师会就个人问题而放到台面上争执），那很难想象团队做的技术到底是什么层次。积极的争论有利