不懂技術的人如果做了研發團隊的領導，很容易出現嚴重的問題。例如，技術會議他到底需不需要參加，如果是一位技術專家出生的人，毫無疑問他需要參加，但是如果情況不是，這時候就會出現麻煩。他參加或者不參加，都會引起麻煩，所以儘量避免這樣的人出任研發團隊領導。另外，對於整個研發過程的管理，不懂技術的人很容易完全從產品角度考慮，忽略研發團隊面臨的困難和風險，忽略技術人員對於技術的憧憬，造成團隊超負荷工作的情況、技術團隊缺少技術願景等情況發生。
舉個例子，遇到業務方提出的需求完成時間點過於苛刻的情況（其實這是一個壓力傳導問題，業務方收到了客戶的壓力，本來可以通過向客戶解釋等方式減少研發的壓力和風險，但是選擇直接施壓研發）。這時候，你的這位不懂技術的團隊老大可能會說，沒關係，我們一開始並不需要一個完美的系統，你先上了再說，先解業務的渴，我們後面有時間再重構再完善（當然有的技術人員也會用“架構和設計是逐步演化出來的”這句話來證明“故障驅動”開發是值得的），這樣的想法本質上是錯誤的。
一些人喜歡對缺少需求分析、技術設計環節解釋爲“這是敏捷開發，和你們的瀑布式不一樣”，拜託，別這麼黑敏捷開發了，人家是很好的一套開發流程。缺少應該有的文檔或者文檔寫得一塌糊塗，這是能力的缺失，不是時間緊迫導致的，不要把好端端的敏捷開發描述成萬惡之源。敏捷開發的實質是爲了解決需求快速變化的情況，需要快速響應需求提出方，快速搭建產品原型用於驗證實際效果，而不是說有了敏捷就可以忘記軟件工程理論，不管三七二十一，先隨便寫一堆代碼再說，這是不合理的。任何的軟件工程模型，都不會允許在需求完全不明確、描述不清楚的情況下，開始進行技術方案設計，也不會鼓勵在方案設計缺失情況下開始編碼，因爲這個時候沒有人知道究竟如何編碼。
團隊領導可以不是對口專業出身，但是他必須對技術有熱情，之前工作經歷包括了開發工程師經歷，他需要對技術有敬畏之心，總結爲兩點：
1) 基礎知識和理論知識非常重要。多多使用已有的成熟的方案是關鍵。
2) 對技術要有一顆嚴謹和敬畏的心。想清楚了再幹，堅持高標準，很多事情都急不來。
