By: Niel Nickolaisen
.
命令與控制型文化
要帶領一群工程師最簡單的方式便是採取命令與控制的方式。從小學的時候開始，我們就被教導如果你做了幹部，就是要學會如何下命令讓同學們去完成工作。卻很少有導師會主動的教學生要如何的讓團隊負起責任來，自行完成工作，把該做的事做好，而不是只把自己該做的事做好。大家好像都忘了，各級幹部也是團隊選出來的，其實與團隊共進退的領導模式才是王道。因此我們從小就習慣於主管就是要負責發號司令的人，做主管就是學會如何發號司令，而且誤以為主管就該什麼都懂，而忽略了真正做事的是我們自己，而做得好壞就看自己怎麼做了，主管只是要負最後的責任罷了。
Niel Nickolaisen 覺得應該把信任與責任攤開來談，用視覺化的方式，才能讓大家更清楚的看到這種關係。因此運用了二維的圖示，縱軸(信任)是領導或業務流程對團隊或員工的信任度，越高就是主管與團隊之間的信任度越高，越低就是主管採用命令式的控制模式越大。橫軸(責任)是團隊或個人對工作所做出的承諾也就是自己認為對事情(工作/任務)的責任感與所有權。敏捷的團隊對任務工作的表現只有在團隊完全承諾下來時，透過盡心盡責的情境下才會擁有活力與創新的表現。上面那張圖太理想化了，下面這張圖比較像真實的世界，信任與責任往往都不會那麼明確的，尤其是四個象限的邊界應該總是模糊的，加上的虛線部分則是過去自己所顧問的團隊所必經的過程路徑(當然有很多團隊一直無法到達活力與創新的區塊，我們不能把責任完全歸咎於主管，但他們其實可以做得更好些，這也是本文的目的)。Niel 的視野並未侷限在專案開發，而是普遍指向主管與團隊之間的領導問題，這裡我的解釋則狹隘的偏向專案開發上。
- █失敗(藍色) : 指的是長官完全信任團隊，但團隊對自己的工作並沒有哪麼在意。這種現象通常是團隊對自己所開發的東西沒有認同感所致(對自己該做什麼一旦不夠了解時，便會如此)，接到任務後認為成敗是主管或是公司的事，我只是奉命行事而已(工程師認為我已經盡力而為了)，在這種情境下專案自然會有較高的失敗率，即便成功了效果也相當的侷限，而在與其他團隊協作時便常常會有穀倉效應的Silo現象出現。此時要從團隊培養對需求真正的認同感開始(在陳述需求時運用影響地圖Impact Mapping的工具可能是一種好的方法)。
- █命令與控制(黃色) : 長官由於擔心團隊無法自行完成任務，因此將所有權收回，放棄讓團隊自我組織，回到一個口令一個動作傳統的waterfall式的命令與控制狀態，等於正式宣告敏捷轉型失敗。如果團隊依然採用迭代式的開發方式，便是所謂的假敏捷(此時；由每日的站立會議就能觀察出來)，此時除了開發效能不彰之外還會造成偏高的離職現象。常見的情境是公司聘請的敏捷顧問離開之後，接手的主管採用了自己熟悉的命令與控制模式來帶領團隊，便會將敏捷顧問所辛苦建立的自組織團隊打回原形。這是一種低信任與低責任感的工作環境，優秀的工程師當然不會有所眷戀而輕易求去。
- █衝突(紅色) : 低信任感與願意負責的團隊。團隊具有高度的責任感但容易與長官之間有不同的意見而常常引起爭執(衝突)的現象，這是自組織團隊的必經過程。一種現象便是Scrum Master 們經常請主管退後一步的原因，就是不希望團隊與主管之間產生衝突，並運用團隊逐漸加強的責任感，企圖用團隊的好表現來增加主管的信任感。當發生這種情境的時候，一般都不會真的產生劇烈的衝突現象，取而代之的是彼此偶而會互潑冷水或扯後腿的現象，這是彼此之間缺乏信任感所致(當主管有很多措施都沒跟下屬做解釋或進行充分溝通就自行發布的時候，就容易產生這種類似衝突的現象)，起因是彼此不相信對方可以把工作做好，又覺得對方不夠敬業，因此即便團隊開發的很辛苦卻成效始終不彰。是一種團隊逐漸產生自組織的過渡期間，此時主管的誠意表現將決定團隊向上產生活力與頻增創意所能達到的境界。
- █活力與創新(綠色) : 命令與控制的現象完全消失，團隊以自組織的方式工作，只要在目標夠明確之下，團隊總是清楚自己應該怎麼做，主管也能充分信任團隊，團隊以致力於交付滿足客戶需求的價值為主，好的工作氛圍讓創意與活力頻頻出現，這個時候團隊將擁有最高的效能。表徵是: 工程師即便收到好的挖角Offer也不太會想要離開團隊。
.
邊緣模糊化了的信任與責任模型
圖上的虛線路徑代表了團隊在組織環境下的表現，許多互動的因素會左右誠信與責任模式，基本上它是動態、模糊而難以維持的，我們常說在現今這個 VUCA 的時代下，一切都在變，到底要如何來面對呢? 敏捷的文化認為我們可以運用迭代的方式來面對模糊性(Ambiguous)，用行動與學習(Action Learning)來提升明性確性，至於不穩定性(Volatile) 則可以運用目標建結果OKR，以設定明確目標與關鍵結果來對應，至於複雜性(Complex) 才是我們帶領團隊時最難面對的問題，必須先建立起領導與團隊之間的誠信，然後在團隊能夠體會到責任與權利的義務時，再用自組織來克服內部的複雜性，使團隊產生足夠的自適應性來應對外部的複雜環境。
權力與自由的可貴
上圖中，左下角的命令與控制象限看起來是團隊效能處於最低的狀態要盡快脫離，應該用力實施各種改善措施來促使他做轉變，但 Niel 提醒我們，適當的控制模式可以讓團隊處於較高的穩定性狀態(團隊要處在穩定的狀態下，才容易轉型成功)，因此當我們想讓團隊進化到右上象限時，適當的以命令的控制方式來進行操作反而最為有效，因為減少自由與權利反而會讓人們更去珍惜它。
.
工程師不夠敬業
在職場上普遍存在著主管們認為工程師沒有我敬業的想法。因為團隊總是在遇到棘手的問題時才向主管請救，這種情形很容易讓主管誤以為團隊缺乏責任感，其實大部分的時候，團隊只是抱著尊重大於解決問題的意味向長官請救，團隊也知道大可開個會一起思考如何解題就搞定了，但資深的成員總覺得此時應該尊重長官才是，畢竟如果我們搞砸了到頭來倒楣的人可是他。反之；
老闆應該都知道組織現在該做什麼
這種相互誤解的場景其實是溝通不良所造成的。員工總以為老闆應該隨時都知道組織現在該做什麼才對，但其實Toyota的精實文化很早就告訴我們了，現場的領班才是最清楚狀況的人，所以大部分的抉擇應該是當事人才最適合做決定的(前提當然是你要夠專業)，而老闆所做的決定往往是較少的那一部分。反過來看；中階的主管自以為我什麼都懂，我知道該做些什麼。這才是最危險的事，信心滿滿是好事，但真相是只有第一線的工程師才知道所有的細節，若只憑過去的經驗作決定其實是一種錯誤，而他該做的則是發揮身為一個領導者該有的作用才是，而不是自以為是地借助以往的經驗來下指導棋。
.
解決誤解的方式，是建立一種主管與團隊之間的互信模式。
.
信任得來不易
主管與團隊之間的信任得來不易，尤其是在職場上更加困難，因為人們總是會戴著不同的面具去上班，深怕全然的坦承會帶來沒有必要的副作用。朋友之間也是如此，通常要一直到有了足夠的互動之後，才可能慢慢的建立彼此之間的互信。與主管之間的信任則是建立在誠意上頭，這是因為大部分的主管很難有機會和下屬產生互動，因此主管所展現的誠意則可取而代之，成為建立互信的基礎，雖然沒有友誼做支撐但依靠組織架構，也足以獲取某種程度上的信任了。子曰：「人而無信，不知其可也。」指的就是人若不講求信用，在社會上就無立足之地，什麼事情也做不成了。提供一個工具協助大家思考，那就是Niel Nickolaisen所發明的信任與責任模型(Trust – Ownership)。
.
責任的內涵；簡單的說就是一個人有沒有擔當
.
結語
敏捷轉型實質上就是組織文化與流程的改變。主管與團隊之間的誠信與責任劃分描繪出了團隊成長的路徑。敏捷宣言與原則則指導了流程上能夠符合敏捷的規範。如果想要擁有一個高效的開發團隊嗎? 就得先弄好領導與團隊之間的信任與責任關係。 Niel Nickolaisen 的信任與責任模型 Trust–Ownership，目的是；提供一個用來提升團隊效率的分析工具，進而避免本來是團隊責任範圍內的工作，反倒跑到主管身上去了，造成主管累的不行而團隊又被責怪沒有盡力。這個工具是屬於主管或領導階層的工具。主事者需要觀察目前團隊的現狀，試著評估自己對團隊的信任度與團隊在接收任務後所表現出來的負責程度，是落在哪一個區間，進而思考自己該採取什麼樣的作為來改善它。一本參考書《敏捷文化》The Agile Culture是 Pollyanna Pixton、Paul Gibson與 Niel Nickolaisen 2015 所合著，全書的基礎就是架構在「信任與責任模型」上頭 (youtube 上 作者的親自說明如下)。
.
交付工作是誠信的入口，務必先詢問再要求承諾，
強制交付日期的專案，則是誠信最好的破壞者。
.
