假如这些兄弟确实技术能力很强，那么技术体系可能会很好，假如技术能力不强，设计和开发出的东西没有任何的审查，技术负债就会很多，而技术负责人本来的职责不就是掌控技术质量吗？你完全放开，atv，要你何用？

　　家族式团队很有可能和原有团队产生摩擦，比如原有团队感觉受到了排挤，很有可能处处不配合，而新进团队可能为了有更多的话语权，会抢班夺权，所以这两个团队就为了私利，不会专注于技术，内耗会很严重。

　　这种事情就很多，比如某个公司，新来的技术负责人带来了自己的团队，并且都是级别很高的职位，而老同事感觉这些人啥都不懂，什么也解决不了，而新来的团队又各种的变革，导致互相利益不平衡，很多老同事走了。

　　请先进行技术方案的设计

　　对于一个刚来的技术负责人来说，有许多工作，比如组建团队、了解产品，但更重要的是设计靠谱的技术方案。

　　首先要了解系统存在的问题，要了解产品未来的走向，要了解技术团队的现状，针对这三点，你需要亲自操刀，设计一个针对目前最优的技术方案。

　　为什么要亲自呢，因为你是技术负责人，不了解技术问题，就无法进行技术管理，亲自设计了，才能有针对性的去解决问题，将来系统遇到瓶颈，就能更好的优化或者重新设计。不要用各种理由不去做这个事情，在早期这很重要。

　　不要过度追求专业化

　　其实在创业公司，一般追求小而快的概念，但是很多从大公司出来的技术负责人充满激情，任何事情都想追求专业化，这可能会出现很多问题，这里举几个例子。

　　存在很多没有意义的技术岗位，比如现在很多产品并没有多少的用户，可非要搞数据挖掘，很多数据通过简单的 Shell 脚本就能解决，可专业的数据挖掘岗位要求并不低，从成本和效益看，并不建议有。

　　喜欢造轮子，在创业团队，其实应该多用开源的解决方案，现在发现很多公司喜欢自己实现或对原有软件做扩展，假如没有特殊原因，应该用成熟的解决方案，原因第一就是研发成本，第二就是这个开发成本会很长，第三就是稳定性有待考量。

　　过度设计，就是设计的方案不结合目前的实际情况，考虑的太复杂，所以实现的也特别复杂，和造轮子一样，也存在同样的浪费，其实过度设计到还好，就怕错误设计，比如我原来单位，非觉得 MySQL 性能不好，要加一层 Memcached 缓存，最后设计并线上使用发现后，缓存命中率非常低，白白浪费了大量服务器，损耗了性能，并增加了系统的复杂性。

　　不要有开发语言歧视，比如前端业务层用 PHP，后端数据层用 Java，性能没有想象的那么夸张，这也是细分岗位的一种缺陷。

　　专业化的反面其实就是技术负债，上面也只是简单的说下，有很多的最佳实践指导，想表明的就是太专业化是对效率的最大打击（时间、成本等等），我原来也遇到很多类似的情况，这个伤害分为两个阶段，第一阶段就是短期的一锤子伤害，比如说技术方案上线了，浪费了一些时间和成本，但是这个浪费是固定的，可衡量的。第二阶段就非常难衡量了，为早期的决策还债，比如说原来的技术方案上线后，后期开发特别难扩展，维护也非常困难，累计起来是对生产力的极大打击，成本非常昂贵。

　　招人要慎重

　　关键词就是数量和质量，没有合适的情愿不招。在创业团队，项目一个接着一个，很容易造成一个假象，开发人员不够，所以就大量的去招人，这是非常不成熟的行为，尤其假如这个技术团队没有太强的最佳开发实践，新来的人员可能会很茫然，各有各的开发习惯和模式，会导致 1+1 < 2 的现象产生。人一多，分工就要细化，一细化协作就会产生一定的问题，所以招人要控制数量。

　　第二就是重视质量，质量这个词每个人都有自己的标准，我核心的观点就是情愿使用一个技术底子扎实的毕业生，也不愿意使用一个有多年开发经验但无技术底蕴的人。一个没有技术体系的开发人员总有一些瓶颈和不好的习惯，会有很多累。

　　不了解公司负责人

　　很多公司负责人找技术负责人的时候，都是求才若渴，目标就是希望这个人去搞定技术事宜，可在头脑中并没有衡量标准，一切都是变化的。

　　对于一个技术负责人来说，可以天天和他聊，告诉他架构的重要性，人员的重要性，这些确实很重要，但并非必要性，对于公司负责人来说他其实就关注开发速度、稳定性、产出，他并不关心深层次的技术内部是如何运转的。