作為主管，帶領引導團隊朝組織期待的方向前進有很多種方式。其中，「教練式引導」針對特定團隊成員行為改善的其中一種方式。
主管對於團隊成員的引導方式大概有四大方向：教練coaching, 導師mentoring, 領導leading 與管理management。在軟體團隊中，領導與管理是主管一定會做的，而教練coach與導師mentor就會視團隊的實際情況而定。
管理management：簡單的說，是直接或間接以組織所賦予的權力，以具體的方法，要求成員達到結果或者某種行為。舉例來說：「某甲，明天早上十點請到會議室去和某乙討論某專案」就是個具體的管理作為
領導leading：簡單的說，以自己的行為加上組織賦予的權利，以身作則的達到團隊合作的結果。舉例來說：「某甲，我明天早上十點會到會議室去和某乙討論專案，一起和我去吧」
導師mentor：一般來說是比較有經驗的成員，在執行自身的任務的時候，順便分享給相對沒經驗的成員。也許會回答問題，也可能教導做法，或者也分享經驗。通常由主管指派資深成員做mentor，但主管也有可能自己作為mentor角色。導師通常會比學生更厲害或更有實質經驗
教練coaching：以「口說」或者「間接」的方式，激勵或指引成員達到具體的結果。這具體的結果，幾乎100%是有成員直接完成。教練不一定比學生更厲害或更有實質經驗，但通常會更有「口說教學」經驗。例如在世界排名頂尖的職業網球選手，都有雇用教練陪伴指引戰術與練球，但那些教練過去甚至不見得是職業網球選手。
角色區分有時候並不那麼重要。例如管理與領導常常是混合進行，而在軟體團隊中mentoring coaching 當然也常混用。更常發生的例子是，主管指派一個導師mentor給新進同仁時，實際上常常混合了leading/mentoring/coaching。混合並不是壞事情，但如果資深同事，可以透過區別自己的角色，進而使用不同的工具達到目的，那效果會更好！
這篇文章僅只專注於教練式引導。
教練式引導的基本方式: GROW
最最基本的教練式引導模型是Grow，它有四個循環的階段：
GROW: Goal, Reality, Options, Will (what)
目標Goal：
教練和學生要決定一個具體的目標。這個目標可以是組織需要的目標，也可以是學生個人的目標。目標必須是可清楚辨別結果的。例如，網球選手想在四大公開賽進入前四強。在學生剛加入團隊時，可能會訂出目標是「了解現在的系統」，這其實並非清楚可辨別的結果，教練應該和學生花時間，討論具體的結果，例如「根據現在bug清單，修好一個bug並送出Pull Request之後通過團隊所有其他成員的code review並且合併到master branch」。雖然一次可以訂多個目標，但建議還是少量目標為主。
現況Reality：
教練和學生列出和具體目標相關的現況。例如網球選手此時世界排名是200，過去平均多久打一次正式比賽，平均練習時間等等。
以軟體開發團隊來說，現況可能是剛剛加入團隊，才剛剛有git的權限，過去的文件還沒看完，對某些專業領域還不了解，還不知道哪些問題應該問哪些人等等。
現況的描述是相當私人化，對於某些人來說可能還先牽涉到部分自我敏感的資訊，尤其是自己弱點。在還沒有互信的時候，此階段執行要特別謹慎。
執行選項options
了解現況之後，教練就要和學生討論選擇做法。這些做法當然是「學生」要去做的。以網球教練為例，可能會建立心肺功能的健身菜單，也可能會安排練習賽，也可能會為了強化發球。通常可執行的選項會多過可用的時間。當然就要和學生討論哪些選項應該要做，那些不做。
軟體開發團隊也會設定這些選項，但更著重要選項的優先順序，也就是哪些要先做，那些之後再做。
意願will/what:
監控執行，特別是監控執行意願。一個剛加入團隊的新鮮人，初期在意願上通常不是太大問題。如果已經在社會打滾多年，因為換工作的關係加入一個新團隊，作為教練或主管，就要稍微留意一下是否有意願或者動機的喪失。
這GROW是個循環，教練不見得一定要告訴學生這個模型，如果可以說明清楚是最好。根據實際情況，循環的長度會有不同，可是軟體開發團隊中的教練應該盡量控制在1~2週之間，切勿太長。
教練的功能
GROW模型優點是相當簡單，容易理解。缺點是教練實質功能在這個模型比較隱晦。在執行此模型時，也可參考以下重要功能：
建立互信
建立互信是教練最最重要的功能，沒有互信的情況下，很難達到教練完全的功能。
軟體開發工作上的互信應該會比運動型的教練容易一些，只要執行以下三點：(a)自己保持清楚明確的溝通 (b)永遠花時間跟確保完整傾聽對方 (c) 固定時間回饋 通常就能有一定的互信
因材施教
在軟體開發團隊中，教練vs學生，通常是一對一。而每個學生的情況截然不同，因材施教是顯而易見要達到的。因材施教在非技術的領域比較難，最好的方式可能還是縮短GROW的循環時間，如此可以在短的時間修正互相之間的不了解。
建立安全網
運動類型的教練都有其專業能力，可以判斷目前學生是要突破肌耐力極限，還是快要受傷應該休息。甚至某些運動項目，例如體操，就還真的有實際上的"安全網"，因為受重大傷害絕對不會對目標有幫助。
就軟體開發團隊來說，安全網其實很重要，但相當隱晦。例如對於相對沒有工作經驗的人，教練應該在「現況討論」時，列出更細節的項目，例如估計時間的時候要估計完整的時間，包含unit test跟撰寫文件的時間。這些實質細節項目，其實會讓新鮮人更清楚並且有信心的做事。
安全網也有可能是透過工具，先行體驗犯錯，而減少日後在真實情況下犯錯的機會。例如，即便團隊沒有要求，教練也可以和學生討論使用某些靜態程式碼工具，在送出PR review先自己找看看有沒有顯而易見的問題。
建立安全網在某些時候是個極為重要的任務。一個教練要謹記，教練成功的原因，是因為學生成功了！不會有一種學生失敗了但是教練成功了的情況。因此安全網是個避免災難式失敗的保險方式。
鼓勵人心
真誠的鼓勵其實對大家都有幫助。尤其是在完成目標之後。因此目標的設定，最好是許多短期目標構成長期目標。舉例來說，如果網球選手的目標是進入四大賽的前四強，但目前世界排名還200，短期目標可能是先在最近的幾次三級比賽獲得冠軍。
軟體專案的目標甚至可以是逐日設定，所以鼓勵也可以逐日發生。所以當教練必然要花一些時間陪著學生。
時間分配
軟體團隊身兼教練的人，通常不會和運動類型的教練一樣是全職的工作。每個人在團隊都應該要有產出，兼職的教練也不例外，所以時間分配在學生的身上恐怕要特別注意。
最基本是要和主管討論時間分配。如果要不影響工作進度，一般的原則，每天15~20分鐘，再加上偶爾中午一起吃飯的時間就應該是上限。
這裡的15~20分鐘，指的當然是學生和教練一起執行檢討GROW模型的時間，並不包含假設教練身兼導師一起和學生工作的情況。
尋找外援
以有世界排名網球選手來說，年紀稍長的教練幾乎不可能跟他打練習賽，所以教練可能會透過自己的人脈（例如同個經紀公司）找到同等級的職業選手來打友誼賽。而更厲害的教練可以說服更高一級的選手來和自己的選手練習。
就軟體開發團隊來說，教練有可能比學生在專業領域還要厲害很多。然而也有可能由於教練資歷太深，反而對最近幾年的新的開發工具並不了解，教練也可以直接安排其他成員專門對某工具對學生直接教學。
其他教練模型
市面還是有很多不同的教練課程與書籍闡述不同的工具和模型。可以參考這裏
