Posts Tagged ‘management’

創業 CEO:期限的力量

December 16th, 2013

Run Forrest Run

在每週一次的「創業 CEO」系列,我們討論創業者如何教會自己成為偉大的 CEO,因為歷史上最偉大的創業公司,往往都是由這樣的人在領導

身為 CEO,當團隊工作效率不彰,我們總是急得像熱鍋裡的螞蟻,一不小心就會動怒、罵人。但事實上,「鞭策」在過去重複性的製造產業或許適用,來到了網路這樣創造性的產業,往往只會適得其反。

無法在後面用推的,那就必須換另一個方式驅動團隊前進。而巧妙的使用「期限」,我發現,就是其中非常有 Leverage 的工具。

The Problem with Loose Deadlines

 一個六個月的專案需要多久時間完成?超過六個月!

要了解期限的原力,我們得先探討它的黑暗面,也就是當一個專案的期限過於寬鬆,因為「配速不良」所產生的問題。

如果是一個有經驗的馬拉松選手,他會適當的分配每一階段所花費的時間,來讓自己剛剛好在體力耗盡前抵達終點。但可惜大多數新創公司專案的執行團隊,往往不是經驗老到的馬拉松選手。給他們六個月時間做新版本產品,你會發現他們一開始花太多時間做研究,中間蓋產品時出現一堆意外,最後根本沒時間把 QA (Quality Assurance) 做好。

追究中間的問題,是專案一開始的時候,它的期限對所有人來說太遠了,遠到幾乎可以忽略。因此大家好整以暇的發想功能,無形中為自己增加了許多無謂的風險。等到開發階段,這才發現很多新技術根本還未成熟,因此開發一再受阻,需要退回原點,最後當然沒辦法在時間內蓋好,何況跑完好的 QA 程序。

這時團隊的士氣低落,但因為沒有達到 Deadline,你不但沒辦法鼓勵他們,可能還要做出懲罰。整個組織投入了一堆資源在這案子上面,但得到的投資報酬卻相當有限。

The Effect of Tight Deadlines

但同樣是壓期限,如果把它改為一週、兩週、或是四週這種很容易體會到,似乎馬上就要來臨的 Deadlines,這時看不到終點的馬拉松突然變成了截止線就在眼前的短跑,而奇妙的事情也跟著發生。團隊會非常在意這個終點,因此會回頭砍掉無謂的工作,把時間與精力都專注在最關鍵的事情上。

也因為時間不足,他們需要想辦法最大化有限的資源,因此創意且實用的工作方式也會在這中間產生。而如果他們能夠在短期限中達成目標,那將會得到應有的獎勵。這個流程如果常常重複,久而久之團隊也會變得更有自信。

因此,相較於寬鬆期限,在經驗不足的新創公司,短期限通常是較能驅動團隊,投資報酬也較高的工作方法。此外,即使案子失敗,你的損失也能在控制之中。

___

歡迎訂閱 MR JAMIE 電子報

(Photo via mysterious happen stance, CC License)

創業 CEO:雇用產業經驗,或是職務能力

November 25th, 2013

Army Officers

在每週一次的「創業 CEO」系列,我們討論創業者如何教會自己成為偉大的 CEO,因為歷史上最偉大的創業公司,往往都是由這樣的人在領導

我知道連續三次引用 Matt Blumberg 的文章很沒創意,但我不得不說 Matt 近期真是火力全開,上週這篇 Debunking the Myth of Hiring for Domain Expertise vs. Functional Expertise 又讓我思考了一整個禮拜,因此今天還是決定拿出來跟大家討論一下。按照慣例,我鼓勵你先去把文章看過,再來看以下我的一些想法。

雇用 vs. 拔擢

Startups 規模化到某個程度,總是會碰到這個難題,到底要從內部培養經理人,還是從外面雇用。內部培養的好處是文化的一致性,營運與團隊的熟悉度,但壞處就是可能缺乏管理經驗,什麼事情都必須從犯錯中學習,因此成熟時間較久與成本也較大。相對的,外來資深經理人可以帶來產業人脈,滿足時間的急迫性,以及解決內部人才不足的問題。但缺點就是對人與公司營運模式形成的前因後果不夠熟習,也可能會有文化的衝擊。

產業經驗 vs. 職務能力

因此,當公司有這樣的需求,且的確能找到文化有一致性的人才,再加上 CEO 可以花很大力氣幫他進入狀況的前提下,一個 Startup 會選擇添加外來資深經理人。這時有一種說法,是你否則就得到產業經驗 (Domain Expertise),否則就是職務能力 (Functional Expertise),但兩者很難兼顧。

什麼意思?

產業經驗指的是跟你相關行業的營運經驗,職務能力指的則是對你在找的職務有豐富管理與作業的經驗。理論上這兩者可以得兼,但實務上卻很難,為什麼?

舉一個稍微簡化,但是比較容易理解的例子:假設你是 2006 年剛剛崛起的 Facebook,為了未來的上市之路做準備,你需要找一個外來資深 CFO。如果要找對網路產業有豐富經驗的財務長,那只能挖角 Google、Amazon、eBay 的 CFO。這些公司如日中天,CFO 的薪資地位都非常崇高,你只是其中一個似乎有潛力的 Startup,但連商業模式都還沒有,這種公司每年有好幾十家,幾乎不可能說服這些大 CFO 加入你,否則也要斷一條腿 (很大的股權) 來換。

因此你往往只能退而求其次,選擇找這些公司裡面的財務部人員,那些被壓在下面短期內升等無望的人,也就是所謂的擁有產業經驗,但沒有職務能力的人。或者你可以找其他產業上市公司的 CFO,可能產業或公司的狀況不好,他們會願意加入有潛力的新興產業,也就是擁有職務能力,但沒有相關產業經驗的人。

規模化經驗

但 Matt 提出來另一個論點,事實上除了產業經驗與職務能力,另外有一個關鍵經驗是常常被忽略的,那就是對「規模化過程」的熟悉度。公司的規模化不會一次到位,實務上它比較像爬樓梯,每一階段都有階段的工作與目標,也有非常非常多的眉眉角角需要注意。如果外來資深經理人有過類似的經驗,則在你爬這個樓梯的每一步,就能給你很多重要的提醒,也會讓公司省下諸多無謂的錯誤。

這點我可以親身證明。AppWorks 的其中一位合夥人 Joseph 是從很早期就加入 CID (華威創投) 的夥伴,在那裡服務的 11 年中他第一手參與了 CID 從 20 人團隊一路擴張到橫跨全球五個地點,總人數達近百的規模化過程,也目睹了他們的基金數量與規模大幅成長的經過,因此在 AppWorks 規模化的路途上,他經常是我們最重要的明燈。

所以,就像 Matt 在他文章中說的一樣,既然除了產業經驗與職務能力之外,既然你在解決的是「規模化」這個問題,那麼吸引到有這個寶貴經驗的人,當然也會有很大的幫助。

___

歡迎申請 AppWorks Accelerator Class #8,加入這個 120 位創業 CEO 組成的 Network

(Photo via drakegoodman, CC License)

創業 CEO:為公司打造「作業系統」

September 23rd, 2013

Police Forces

在每週一次的「創業 CEO」系列,我們討論一個創業者如何教會自己成為一位偉大的 CEO,因為歷史上最偉大的創業公司,往往都是由這樣的人在領導

作業系統 (OS / Operating System) 是一組軟體,用來管理電腦硬體資源並且提供電腦軟體共通的服務。作業系統是一個電腦系統中必備的系統軟體元件,應用程式通常需要作業系統才能運行。(Source: Wikipedia)

在 Matt Blumberg 的新書 Startup CEO: A Field Guide to Scaling Up Your Business 中關於 Execution 的一部,提出了一個很有趣的概念,他用「Company Operating System」去形容一個企業的核心營運流程,並鼓勵創業 CEO 們用心去建造一個一流的作業系統。

對於學軟體出身的我來說,這是非常啟發人的比喻。你可以把公司的各種硬體與設備看作底層,然後建造一組 Operating System 去控管並協調這些資源的使用。你也可以把公司的工作團隊看作中間層,在那之上再建立一組高階的作業平台以確保上層的策略、目標,能夠被中間層的同仁確實執行,且同仁與同仁間的整合、溝通,能夠順利的發生。OS 必須給每個軟體足夠的作業權限,也必須做好錯誤的處理,這些也是公司營運中關鍵的活動。

此外,雖然上層的應用程式千奇百怪,一個作業系統的工作方式卻是固定且可預期的。同樣的道理,一個新創公司可能常常需要調整它的業務內容,但不代表它不能夠有一個經常性的作業流程。事實上,幾億年的日出日落、春夏秋冬演化下來,「固定韻律」早已深深寫入我們的 DNA 中。在可預期的環境下,多數人的工作表現往往比不可預期之下來得好很多 ── 這也是 20 Mile March 背後重要的精神之一。

如果一個軟體作業系統有 Program Execution、Memory Management、Multitasking 等核心功能,一個 Company OS 又該有哪些關鍵功能呢?Matt 提出了幾個他多年經驗下來的結晶:

  • 重大會議行事曆 ── 季董事會、年度策略會議等這些會大幅影響公司走向的會議時間,應該提前讓團隊知道,讓大家可以有正確的預期
  • 統一的關鍵溝通格式 ── 統一的溝通格式讓大家可以專注在被溝通的內容,而不是浪費時間在解讀,甚至誤解上
  • 透明的重大決議 ── 在每次董事會、策略會議後,除了絕對機密的內容外,CEO 應該向全公司清楚報告這些決議的內容與前因後果,確定所有人都明白了解公司的走向
  • 清楚定義核心領導團隊與決策流程 ── 應該要讓所有人明確的知道核心領導團隊的組成 (在 Eric Schmidt 時期的 Google 這個核心團隊就叫做 Operating Committee),並且了解他的部門所歸屬的領導成員,因此當他對公司的策略與方向有想法,才能知道該去找誰聊聊
  • 嚴格執行「開門」政策 ── 就像作業系統必須要回應每個在執行中的程式一樣,核心領導團隊也必須回應每一個需要解答的同仁
  • 單一化的資訊系統與作業流程 ── 不要讓同仁的生產力浪費在工具的適應與除錯上,無論是傳統或是雲端的資訊系統,選擇一個不錯的,然後確保全公司都能夠妥善的使用,或者說在工具的選擇上,單一化所得到的生產力提昇,往往大過多元化所帶來的好處

當然,這些是 Matt 為 Return Path 所建造的核心作業程序。你的公司因為商業模式與企業文化的不同,應該還需要有所增刪。但無論如何,用作業系統去思考營運流程的建立,的確讓一切都變得有趣了起來呢。

___

歡迎訂閱 MR JAMIE 電子報

(Photo via police_mad_liam, CC License)

©2024 MR JAMIE.
網站由 Allen Hsu 設計 | Logo 動畫由 Wen Chen 完成