我任職於蘋果時，公司的營業額為四千億美元（按：約新臺幣十三兆元），員工達十六萬人，但這家大型公司卻像一個事業體一樣行動。一般公司會根據產品類別（事業體）分成不同的職能團隊，但蘋果不一樣，執行長之下又分為設計、工程、行銷、製造、零售等，是以職能分類的組織（請參考表1）。
前者的情況是，每個事業體各自像獨立的公司那樣經營，統計各事業體的營業額、利潤及虧損。從執行長的立場來看，依照事業體來經營，指派責任歸屬，或許更有利於經營龐大組織。
相反地，蘋果由不同職能的專家組成，分為「業務工程師、經理、資深經理、總監、資深總監、副總裁、首席副總裁」，共同負責公司的銷售、利潤和損失。
比方說，我所屬的可靠度「組織」（組織會整合特定功能，組織底下再按產品類別分為許多團隊）負責評估蘋果產品核心零件的可靠度（除了iPhone、Apple Watch、MacBook，還包含手機殼、錶帶、充電插頭）──任何零件、產品或系統等在任何條件下都不會故障，而是能在一定時間內維持最初的品質及性能的特徵評估──並分析其標準和故障等；因此，對於職能式專家組織來說，可靠度組織累積的各種知識、經驗、資訊和解決問題能力，是創新方面非常重要的資產。
在這之中，我負責iPhone顯示器的可靠度評估，每週都會開會，在這種週會上，負責人會以各種可靠度評估經驗值為基礎，提出尖銳的問題和想法。得益於此，大部分問題的線索都來自可靠度組織，舉例來說：
「這個問題可以請教MacBook團隊的詹姆斯，他以前用新的實驗方法解決了可靠度評估中可能出現的電線腐蝕問題，應該會對這個問題有幫助。」
「其他產品也有類似的故障問題，原因是當時製程中出現的特定雜質。你們為什麼沒有對雜質做進一步的化學分析？」
「要以統計分析來預測實際產品的不良率才能得出結論。製造組的傑森有類似的統計分析資料，請向他請教後，在本週內報告可預測的不良率。」
「請打聽看看，使用同樣供應商零件的其他產品，是否也出現類似的結果。」
蘋果開發全方位產品已經有很長一段時間，過程中累積的經驗和專業知識，形成職能式專家組織創新的基礎。
解決Apple Watch問題的經驗，有助於開發iPhone；開發MacBook時取得的試錯結果，帶給開發Apple Watch的工程師靈感……這種影響力不僅出現在可靠度組織，在首席副總裁旗下的設計、行銷、工程、製造等職能式專家組織中，都出現同樣的動力。
蘋果並不是打從一開始就以職能式組織運作，將事業體系依職能重新劃分的不是別人，正是賈伯斯本人。一九九七年，他以執行長身分回歸蘋果時（按：賈伯斯曾在一九八五年辭去蘋果董事長一職），蘋果的事業結構仍是依產品分類，但賈伯斯回歸後立即解雇了各事業體組織的負責人，然後將整個公司重新依職能劃分，自己則親自指揮團隊；而且他不是根據績效評估各事業體，而是將整個公司視為一體來評估績效。
與此同時，他還建構出領導職能式組織的各個首席副總裁，成為以賈伯斯為中心、根據公司的方向和策略做出重要決策的體系。
賈伯斯相信，要以職能式組織取代事業體組織，這樣的經營方式才能創新。倘若按事業體經營公司，勢必會集中於事業體本身的短期績效，而非根據公司大方向開發創新產品，那麼，最終會專注於用較低的成本，讓事業體利益最大化；一言以蔽之，比起創新，公司會更著重於賺錢。賈伯斯確信，那樣的組織體制絕對不可能創新，也無法改變當時蘋果即將破產的未來。
話說回來，我們也不能保證職能式專家組織型態就一定能創新，不過，只要是曾在公司內部工作過的人，應該都經歷過組織內部的衝突，以及違反全體利益的利己主義。賈伯斯應該也領悟到，若要將全體員工的能力集中投入在公司利益和方向上，選擇職能式組織才是最好的方法，而且這樣的決定成了蘋果起死回生的契機。
嚴苛的甲、乙方順序
我所負責的可靠度評估業務，必須評估消費者在使用產品期間，產品是否維持原有效能，要是故障，就要分析原因並加以解決。假如消費者購買不久後，產品效能就變差或故障，那麼顧客將不再購買該公司的產品。因此，可靠度對消費者的滿意度，乃至品牌聲譽和價值都有著決定性的影響，所以企業在設計和開發產品的階段，就必須徹底找出問題並完美解決。
可靠度負責人從產品開發階段到設計、選材、零件功能與製程，甚至量產階段，都會與各個團隊全面合作，得益於此，我才能迅速理解蘋果的工作方式和特性。我在蘋果第一次開會時，就發現這間公司的特色是分工明確的業務順序。比方說，在與產品設計部和工程部開會時，產品設計部會向工程部提出近乎無禮的要求，使工程部處於劣勢、招架不住；我感覺得出來，工程部其實已經使出了渾身解數。
雖然組織表上不會寫出來，但實際執行業務時，可以明顯看出兩個部門的從屬關係。業務負責人之間的會議就更不用說了，產品設計部的總監報告會議，氣氛可謂如履薄冰，這場會議的主題，是產品設計部要求工程部改善開發中的產品，所以他們會在會議上提出犀利的指責與尖銳的問題。這種氛圍源自以賈伯斯的經營哲學建構的業務順序。
「設計會引領技術，而技術應該提出能讓設計成真的技術性解答。」賈伯斯認為，簡單是細膩的極致，因此致力於製造優雅、細膩且便於用戶使用的產品，為了有效推動這個過程，各部門謹守這樣的氣氛。
「請在本週五的會議上報告工程部開發現況、主要問題及針對各問題的改善措施，尤其要包含改善措施的驗證日期，然後將明確的收斂（convergence）方案分享給我們。為了讓我們能在開會前討論，請在週四前提供最終簡報。」
那麼，工程部就會與專案經理（協調不同部門間的合作，調整專案開發及實行日程的負責人）及核心成員（由專案經理和十五名左右的業務負責人組成）一起召開事前會議，討論如何回應產品設計部的要求。
專案經理會迅速整理開發過程中發生的問題，並準備簡報，工程部負責人則依問題類別分析問題原因，整理出應對方案，做成一頁式簡報（One Pager）和備忘稿（backup slide）。在事前會議上，各負責人以準備好的簡報為基礎，像是實際在產品設計部總監面前報告那樣預演。
這時，業務負責人會提出犀利的問題，預演實際報告時的提問，並針對該如何應對激烈爭論，過程中沒有人會在乎別人的目光並擔心：「我問這個問題，別人會怎麼想？」透過事前會議，一切就能準備得萬無一失。
會議上會問的問題包括：
◆「你認為這個假設是正確的，是根據什麼數據 ？請拿出支持這個假設的數據。不要自己猜測，應該要以數據為根據來討論。要是產品設計部問這個問題，你打算怎麼回答？」
◆「簡報上寫著下一階段的檢查點是一週後，為什麼需要一週的時間才能得到結果？請要求零件供應商更早提供。」
◆「故障原因是材料瑕疵還是物理性損壞，責任歸屬和改善措施會因此而不同。請用一頁式簡報寫出如何分析各種情況下的故障。為了配合專案的日程，請在下週前提出結論。」
◆「在提出問題之前，請先將整體策略的摘要表格放在簡報上，這樣才會給人一種你處理問題很有系統的印象，而且問題的解決方案也會更明確。修改後明天再報告。」
◆「簡報中提出的問題，根本原因並不明確，可以再具體說明是什麼部分引起問題嗎？還是你也不知道原因？」
◆「你想要透過一頁式簡報傳達的核心是什麼？如果要在產品設計部面前報告，這種資料的水準太差了，而且還有很多漏洞。回去重新整理問題的原因，下午再報告。」
◆「報告的時候，簡報播放速度太快了。你要先清楚說完想透過圖表傳達的內容，在切換到下一張簡報前，先讓總監提問，留時間讓他確認想知道的部分。」
◆「表格上面一定要加標題，而且不要把表格放在一頁式簡報上，最好放在備忘稿中。」
◆「你的簡報有錯字，不是『validete』，是『validate』，還有，簡報裡的字太多了，要以核心資訊為主，整理得更簡潔，表格框線的顏色也太深了，我看得很不順眼。」
對工程部來說，和產品設計部開會簡直就像打仗。即使是在蘋果工作很久的工程師，一旦自己的專案變成重要的案子，也會非常緊張，因為要是無法有邏輯地回答產品設計部提出的犀利問題，就會一直處於劣勢；總而言之，產品設計部是「甲方」，工程部則是「乙方」。
舉例來說，開會時如果更新內容不夠完善，產品設計部就會在整場會議上不斷訓斥工程部，使得工程部不得不在下次開會前，拿出能讓產品設計部滿意的結果，沒有任何方法可以草草了事、敷衍帶過。
「請找出今天討論的措施項目的明確答案，並在下週前報告。講白一點，就是要在那之前消除危險因素。」
為了達到產品設計部要求的可靠度評價，我通常至少會和工程部開兩到三次事前會議。如果發現還不夠完善的地方，就要持續向零件供應商索取資料來研究，同時夜以繼日地跟合作的業務人員交換意見來改善簡報（為了開三十分鐘的會議，至少要準備四到五個小時）。
產品設計部的角色，是在技術上滿足設計部的要求，因此他們會設計出能配置、組合顯示器、照相機、電池、感應器等主要零件的方法。在這段過程中，工程部的角色則是以產品設計部要求的產品設計和技術需求為基礎，與零件供應商協力尋找技術解決方案。透過這段過程，能解決開發產品的技術問題，最終確定量產產品的設計、功能、材料、零件，之後再由製造部改善製程，將良率（生產數量中良品的比率）最大化，然後搭配上市日期，開始生產。
一般公司的業務順序與蘋果恰恰相反，設計附屬於技術，由工程部統籌新產品中要出現的功能，產品設計部和設計部則是他們的後援。由技術引領設計的公司和由設計引領技術的公司，兩者的差異看似單純，但如果比較兩者實際開發產品的過程和上市產品的水準，就會發現差異極大。
在由設計引領技術的蘋果，產品設計部是甲方，工程部是乙方，乙方得根據甲方的要求，提出技術解決方案和替代方案，並為了得到甲方的正面評價竭盡全力。和我合作過的工程部人員一致認為，與產品設計部開會最為難熬，但我們還是花了大量的時間和精力準備會議。
不過，還有一層關係比這更有趣，就是產品設計部和設計部之間的關係。產品設計部與設計部開會時，角色與先前完全顛倒，因為設計部會催促產品設計部滿足自己的要求，因此，產品設計部就跟工程部一樣，會為了能完美應對設計部的要求而做到萬無一失的準備。在工程部面前扮演甲方的產品設計部，在設計部面前又成了乙方，如此嚴苛的業務順序讓蘋果成為擅長創新的企業… 閱讀完整內容
