某人曾说过，“What does not kill me,makes me stronger.”
根据周围公司的情况，总结了拖垮中小公司技术团队的主要因素，当然，你也可以使用下面的手段，把你现在的公司拖垮（与本人无关），正所谓术高莫用，年轻人，耗子尾汁：
1、外行管内行
大部分公司，老板本身不懂技术，有些老板略懂业务，更多的老板是更懂市场，老板找一个会包装自己但没有做过开发的人来管理技术团队，那位说老板不傻，只能说在他懂的范围内不傻，在他不懂的范围内很多老板看不透彻，让一个没有写过一天代码的人管团队会出现什么情况呢？主要如下：
- 流程一团乱，不知道用什么流程好或根本就没有流程可言
- 常常忽略整体设计，没有任何设计思想可言
- 脱离技术，浮于表面，正是所谓的"White paper" 设计
- 裙带关系应运生成，因为厉害的技术人才往往有自己的思想，不会随便听从外行的指挥，一定会有矛盾产生
- 其他…
2、去大公司挖技术牛人，认为一个人就可以力挽狂澜
许多短期内不缺钱(没有企业真正不缺钱)或刚融了资的中小企业，去大厂挖了几个所谓的牛(luo)人(si)回来，想造航母，养恐龙。不仅挖来的人发挥不了作用，还激怒了一起奋斗的老员工：舍不得给自家兄弟加工资，倒是给外人吃香喝辣的。
这就叫：偷鸡不成，还被鸡鄙视，得不偿失啊。
3、敏捷或OKR
敏捷和OKR本身都没有问题，都很好也很积极，但敏捷和ORK对团队成员的素质有很高的要求，不仅仅是技术能力，还有自我驱动能力，在国内厉害的master都去了大公司，所以并且大公司可以用较长的时间进行团队的训练，促进团队成员之间的协作，敏捷或OKR也是需要成员之间合作的，就像走独木桥，很多公司不以为然，从网上找几个流程就用起来了。
其实中小公司的流程都是比较简单的，Leader的权力也非常大，按常规的迭代出问题的概率要小很多，有的时候就要在快慢、出问题的概率上做取舍。
4、不遵循人员比例
中小公司资源有限，但也不能忽略人员比例，让一个人干两个人的活，不难度，没有责任心的人也干不好，如果研发和测试全都由开发来干，估计不会有好的效果。所谓的全栈，大都比较水，写写demo尚可，一但涉及性能、规模级的应用，就捉襟见胳膊了，同时在一客程度上还要考虑重要岗位的B角，但也不能盲目扩张。
5、“狠”抓技术管理
Leader一定是技术比较强的，业务和技术都比较强的更好，同时不能使用脱离团队的技术，有一定的规范和流程，如：代码规范、上线流程、一些必要的标准，同时还要兼顾灵活，做好激励，奖惩明确，考勤能没有就没有，十几二十个人，谁怎么样还是知道的。不要以Leader自居，应以身做责，起好带头的作用。小团队要有一定的灵活性，同时避免造轮子，不要为了追求极致而浪费时间。
6、 鼓吹创业文化
一般技术人员不可能都是创始人，都是挣扎在温饱线上的同仁，为要深入谈什么理想，你有理想是你的，不是他们的，你可能衣食无忧了，他们还在为吃什么，给女朋友买什么，给家里寄多少钱而发愁。
同时也提醒广大同行们，和你大谈理想、称兄道弟的都是不想多给钱的老板，有多远就离他们多远，永远记住：身体是自己的，时间也是自己的，梦想是别人的，当然你也有你的梦想
7、 按代码行数、bug数，实行绩效考核
小团队（低于20人的）不建议有复杂的考核，大一点的团队也不建议有复杂的绩效考核，不会很客观的，这个可以放心，存在很多主观因素，曾经有的公司使用互相打分机制来决定考核结果，也是创新！
代码行数不是工作量的直接体现，也不是工作难度的体现，往往一个关键路径的代码行数是极少的，代码行数、bug数千万不要做为考核的依据，否则就等着团队解散吧。很快就会出现难的事情没人做，因为容易出错，不出成绩，bug还多。
8、苛刻的制度
迟到扣钱、早退扣钱、上班时间监控员工、行政或hr耍小手段、见风使舵，
绩效考核面谈扣各种细节
总之让员工各种不爽，各种心里堵。
8、 中台化
中台真的是大公司玩的，上中台后，流程会比较复杂，各种支撑软件、框架随之而来，7*24小时不断，或许你的数据量业务量真的不适合上中台，能简单就简单，简单到不能再简单了为止。
9、极至的UI体验
人不多的时候，虽追求什么UI的体验和效果，不可能做好，也别和大公司比，你永远不知道大公司投入了多少人力，一个简单的PPT模板，就有可能是大公司每年投入几十人在做。一个客户端的开发团队可能超过你整个技术团队，
别追求什么极致产品体验，就那几杆破枪、就那几个水平一般的人，没法极致。如果老板连这点智商都没有，你也别跟着瞎折腾了，前面是死路一条。
10、团队之间勾心斗角
几个团队之间，互相甩锅，都不是自己的问题，如果不是每个团队的问题，那一定是Leader的问题了，谁让你是Leader呢？你有权力也有责任帮忙处理这些问题。甩锅成风后，就等着吧，会越来越乱的。