管理者的困境:放權或者崩潰

編者按:原文作者Dreck Sivers是CD Baby網站的創始人,CD Baby是全球最大銷售獨立音樂人CD的網站。Dreck自己也是一名音樂人。他榮獲2003年“全球技術獎”,被《時尚先生》雜誌評為全美年度“最傑出和最睿智”封面人物。

大多數管理者都會陷入放權的困境。你很忙,每件事都要親力親為。你很清楚自己需要別人幫忙,但你沒有足夠的時間尋找並培訓別人來幫你。所以,你更加努力地工作,直到自己崩潰。

下面這個故事講述了我如何放權。

2001年,CD Baby成立三周年。我已有8名員工,但所有其他事情仍然需要我自己做。每週7天,從上午7點工作到晚上10點,自己仍然要經手每件事情。

每隔5分鐘,就會有員工向我請示:

  • “Derek,有個傢伙想修改網站上已經存在的相冊,我該怎麼跟他說呢?”
  • “Derek,我們可以接受電匯作為一種支付方式嗎?”
  • “Derek,有個人今天下了兩個訂單,他想知道我們可不可以給他一起郵寄過去,並且把節省的郵費給他退回去?”

如果整天不停地回答問題,那麼什麼事也做不成。我感覺我好像是每天去上班,然後在過道裏坐著,全職回答員工的問題。

我的忍耐已經到了極限,我不再去辦公室,並且關掉了手機。隨即,我意識到自己正在逃避問題,而不是去解決問題。我必須解決這個問題,要不然就壞了。

經過一夜的反思,我最終在思想上接受放權。

我必須放權,我不是我公司的必需品,沒有我,我的團隊照樣也可以經營公司。

第二天,我一進門,有人就請示我,“Derek,我們昨天收到了一個客戶送來的CD,但他今天改變了主意,他想讓我們退回他的CD。我們給他郵寄了回去,但他又問我們能不能退還他的安裝費用,因為他從未登錄過網站。”
這一次,我並沒有僅僅回答了他的問題,而是把大家都召集起來。

我給大家解釋了事情的經過,和需要解決的問題。我回答了問題,但更重要的是,我解釋了自己思考的過程和回答背後的理念。

“是的,我給他全額退款了。這樣,我們會受到一點損失。但是,最重要的是經常做一些能讓顧客高興的事,只要不過分就行。像這樣一個小小的表示對我們大有裨益,他可能會因此告訴他的朋友們,我們是一家不錯的公司。每個人都要記住,幫助音樂愛好者是我們的首要目標,利潤是其次。你們將來可以根據這條準則來自己做決定,我會完全同意。做那些能讓他們高興的事。要確保每個跟我們做生意的人都會滿意而歸。”

我一一問了每個人,確保他們都理解我的回答。

我讓一位員工起草一本手冊,把這種情況的處理方式記錄下來,並附上解決這種問題的理念。

然後,每個人都回去工作了。

十分鐘之後,新的問題,相同的過程:

  • 1. 召集所有人
  • 2. 回答問題,解釋理念
  • 3. 確保每個人都理解整個過程
  • 4. 讓一名員工把這條記錄在冊
  • 5. 讓他們知道,下次沒有我他們也可以這樣處理問題

2個月之後,沒有員工請示了。

然後我想員工們展示了事情的最後一部分,也就是我自己的工作。作為學習的一部分,他們也需要把這個記錄在冊,然後給其他人看(由教而學)。

現在,公司完全不需要我了。我開始在家裏工作,不再去辦公室了。我甚至教過他們我關於雇傭新員工的思考過程和理念。所以,有兩個新員工是完全由他們發現、面試、雇傭以及培訓的。他們用那本手冊來讓每個新員工理解這種理念以及它的歷史,並且知道怎麼自己做決定。我每週去視察一次,確保一切正常。確實一切正常,他們甚至都沒有什麼事情向我請示。

因為業務由我的團隊負責運作,我可以心無旁騖地改進業務。我去了加利福尼亞,只是弄清楚事情由他們運作。

我現在仍然每天工作12個小時,但是,我把所有時間都花在業務改進、優化以及創新上。對我來說,這才是最有趣的事情。這是在玩,不是工作。

我放權之後,公司市值在四年裏從一百萬增長到兩千萬。管理者和企業家之間有很大的不同。作為管理者你會感覺很自由,直到你意識到如果自己不工作,公司就會倒閉。

要成為一名真正的企業家,你要確保自己能夠離開一年,而當你回來時,你的公司比你離開時運營得更好。

 

如果你不是Programmer,怎麼聘請Programmer呢

 

你需要注意一下幾點:
1. 他們有多堅持己見(固執)呢?

詢問他們有趣的編程主題(如Ruby或Python?)。從他們回答的語調和推理中,可以得到很多資訊。在我們最近一期節目中 ,傑夫說:“當人們對事情有強烈的見解,當他們可以大篇幅地談論一些事情時,這就是一個很好的跡象表明他們對這件事很有熱情。”

2.他們為開源專案做了多少貢獻?

看看他們的貢獻。雖然你可能不是一個programmer,你仍可以知道他們是否寫過一些代碼。而事實上,一個人有所貢獻,是一個良好的開端。“事實上,一直在貢獻意味 著他們正在使用這種工具,”Jamis說。“這就好比抓癢,就像他們接觸到一些他們認為應該加以改進的程式,或接觸到一個錯誤並且自己修復了那個錯誤。參 與程度對programmer是一個很好的鑒別標準。”

3. 他們有多享受編程?

他們不需要在自由時間的分分秒秒都去敲代碼,但是你確實想看到一定程度的熱情。Jamis說,“與其說在業餘時間編碼本身是最重要的事情,不如說它展示了你熱情的態度和有自己的見解。”

4. 他們真的掌控工作? (Do they actually ship?)

瞭解他們如何管理自己的工作。軟體通常出小錯誤——瞭解他們如何避免這種情況。瞭解他們什麼時候按時地完成了項目,並詢問為什麼這個項目是成功的。或 從延遲項目中吸取了什麼經驗教訓。“控制軟體運行的能力是關鍵的,”據傑瑞米說。“他們是如何管理實際需要的任務並在一定的時間內完成,這是很重要的。”

5. 他們掌握了什麼?

皮克斯(Pixar)公司的蘭迪·納爾遜認為,能夠掌控任何一件事意味著也能夠掌控其他事。所以尋找那些掌控著一些事的人。候選人是一個優秀的廚師 嗎?或山地車選手?還是其他什麼人物?”這是一個跡象表明他們也可以做您項目的主導者。“那是一種即使其他登山者幾乎馬上就要到達山頂,仍感覺我將要先到 達山頂的感覺,”尼爾森說。“如果一個人在來到你工作場所之前都沒有涉足,那麼他成為工作的主導者的可能性也是很小的。”

6. 他們的溝通能力如何?

你對編程瞭解的越少,你越需要依靠一個人去解釋程式進度。這就是無論什麼職位都要聘請大作家的原因,這是個好主意。例如,這兒有傑夫解釋的在計畫方案內Basecamp API人員更新到其他專案的例子:

我只是對Basecamp 和Companies APIs的人員進行更新調整。

我們現在允許客戶和公司員工去接觸通過專案認識的人和公司。在此調整之前,公司員工和客戶只能看到對方使用的特定的項目ID。沒有辦法讓他們看到在項目過程中參與的所有人(例如,同事)。

例如,如果API用戶發出的請求,一個是鮑勃,另一個是吉爾,那麼/ people.xml文件將返回給鮑勃和吉爾。如果請求的用戶是管理員, 那麼帳戶中的所有的人都能收到。
這同樣適用於公司管理。

如果一個programmer既能夠編碼,又能講非programmer能聽懂的的話,那麼很多事情是不太可能出問題的。(編注:上面這6點,是招聘官需要知道的注意事項。關於在聘用programmer或開發人員的時候,需要問哪些問題,

試用 Test drive

如果可以,擯棄“全要或無用”的決策模式。雇用一個全職員工是一個很大很困難的決定。為小項目聘請員工,讓他們在空閒時間完成這些專案,這種方式更容易為雙方所接受。《Getting Real》 中的“淺嘗輒止” 一文中談到:

在聘請任何人之前,先給他們一個小項目來考慮。我們就會瞭解他們對待這個項目是如何溝通,工作的,等等。當他們設計或者編寫的時候,就會給你帶來很多發現。你會相當快的學習,無論氛圍是否恰當。

可以用日程安排來堅持這種方式,即使只需要20或40小時,也比什麼都沒有要好。適合或者不適合,都會顯現出來。如果沒有,那就是雙方想要先測試工作而隱藏了自己的問題與風險。

仔細考慮一下,你能提供什麼,並且如何才能讓你的職位盡可能的吸引人,這也是個不錯的主意。壺裏的蜜越多,才會有越多的蜜蜂飛進去。(恩,不管怎樣, 可以肯定這不像一個東西放在那一樣)在《Great Hackers / 偉大的駭客》中保羅點格雷厄姆提供了一份列表,關於如果吸引最優秀的programmer:優秀的開發工具、開源軟體、帶門的房間、一個感興趣的問題和聰明的同事。如果 你有其中的任何一項或者全部,確保讓潛在的雇員能夠瞭解到。

自己動手?

所有這些都會有所幫助,但是很顯然,聘請programmer最好的方法是你自己能至少瞭解一點編程。聘請一份你從來沒有做過的工作,真的是件很困難的事。因此,要在聘請了那些人之後管理他們,格雷厄姆在他的《偉大的駭客》一書中有過如下討論:

我看過關於如何管理programmer的一些文章。事實上有兩種:一個是如果你是programmer,你該做什麼,另一個是,如果你不是programmer,你該做什麼。而第二種可以總結為兩個字:放棄。

問題不在於日常管理。實際上,真正優秀的駭客(hacker)是自我管理的。問題是,如果你不是駭客(hacker),你就不會知道誰才是真正優秀的駭客(hacker)。

確定自己是否能在招聘員工之前瞭解一些編程技術。事實上,傑森在與DHH合作之前就已經開始學習PHP了。同樣的,在我們當中有人學會如何配置伺服器之前,37signals不會聘請系統管理員。如此做來,你就會對尋找應聘者以及你想解決的問題有更深入的理解。

至於你在這過程中犯的錯誤,要記住,這就是“真正的”programmer的工作方式。“運行迭代感覺就像永遠反復的錯誤校正”傑瑞米解釋到。“這聽起來很令人洩氣,但這卻是允許的。該死,甚至測試驅動開發也是反復的錯誤校正。所以,建議你應該先從自己做起。”