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