經過一段時間的引導與練習，新人在學習上雖有進步，但可能還是一直卡住在某些關鍵點，而讓成長趨於緩慢或停滯的狀況。未能找出突破的方法，是不瞭解系統思考。
系統思考的精義，是為了讓我們學習看出我們在系統中運作的結構，從而可以利用訓練後熟練的技巧去改變現況。而其中最重要，最有用的洞察力方式，是能一再識破重複發生的結構型態，這便是去了解「系統基模」。
「又是它」
「又發生了，版本不sync的問題! 」
「又是搞混了call by value，call by reference所造成的Bug!」
在指導團隊成員進行專案任務時，時常會不斷遭遇到相同的問題，或者一直無法協助團隊成員突破，或找到一勞永逸的解決方法。
這是在個人上的成長上限，我們稱之為「瓶頸」。是系統基模中最常發生的一種。
初期的學習成長快速，是因為前幾篇所提的「不斷增強的回饋」所造成的結果，但時間久了，將會碰上抑制成長的調節環路；但有些管理者沒有意會到有抑制成長環路存在，還繼續使用「不斷增強的回饋」去推動團隊成員成長，兩相抵銷下，成長不進反退。這是不認識系統基模。
事實上，當遇到成長上限時，將是一個可以思索個人或組織停滯不前的大好時機。
就像現在，新同仁的成長遇到了瓶頸。但我似乎發現了抑制環路。
S君:「做SelectBoxes元件雖然學到滿多的，但有時候一直陷在相同的程式碼中，不斷地修改優化，有點Boring。」
我: 「SelectBoxes已經完成。你去看我怎麼優化的，下班時間有問題再問我。現在，你必須開始下一個任務，是一個完整的需求，我希望你從系統分析做起。」
I君:「這跟我之前工作的型態與步調完全不同，我當初就是想脫離舒適圈才到這裡。的確最近滿有壓力的，而且我常常一個問題卡住很久，K君也說一個問題卡超過一個小時就要趕快問人。但是有時候就覺得自己問的問題是不是其實就google的到，就這樣拖了很久…」(在思考迴路中打轉)
我: 「你練習的強度還不夠。從今天起你要花至少兩倍的時間，下班或假日我都有空，有任何想額外學習或練習的，可以先跟我約時間，我個別帶你做題目。另外，多參加讀書會、技術分享會、研討會，多認識一些優秀的前端工程師。我只想問你一件事情，你有沒有決心要當一個真正的前端工程師? 時常問自己，莫忘初衷。」
這也是在自我超越那篇中我所提到的，雖然不是正解，但跳出抑制迴路是一個立即解。
團隊需要強心針，以及真正的槓桿解；所謂槓桿解，就是先做最關鍵高效產出的事情，發揮強大的槓桿作用；但真正立即見效的，通常不是根本解。
以書中的例子來說。
就像談戀愛一樣。邂逅之初，感覺很棒，因此你們花更多的時間在一起，沉浸在兩情相悅的感覺中；結婚後，漸漸地開始發現彼此個性上的缺點，爭吵不斷；最後，你們只看見對方的短處。
這是婚姻的成長上限(淚)。
但你們都還想試著讓婚姻生活更好，於是偶而安排個小旅行，讓已經平淡的夫妻生活，稍微有一些漣漪，而產生立即恩愛的效果(大概維持一天XD)。然而這都不是真正的根本解，夫妻之間的三觀(世界觀、人生觀、價值觀)溝通，彼此願景是否達成共識，有沒有一起扶持走下去的決心，才是必須面對的真正解。
這放在企業更是如此。
Peter Senge認為，大多數企業的成長之所以停止，不是因為達到了真正的極限，而是因為增強環路產生快速的成長，但也在不知不覺中觸動了另一個抑制成長的調節環路，從而使成長減緩、停止，甚至下滑。這就是企業的成長上限。
遇到成長上限並不丟臉；可笑的是，很多企業遇到了抑制環路而不自知。
我們來看產品創新的成長上限環路。
大部分老闆認為只要增加研發工程師的人數，就能解決產品一直無法研發出來的問題，從上面的環路可以看的出來，資深工程師除了開發外，必須負責管理大型專案與培育新進人員的負擔，會是整個環路中最被抑制的重要因素。能夠撐下來超過兩年以上的資深工程人員，基本上對於公司是非常重要的資產，不應該輕易讓資深人員離職。一位資深工程人員的離職，將導致後續補進的工程師人數的數量，到真的能夠有研發產出的效果，中間會產生更大的時間滯延(因為沒有人帶後續補進的工程師)。
在《人月神話》中，精準的提到，工作完成所需的月數，會因人員的增加而遞減，這是因為軟體專案是交互關係複雜的工作，需要大量的溝通成本，因此人數的增加，容易因溝通問題，反而無法達到預期的效果。Again，軟體開發是以人為主軸的一種活動。
前前篇也說到，只有個人學習，組織才能跟著學習。也就是說，只有個人成長，組織才能跟著成長。
突破成長上限，是每個人一輩子都要不斷去做的課題。
小結一下這十天來，我們學習到教練式引導的幾項SOP:
iThome鐵人賽
看影片追技術