做為一個管理技術團隊的基層主管，到底要不要寫程式呢？
基本假設
我們先假設，這篇文章提到的技術主管是：5-7 人 web 開發團隊的負責人，也就是初階、基層的技術主管。
相信有不少這樣的技術主管都是技術背景出身的，可能是最會寫程式的那個、也可能是最懂技術架構的那個，工作一陣子後，公司認為他表現得不錯，被拔擢成為初階主管。
（非技術出身的主管不在這篇文章的討論範圍，因為不懂技術的技術主管，沒有寫不寫程式的問題XD）
技術主管的職責
在討論技術主管要不要寫程式之前，先來聊聊主管的工作是什麼。大家可能會覺得主管的工作就是出一張嘴，但其實公司對於這樣的角色，最基本的期待是：確保團隊的工作準時完成，並且品質必須符合要求。
為了完成這項工作，主管必須：
對上：確認工作需求、交代工作進度、尋求資源及協助
對下：分配資源及工作、驗收員工產出、照顧員工身心狀態(?
所以其實真正講起來，為了確保團隊產出符合預期，雜七雜八的事情很多，導致很多時候看起來真的是只有出一張嘴XD
主管花太多時間寫程式會有什麼問題
有人會認為，確保團隊產出有很多種方式，主管跳下去幫忙寫程式也是其中一種，這樣會有什麼問題嗎？其實長期下來，對自己跟對團隊，都會造成問題。
對自己而言，寫程式容易佔據過多的時間，多到排擠應該用來管理的時間。可怕的事情是，一但開始寫程式，很多主管都不會注意到，自己已經被寫程式佔據太多時間了。在不自覺的情況下，蠟燭兩頭燒，程式跟管理都做不好，總有一天會出事。
對團隊而言，一旦主管被寫程式佔據過多時間，管理開始出問題之後，開發過程就會開始不流暢，時程就會開始 delay，品質也跟著下降。
更進一步講，如果主管把自己算為專案開發的人力的話，就會覺得再怎麼樣，主管自己都可以出來收拾殘局，那就有可能隨便答應上面的人提出來的需求，工作量評估開始失準，使得團隊必須開始面對不合理的時程。
而另一個隱憂是，因為主管自己親自開發，很有可能對團隊使用的技術比手畫腳，但當上主管後，大部分時間都在開會，跟處理雜事，其實沒有那麼多心思可以花在研究程式寫法或是新技術，因此通常會堅持使用自己比較熟悉或是自己認為比較好的寫法、技術，就有可能拖累技術團隊的開發品質及發展。
所以主管一行程式都不該寫嗎？
也不能這樣說，我認為主管還是應該要寫一些程式，但這些程式是主管利用自己的時間，為了學習新知或跟上技術潮流而寫的，不應該是作為工作上實際的產出。
什麼意思？其實這邊要刻意區分寫程式跟開發，單純的寫程式(或稱為學習)跟開發是不同的，開發雖然也是寫程式，但通常是為了工作的需求，存在各種資源壓力。
因此主管如果真的想要自己下去開發，那就必須要考慮清楚，非不得已不要自己寫。
例如：
- 半夜系統突然壞掉，找不到人幫忙修。
- 有一個古老的系統突然出現bug，眼下只有主管懂這個系統。
- 好死不死整個團隊都是菜鳥，沒有資深人員可以幫忙撰寫核心的功能。
- 諸如此類，又急又重要，而且暫時找不到其他人替代的。
總歸一句，重點是資源的分配。
主管作為公司的資源，應該就要把大部分的心思放在管理上。尤其技術主管，因為了解技術，應該利用這樣的背景，去更有效的管理技術團隊。
主管擅自讓自己寫程式，其實是一種資源的浪費，而且其實除了要不要寫程式的議題以外，其他跟技術或開發相關的事情，主管也都應該要站在一個綜觀團隊全局的角度來看，不應該去跟團隊成員搶工作，如果有人做得比主管更好，那就讓他做，如果他現在做得還不夠好，那就想辦法讓他做得更好。
例如：
- 如果團隊中已經有很多很會寫程式的工程師了，那就不要再去跟他搶，把寫程式的工作讓給他們。
- 如果團隊中已經有人會做系統設計了，那就把這件事情讓給他。
- 如果團隊中已經有人會帶新人了，那就把這件事情讓給他。
- 如果覺得有人有潛力，那就安排更進階的工作給他。
結論
回到主題，所以主管要不要寫程式？
我的答案是，不要讓自己變成團隊開發的主力，而忽略的團隊的管理，但是要透過寫程式的方式學習新知，維持對程式的感覺。
讓資源做有效率的分配，讓團隊有最大的產出，自己跳下去寫程式也不是不行，但絕對不會是第一個選擇。
另外也不要忘記，管理也是一門專業，也是需要被學習的。
延伸
更多《職場甘苦談》系列文章