針對前不久 mmdays 發表〈軟體公司該這樣做：領導你的員工、而非管理他們〉的文章，獨孤木發表文章質疑〈軟體公司怎麼會不需要管理員工？〉。讀完獨孤木的文章之後，讓同人也想在這篇文章提出我對領導或是管理軟體人才看法。
獨孤木在他的文章中提到：
事實上，好的人才需要管理。軟體開發的流程需要管理，軟體的品質需要管理，軟體的人才也需要管理。你不管，人才只會流失而已。失敗的管理，是人才流失最重要的原因之一。
這不光是領導而已。
打個比方好了，你現在有十個產品，你要怎麼樣為每個產品安排不同的策略？你要怎麼分布你的資源？你要怎麼樣設定你的優先次序？你要怎麼樣平衡資源？這通通都是管理的問題。
至於人才，我其實越來越對所謂的『好的人才最討厭人家管他們』。這句話相當質疑。
對我來說，真正好的人才最討厭的事情是，做無意義而無效率的事情。也就是說，最討厭的是浪費他們的時間。
他們不會在乎被管呀。如果這些管理的措施，可以讓他們的效率有效的提升，他們怎麼會討厭被管？事實上，他們很樂意被你管。前提是你要管理的好。你要重視重要的事情，而不是一些雞毛蒜皮的小事情。
很多人總是把管理認為就是有一個人在旁邊給你下指令，要你一動一動地去做，像是個班長一樣，這就叫管理。然後只要畫大餅，就是叫領導。事實上絕非如此吧。
如果你要帶領一個團隊，某個問題你不去解決，持續卡住團隊的進度，你也不想去管它，給予好的人才最明確的目標、最大的彈性、和爭取最多的資源，這樣就夠了嗎？
你要怎麼樣解決資源衝突的問題？你要怎麼樣平衡不同的目標？你怎麼樣跟各個不同的人溝通，而不是讓員工覺得，你只是見人說人話見鬼說鬼話？
對於目標明確、沒有複雜的人際互動、以及問題領域規模不大的軟體開發，同人認為獨孤木說的並沒有錯，只是他忽略軟體開發大部分的情況通常都不會那麼理想；有相當高的不確定性、複雜的人際互動、以及牽連廣泛的問題領域。因此軟體開發通常不是可以藉由投入資源，然後加以控制而得到預期的成果。因為明確的計劃並不可行的，再加上人際互動和問題領域的複雜性很難加以控制。因此，對於比較複雜的軟體開發而言，管理並不如想像中的簡單，尤其是存在領導與管理的弔詭。
獨孤木提到「領導是管理的一環」，同人不認為他的觀念有錯，但我認為他只說對了一半。在管理的情境中，的確領導是管理的一環。但換個方向來思考，在領導的情境當中，管理又何嘗不是領導的一環呢？不要忘了，管理需要有具體目標，管理者才能夠根據具體目標來制定計劃，落實執行並加以控制，以期達到計劃預計的成果。然而，促使他人訂立目標卻是不可能被管理的，它只能被領導，雖然在過程可能會需要管理的手段。
在解釋領導與管理的弔詭之前，讓我們先來看看在〈我看「算計」與「計算」的弔詭〉引用吳宗成教授的觀點：
「算計」（plot）與「計算」（calculation）的paradox：簡單的名詞，往往也都是複雜的動詞。「計算」可以當作是「算計」的處理元件，而「算計」可以視為是「計算」所建構出來的策略系統。失算的「算計」不是「計」，失計的「計算」也不是「算」。有時面對複雜的管理意涵，只要使用簡單的計算即可輕易下手而得到答案（mathematical model 屬之）。有時面對簡單的管理意涵，反而要採用盤根錯節的算計，必須繞一個大圈子，才能夠得到預期的結果（mental model 屬之）。天下本無事，只有庸人才會自擾之…
領導與管理的弔詭，就像算計與計算的弔詭一樣；領導相當於算計，而管理相當於計算。同人說過「計無算不成，算無計不通」；管理是「確認」把事情做正確，空有計劃而沒有精確推算，最後將不會得到正確的成果、領導則是「驗證」做了正確的事，空有推演的行動卻沒有落實現實可操作的計劃，最後將不會通達至正確的方向。
管理的重點在於分配資源，以期實現計畫；領導的重點在於發揮影響力，促成他人採取行動來縮小目的與現實的差距。領導是管理的一環，在實現計劃的過程需要令人採取適當的行動，用來讓期望的事情真的能夠發生。管理是領導的一環，在令人採取行動的過程則需要簡單可行的計劃，用來評估行動是否偏離方向。
把吳宗成教授提到觀念應用到領導與管理的弔詭，我們可以得到管理適用於解決數學模式的問題，領導適用於解決心智模式的問題。對於軟體開發而言，顯然有很多問題是管理無法解決的。因為軟體大部分需要解決的問題，多半不是結構化，而是半結構化與非結構化；管理可以輕易地解決結構化問題，但對於半結構化和非結構化問題，管理者不能期望用管理來竟全功，而更要把焦點放在領導上。
看來獨孤木誤會管理在領導過程當中的意涵，真正的領導並非不需要管理，而是需要注意不能因為增進管理的效能而降低軟體開發組織整體的多樣性。同人以為獨孤木正是因為忽略了多樣性，所以才會質疑「好的人才最討厭人家管他們」這句話。獨孤木對管理軟體人才的看法顯然是太一廂情願了，軟體人才討厭別人管他們，通常不是經過客觀分析的理性評量，而是基於個人價值觀的感情好惡。
從同人管理軟體人才的經驗顯示，很多時候管理者和軟體人才爭論管理措施，通常不是對不對、或是好不好的問題，而是軟體人才在個人主觀上就是不喜歡自主性受到控制。在觀念上，軟體人才理解管理措施並非不好，只是他習慣用自己的能力來解決問題，成就感才是對他工作的最大報償。
更明確地說，軟體人才不在乎被公司管，或是樂意被管，說是因為管理措施增加工作效率、或是公司管得好，重視重要的事情，這不見得是事實，而是軟體人才的個人感覺。但在一個具有成員多樣性的軟體開發組織中，每一個成員的感覺不見得會相同。當成員對管理措施感覺不好的時候，並不代表他的觀念錯誤，而只是理念不同。
管理措施的效率，只有在透過它做出成果之後才會有定論，而且往往事實證明，成員認為管理措施不妥的直覺是有道理的。但當管理者指責、排斥、以及壓抑理念不同的員工，那麼真正有想法的軟體人才將會逐漸遠離，團隊將會喪失解決問題需要的必要多樣性。
同人以前發表的文章曾經提過領導團隊的「必要多樣性法則」；領導者對團隊所做的行為，必須比整體行為的多樣性還要更靈活、更有彈性，否則他將難以掌控團隊。在許多軟體開發的過程，同人常看到管理者為了掌控團隊而降低團隊的多樣性，正如溫伯格在《溫伯格的軟體管理學：關照全局的管理作為（第3卷）》提到的：
當人們無法充分利用可能行動的多樣性，就會做出不一致（incongruently）的因應。根據必要多樣性法則，行為不一致的經理人可能無法控制自己想要控制的系統。
團隊的多樣性會讓言行不一致的管理者困擾，他們根本無法管理有創新思維的軟體人才，當然更不可能領導他們；問題不在於管理權威或手段，而在於不能充分利用運用多樣性。
有別於管理重視資源運用的效率，領導的意義在於賦予團隊力量，讓成員可以發揮專業與特長來工作，然後在工作的過程得到成長。真正的軟體人才可以透過領導而得到激勵，發揮他們的才華和創意來得到高品質的工作成果。告訴他們所負責工作的高層次目的，並且和他們共同討論需要完成的具體目標之後，促使他們自己思考來決定如何採取行動。領導軟體人才需要告訴他們做什麼，但不應該告訴他們如何做；尊重他們的決定、放手讓他們發揮做出成果，千萬不要為了掌控欲望而什麼事都要管。
因此，領導軟體人才並非不需要管理，而是它是難度較高的管理。這並不是因為它需要什麼高超的管理技術，而是需要讓軟體人才負起當責並賦權給他。其中的挑戰是領導者要懂得在該放手的時候放手、願意放手、並且真的能夠放手，它需要勇氣和膽識。而且要能夠在軟體人才和領導者之間維持力量的平衡，而不致發生反授權或是微管理；也就是員工不敢做決定，每件事都要請主管裁示，不然就是主管事必躬親，介入每件大小事的管理。做到真正的賦權才能讓管理有效地成為領導的一環。
如同喲哪桑學長在〈不是不管理，而是讓管理更好〉的提醒：
我們常說，Agile/Scrum team 是一個自我管理的組織，但自我管理不是不去理他，甚至放任他；自我管理常是團隊成員之間的 micro-management，而 agile manager 是要栽培團隊、要教導團隊、要矯正錯誤、要指引方向的。
如果你覺得，怎麼大家都不聽話？大家都不配合？大家都不受教？這問題可能不在員工，真正有問題的，往往是管理太糟糕，讓大家覺得，錯誤的管理在浪費大家的生命和青春，你該做的，不是不去管，而是檢討制度、檢討你自己，讓管理更好。
領導軟體人才不是不管理，而是管理正確的事情，讓每個軟體人才都能發揮比較優勢，讓整個軟體開發組織產生綜效。管理軟體人才與其告訴他們具體方案步驟，不如教導、栽培、矯正、和指引，促使他們去思考問題，找出正確的方向。《授權》這本書提到「3F 管理」：可以事前提供前饋（feedfordward）來指引方向、事後提供回饋（feedback）來矯正錯誤與缺失、並要完成跟催（follow through）以確認工作成果。其實不管是不是組成 Agile/Scrum team 或是應用任何軟體開發的方法論，領導軟體人才使他們有能力都是重要的事，但並不意味著沒有管理，而是管理要更有用。
So true. Honesty and everything rezcdnioeg.