不懂技术的人如果做了研发团队的领导，很容易出现严重的问题。例如，技术会议他到底需不需要参加，如果是一位技术专家出生的人，毫无疑问他需要参加，但是如果情况不是，这时候就会出现麻烦。他参加或者不参加，都会引起麻烦，所以尽量避免这样的人出任研发团队领导。另外，对于整个研发过程的管理，不懂技术的人很容易完全从产品角度考虑，忽略研发团队面临的困难和风险，忽略技术人员对于技术的憧憬，造成团队超负荷工作的情况、技术团队缺少技术愿景等情况发生。

举个例子，遇到业务方提出的需求完成时间点过于苛刻的情况（其实这是一个压力传导问题，业务方收到了客户的压力，本来可以通过向客户解释等方式减少研发的压力和风险，但是选择直接施压研发）。这时候，你的这位不懂技术的团队老大可能会说，没关系，我们一开始并不需要一个完美的系统，你先上了再说，先解业务的渴，我们后面有时间再重构再完善（当然有的技术人员也会用“架构和设计是逐步演化出来的”这句话来证明“故障驱动”开发是值得的），这样的想法本质上是错误的。

一些人喜欢对缺少需求分析、技术设计环节解释为“这是敏捷开发，和你们的瀑布式不一样”，拜托，别这么黑敏捷开发了，人家是很好的一套开发流程。缺少应该有的文档或者文档写得一塌糊涂，这是能力的缺失，不是时间紧迫导致的，不要把好端端的敏捷开发描述成万恶之源。敏捷开发的实质是为了解决需求快速变化的情况，需要快速响应需求提出方，快速搭建产品原型用于验证实际效果，而不是说有了敏捷就可以忘记软件工程理论，不管三七二十一，先随便写一堆代码再说，这是不合理的。任何的软件工程模型，都不会允许在需求完全不明确、描述不清楚的情况下，开始进行技术方案设计，也不会鼓励在方案设计缺失情况下开始编码，因为这个时候没有人知道究竟如何编码。

团队领导可以不是对口专业出身，但是他必须对技术有热情，之前工作经历包括了开发工程师经历，他需要对技术有敬畏之心，总结为两点：

1)基础知识和理论知识非常重要。多多使用已有的成熟的方案是关键。

2)对技术要有一颗严谨和敬畏的心。想清楚了再干，坚持高标准，很多事情都急不来。