最近的一两年时间，我算是做了半个Tech Leader吧（毕竟，我自评算不上做得好，就算半个吧），期间也有一些思考、总结，尤其是教训比较多，记录一下。
作为第一篇，先总结下四个鸟瞰视角的内容。
科学，科学，科学
所有的事情，都应该建立在科学的基础上。比如，
只要是一个运行了一段的team，技术债是必然存在的。我可以想到的：
这些问题，看起来都可以不处理，不会对team的开发有任何影响，但是会逐渐的拖慢整个team的开发速度，渐渐的占据大量的人员精力在这些事情上。
用我自己的话来说，这会增加所有团队成员的心智负担。对于程序员来说，这是很可怕的事情。我们需要一个轻松、投入的心智进入高效编码的状态，这些心智负担会大幅度的降低编码效率，从我的经验来说，是存在拖慢10x速度可能性的。
这个世界上有没有10x的工程师，存在很大的争议。但是，世界上存在1/10x效率的组织，绝对没有任何争议。不让自己的团队陷入技术债的低效率泥沼中，是每个TL的责任。
中远期目标相比向历史看的工作才是更加重要的方面。处理技术债、梳理历史需求，最终都是为了规划好中远期目标。一个团队有了愿景，才会对大家产生吸引力，更加方便集合所有成员的智慧。愿景就是驱动力，掌握的好，会让大家开开心心工作。愿景也是TL对整个团队的承诺，不能随便儿戏。
除了愿景，也需要接地气的一点东西，那就是怎样一步步去向着愿景出发（毕竟，100%实现高愿景的难度太大，低愿景也吸引不到真正的人才）。合理安排人力、时间的投入，分配好优先级，同时还要处理好日常工作中的各项意外带来的影响。评估好大家的能力、心理状态，及时的调整。
对于如何区分愿景与画大饼，可以回答两个指导问题
这三个支撑不仅仅是针对自己，也针对自己的整个team。所以，需要自己带领着自己的team，向着这三个目标靠近，自己做不到，也不用指望team可以做得到。
这点不需要浪费口水。但是，更加重要的是解决问题的方式。能不能有更加科学的方法、从更加长远的角度上解决遇到的各种问题，尽量避免救火队长、补缺式的解决问题。
说起来很容易，但是实际上对自己的视野和格局的要求是很高的，不能有“稀缺思维”。有些时候，放弃“小利”才有更好的合作。 尤其是跨部门之间的合作，很重要的就是能够通过保持沟通和透明度来建立信任。其实只要能把事情做成，大家都是愿意主动合作的。比较忌讳的是藏着掖着，这个算是对信任比较有破坏性的。最忌讳的是背后做小动作，一旦被发现，会彻底丧失对方的信任，未来(愉快)合作的可能性基本为零。同时，第一次合作的印象有很大的权重。
尽量避免降低效率的事情：冗长会议、重复工作、太多行政性事务的干扰（比如，避免一些多余的单子）、影响大家心态的事情（比如，要稳定军心）、较差的工作环境（比如，为大家抢个好工位区）、尽量申请开发工具的预算。
最大化实际工作的时间，作为程序员，那就是努力增加大家的心流体验。毕竟，心流体验算是工作中的心理高潮，谁不愿意做一件事情可以高潮迭起？ 说到时间，可以鼓励大家做时间日志。我做过的时间日志的结论是，一天的 纯工作 时间4个小时，就已经是效率很高了，每个成员都能保证这个水平，前面的愿景也有更高的概率实现。也因此，我反对无效加班，第一，长期来看，拖累整个团队效率；第二，这是管理、决策无能后的表现，天天无效加班，那都是啪啪啪打自己的脸；第三，能让大家保持四个小时的高效工作已经谢天谢地了。
这是自己总结的通用流程，事实上这流程拿去训练模型也是一致的。 我很希望能够系统化的整理出一个比较通用可靠的流程，方便自己实践，不过目前我并没有足够的阅历和能力。《原则》里面的五步法也比我这水流程更好一点，有目标驱动。
这块我也在不断的自我总结，希望未来会有更加系统化的结果。