組織設計的兩難:目標導向還是功能導向?
在團隊逐漸成長的過程中,需要解決的問題、面對的挑戰都會有所不同,因此,團隊的目標、團隊成員的組成與其運作方式也會需要作出調整,才能適切地面對各種挑戰。
當一個組織規模提昇之後,就一定會面臨到要如何設計組織這個讓人頭痛的問題。舉例來說,我的公司 Fourdesire 在創業初期時,三個創辦人就是一個產品團隊,我們一手包辦了設計、開發、行銷與銷售等等問題。但隨著公司發展,現在公司有了四個產品分別對應不同需求的消費者,在設計組織與團隊架構的時候,應該要讓每個產品都有自己的完整產品團隊,來解決市場的需求?還是應該要讓全部產品的設計都由設計總監一手掌握,來提高設計品值與產品一致性?
這個問題實在很難!有著個別目標的產品團隊聽起來很有道理,畢竟他們可以靈活地為各自產品的使用者打造獨特的功能,快速切入市場以取得獲利;但若能夠讓設計總監一手掌握全部的產品設計,則可以有效的提高產品品牌一致性,讓品牌調性更容易被使用者認同。
組織的組成
組織就像一個複雜系統,一個組織往往由多團隊組成、而一團隊也是由多個成員組成。在系統思想家唐內拉‧梅多斯(Donella H. Meadows)所著的《系統思考》中,提到一個複雜系統的組成,包括三個主要的成分:要素(Element)、系統連結(Interconnection)、目的(Purpose)[1]。舉例來說,若我們把一個團隊看為一個系統,這個系統組成的要素是團隊成員,而他們如何合作、如何傳遞資訊等互動方式則是系統連結,這些都是會影響團隊如何運作的關鍵。但對一個系統影響最大的,的往往是其目的(Purpose)——想像一個足球隊,同樣的團隊組成,他們的目的可以是「贏得比賽」、也可以是「在慶功宴上吃個爽」。
讓我們再放大一點看整個組織,若我們把整個組織當成一個系統。此時每個團隊就像是系統中的要素、團隊彼此之間的合作方式則是系統連結、組織目標則是這個系統的目的。設立組織目標很重要,能夠讓整個組織了解他們前進的方向。不過你可能也注意到「團隊組成方式與目的」也很重要,因為他們同時扮演了組織中「系統連結」與團隊中「目的」兩項角色。
天秤的兩端:目標導向與功能導向
我們可以把有個別目標,目的為解決特定問題以達成特定目標的團隊,叫做「目標導向團隊(Goal-Oriented Team)。把依照特定能力、專業與技術,目的為了整合專業資源以解決特定專業問題的團隊,叫做「功能導向團隊(Function-Oriented Team)」。
英特爾(Intel)的前執行長葛洛夫在他的著作《葛洛夫給經理人的第一堂課》中,把這個問題解析得很清楚:「經理人不斷的在這兩種極端的組織架構間尋找最佳組合。[2]」。別忘了團隊也是組成公司的重要因素之一,當整體組織的目標改變時,團隊結構也應該要一起改變,來應對當下的目標。若組織正在市場中快速擴張,也許分權式的個別產品團隊作戰方式,會讓他們在個別市場中更靈活——就像麥當勞在各地有不同的漢堡;但若組織正在整合資源已深造技術或品牌價值,功能導向團隊則能快速的整合資源,發揮邊際效應。
在試著排列組合你的組織架構之前,我們可以先來看看「目標導向團隊」和「功能導向團隊」各有什麼優缺點?
目標導向團隊
目的:解決特定問題以達成特定目標
優點:
- 清楚地瞭解目標與問題,並能夠靈活且快速的解決。這是目標導向團隊最大的好處,靈活且容易面對市場,市場一但發生問題,團隊就可以馬上調整節奏並修正方向。
- 團隊成員更了解自己在做什麼——比起單純設計介面或寫程式——他們現在更清楚自己解決的市場問題為何。
- 跨領域的合作有助於創意性的思考,更容易整合跨領域資源。在產品會議中,設計師可以從工程師的簡報中了解工程的難關與挑戰,並可能從設計的角度給予不同的想法與建議,反之亦然。往往問題可以從不同領域的專業人士中獲得有趣的視角與見解。
缺點:
- 由於團隊有各自的目標,彼此受彼此影響程度低,資訊也同時不容易分享。舉例來說,一個在 A 團隊執行非常成功的設計提案,需要更多的資訊傳遞才有辦法被 B 團隊所採用。
- 團隊成員無法再彼此身上學習——這一點在超小型目標團隊中非常明顯。舉例來說,在一個只有一個工程師、一個設計師、再加一個產品經理的小團隊,設計師雖然可以從工程師身上學到不同的見解(這一點其實很重要也算優點,設計師可以學會工程師如何看待設計,反之亦然。),但卻很難從團隊成員身上學到專業技能或針對解決方案進行討論。
功能導向團隊
目的:整合專業資源以解決特定專業問題
優點:
- 同儕之間可以快速地交換意見、彼此學習並精進。這讓有成長思維的團隊成員能夠快速從資深的同事身上學習,且相同領域的同事較容易建立專業話題,進而深入討論並學習成長。
- 有效的利用經濟規模,減少重造輪子的額外成本,增加整體運作效能。
- 對於該功能領域的資源分配能夠更確實。舉例來說,某個專案因為臨時需求而需要更多工程師支援,功能導向團隊能夠迅速的調派工程師前往協助。
缺點:
- 跨領域的資源較難整合,團隊容易落入僅有自己專業領域才能解決問題的陷阱,而忘記可以與其他領域人才合作。若一個專案需要跨領域的人員一同合作才能完成,可能會需要建立跨領域小組。
- 對目標的理解只有部分。因為目標被分拆到功能團隊往往已經只剩下功能團隊能夠負責完成的部分,團隊成員因此比較難了解目標的全局。舉例來說:「改善伺服器效能」這個目標的上層目標可能是「提高產品體驗」而增加使用者體驗、也有可能是為了「縮減伺服器費用」,而這兩者需要採取的作法可能大不相同。
保持對目標的敏銳與調整的彈性
無論是目標導向團隊或是功能導向團隊,各有其優缺點。事實上,如同葛洛夫所言,一個組織架構的設計必然是混合這兩種模式中的其中一個混合結果。在這個混合兩者的組織架構中,目標導向團隊會靈活地去解決棘手的商業問題、而功能導向團隊則能夠有效利用企業資源創造價值。
但好了!問題來了。那我到底要如何配置團隊才能達到需求呢?也許我們可以考慮以下幾點:
- 團隊目前面對的挑戰,需要快速地應對市場需求嗎?如果這個答案是「是」,那麼也許你的組織中會需要幾個給定特定目標的目標導向團隊,賦予他們足夠的權力來解決這個問題——在我的例子中,目標導向的「產品團隊」就是為了這個目標而設計的,如此一來,產品團隊才能快速聆聽消費者意見並作出反應。
- 團隊需要深耕某個專業領域取得成就,才能在市場上取得領先地位嗎?也許你應該要讓特定領域的人才能夠多交流,並且給予他們深掘該領域的時間與權力。讓他們能夠充份在同儕間學習討論,並充分集中相關資源來發揮最大潛能——讓某些工程師能夠花時間去鑽研新技術,並確保他們有充分的時間交流,並整合資源。我們透過這種方式打造了跨產品的單一登入系統,讓產品團隊不再需要擔心個別產品的帳號管理問題。
- 團隊目前面對的目標,必須要由多種領域的專業人才通力合作才能完成嗎?有很多特殊任務必須要集結跨領域的專業人才合作才能完成,這些任務可能是暫時性的、也可能是比較長期的任務。舉例來說,成立一個新的研究小組,團隊組成來自宮城、行銷、設計等專業人員,給予一個有趣的發想主題,然後看看他們能夠激盪出什麼火花?
無論你如何配置團隊結構,你都必須要考慮下列幾點:
- 考慮人才的學習與訓練管道——團隊成員遇到專業問題時可以請教誰?
- 跨領域T型人才的養成,未來越來越多問題會需要跨領域人才才能解決。異花授粉者[3]這種特殊人才在團隊中的配置也許在未來會變得越來越重要。(關於何謂「異花授粉者」,可參考《決定未來的10種人》中有詳細的說明。)
- 你要如何讓高階目標(例如公司目標)清楚的傳遞給每個團隊成員?讓他們知道更高層目標、甚至是公司目標在追逐的是?
- 遇到緊急狀況時,人才如何重新調度與配置?
考慮多維度結構
無論你的團隊是目標導向或功能導向為基礎,要能夠同時解決上述問題,往往不能只從一個二維的平面去思考組織架構,而是可以透過多重維度思維去思考如何讓成員們能夠更靈活的解決問題。
舉例來說,一個隸屬於某個目標團隊的工程師,他可能也是另一個功能團隊的函式庫小組成員。也許是他對於推動組織函式庫的建立很有熱誠、也許是他對這門專業特別專精而總是可以回答他人詢問的問題,但這樣的雙重身分有助於同時解決兩個不同問題。相對的,另一個在功能團隊遇到函示庫問題的工程師,會知道他可以來請益小組成員,已解決他在原始團隊中面臨的問題。
值得注意的是,每個人的注意力跟精神都是有限的。一個人很難可以同時兼任多重維度的角色。通常選定一個主要角色與一個次要角色會是比較好的選擇,比重可以是 80:20,但建議不要超過 70:30,過於平均的比重會讓人不知道目標要如何拿捏與掌握。
多維度結構提供了一個組織針對靈活與專業兩個看似衝突的問題一個有趣的解決方法。但實際運作起來可能會需要每個團隊成員都對自身的專業能力、團隊需求、溝通方式與組織文化等有更深刻的理解,才有辦法逐漸運作順暢——「嘿!我是某專案的資深工程師!不過我每週安排四個小時來協助其他專案的工程師解決演算法問題!」——聽起來挺酷的,不是嗎?
組織的調整總是會暫時讓人不安,畢竟沒有人喜歡動盪的時刻。但隨著組織成長、目標或市場改變,適當的調整是必然會經歷的成長過程。畢竟世界不停的在進步,用昨天的方法面對明天的挑戰是難以成功的方法。
沿著系統思考的脈絡,小心確認目標,仔細思考互動方式,並適當配置資源並做好溝通工作,保持對目標的敏銳與組織調整的彈性,才是面對未知挑戰戰的解決之道。
參考資料
- 系統思考 / Thinking in Systems: A Primer, Donella H. Meadows, 2016
- 葛洛夫給經理人的第一課 / High Output Management, Andrew S. Grove. 2019
- 決定未來的10種人 / The Ten Faces of Innovation, Tom Kelly, 2008