在外企工作十年，從程序員做到一線開發經理，再后來轉到公司美國總部，又做回程序員。工作角色的變化促使自己思考，分別站在程序員和開發經理的角度看，怎樣的程序員是出色的程序員，怎樣的開發經理是好經理。經歷團隊發展過程里種種好的、壞的變遷，再加上看到、聽到其他團隊的經驗教訓，就越來越有感觸，掌握全棧技術對一線開發經理很重要。
開發經理的職責是確保軟件產品按時保質發布。流程也為這個目標服務， 但流程本身的作用很有限。軟件開發流程理論經歷瀑布式，迭代式（RUP, 又稱統一軟件過程）以及現在的敏捷開發（敏捷在現實中幾乎就是scrum），理論越來越成熟完善，但落地執行又不簡單。 大量文章都在分析為什么敏捷流程在很多開發團隊不起作用。比如最近看到 為什么敏捷開發在亞洲實行不了 里說， “敏捷開發需要大家當面直言問題所在，而這有悖于亞洲文化，因為亞洲人特別注意對別人表示尊重、給別人留面子，這一點與西方文化特別不同，而西方正是敏捷思想的發源地。” 從自己的親身經歷看，這純屬扯淡。講到留面子，和稀泥，打太極拳，老美一點兒也不輸給中國人。流程只是個工具，能否因地制宜執行得好，開發經理起到決定性作用。沒有普適的流程，針對一個特定的團隊，只有合適的流程。 全棧型的經理比較容易領導團隊做正確的事情并做得夠快。 能做到這一點，是不是scrum都不重要。他不必在各個方面都是專家，但至少需要能預見技術上重要的風險才能及時采取措施處理。一些技術決定對項目成敗有關鍵性的影響，比如技術選型，搭建軟件應用的架構，包括分層, 模塊化，secruity, transaction, exception, audit，自動化測試等等。開發經理不必把這些工作都承擔了，但至少需要把關，保證這些核心的工作沒有明顯疏漏。因為最終為產品發布負責的還是開發經理自己，而不是某個犯了錯的程序員。不全棧，把關自然就不全面。
開發經理的各項工作中，我認為最重要的就是面試招聘。招對了人，工作中即使遇到棘手的問題，技術好素質高的隊員自己就解決了。團隊不怕小但要精，隊員必須能獨當一面。不論前臺后端，經理至少應該具備足夠好的技術品味過濾掉不合格的應聘者。喬布斯有個觀點，一旦招了庸才，兩年后，就會輪到庸才做面試招聘，很可能再招進來的還是庸才。如果開發經理不全棧，面試就要靠運氣了。反過來說，資歷好而水平差的程序員，也可以靠運氣進好公司的。
程序員為story估時間（story point）的時候，會不會虛報呢？如果認為scrum的打牌可以避免虛報的話，可以看看上面關于留面子的討論。即使把story的分配放在scrum打牌之后，經常大家心里已經知道哪個人做哪個story, 比如feature enhancement的story自然是這個feature之前的owner來做。打牌的人很容易會“做好人”傾向于多估時間。（再說一次，這不是中國特色，是人性）心理學有個有趣的關于撒謊的討論，撒謊的前提是1. 我知道 2.你不知道 3.我知道你不知道。如果經理在產品某項技術上是小白，就容易出現估時間虛報的問題——這樣的事情我親見過很多次了。全棧的經理自然不會被糊弄。
程序員經常會在一個技術問題上產生不同的意見，這很正常，技術上很多事情本來就要做取舍。這時候經常需要開發經理介入做決定。經理做合理的決定不但對項目重要，對隊員的個人感受也重要。決定不能是隨機的選A或選B, 需要有決定的依據。程序員往往都有點小驕傲，經理技術上捉襟見肘的時候，程序員就容易想，“你還不如我呢，憑什么做決定。”
開發經理需要做coding的工作么？我認為是需要的。 英語里有句諺語， He that would command must serve。至少也要做比較多code review的工作。評價隊員工作效果是開發經理的重要職責之一。技術不全面的經理經常依靠聽隊員自我評價（吹牛），數代碼行數等這種不靠譜的方式評價工作。錯誤地認同或不認同嚴重影響團隊氛圍。身先士卒的經理容易長期保持住團隊良好的氛圍。我沒有能力定義什么樣的氛圍才算是好的，起碼，我帶團隊時，成員互相之間心存善意。
澄清一下自己觀點：經理一定要全棧或技術精湛才能帶好團隊么？不是，但是很多管理的難題在全棧的經理眼里都不是問題， 比如上面提到的評價隊員工作。帶不好團隊就無法好好職業發展么? 不是， 我見過太多靠吹牛，人事等各種非技術技巧成功哄騙二線三線經理的了。管理的路越往上走，技術越不重要，而政治越重要。問題是，作為程序員或開發經理，你的目標是把項目做好還是獲得上級認可？我覺得這是職業價值觀最根本的分歧， 但， 不想討論。