從IBM工程師到創業公司CEO,程序員經歷教會了我如何領導一家公司

jopen 7年前發布 | 15K 次閱讀 IBM

從IBM工程師到創業公司CEO,程序員經歷教會了我如何領導一家公司

獵云網(微信號:ilieyun)

注:Neil Lustig,曾為 IBM 高級工程師,現為紐約 Sailthru 公司的首席執行官。

在 Neil Lustig 職業生涯早期,曾面臨一個選擇:繼續在 IBM 的衛星辦公室做公司最有前途的工程師;還是前往紐約分部,一個更大的平臺,但是得從初級銷售職務做起。Lustig 的老板跟他說,調去紐約會毀了他在公司和行業內的事業。但是,他的導師意見相反。導師告訴 Lustig,只有在充分接觸了解技術和業務兩個板塊,才能夠突破個人瓶頸——并且如果沒有豐富的經歷,他也將難以勝任領導職務。

于是,Lustig 去了紐約——在銷售業大展拳腳。Lustig 花六個月時間就達到了個人年度指標,與花旗銀行這類的大客戶完成了幾百萬美元的交易。這些年來,Lustig 從初級銷售最終稱為 IBM 電商解決方案部門的負責人。之后,每加入一個團隊,他就肩負起更多責任。

在本次的獨家采訪中,Lustig 分享了他的管理心得,以及如何向專業人士學習,成長為一個更加高效的管理者。他列出的每日工程實踐,不僅幫助他戰略指導了公司,也培養了他的“領導軟實力”。

適當分解問題,能夠更好地前進

產品,和團隊、公司類似,都是解決復雜問題的系統。這是 Lustig 第一次從獨立貢獻者(指埋頭干自己工作,不考慮大局的員工)轉向管理者時領悟到的一個重要道理。為了解決新的挑戰,他把復雜系統分解為更容易管理的不同組件,然后再處理解決。

當 Lustig 第一次在 Ariba 擔任掌控全局的角色時,他從紐約的銷售主管搖身變成了歐洲區金融、銷售、市場、專業服務負責人。他回憶說:“我都不知道要做什么。要去領導一個由 10 個國家組成的團隊,并且還說著不同的語言——簡直瘋了。借著我當工程師那會常用的軟件開發方法,我想:在連續流中你不會重寫一個新系統。你會盡可能得將問題分解,然后依次解決。擔任 CEO 也是同樣的道理。在那個案例中,我從消費滿意度著手,因為產品的方向和我們的增長速度都取決于消費者對產品的理解。這樣一來事情就好辦了,我們可以集中精力,協調人手來一起解決這個問題。”

通過電話,隨機測試和傳遞信息

在課堂上,隨機發問可以讓最優秀的學生緊張起來。換個角度,如果我們主動提供解決方案,并且通過電話這一端,那情況會如何呢?“我從 IBM 前 CEO Lou Gerstner 和他的管理團隊學到很多東西。一個我至今仍在使用的戰術,就是親自打電話給公司了獨立貢獻者,”Lustig 說,“有一次,那會的 IBM 首席財務官給我打電話。那時我剛進 IBM 不久。他問我遇到什么難題,我說我正在努力搞定全球賬戶方案中的一個客戶。然后他說,‘好的,交給我吧’——于是就掛了電話。”

高級管理層很容易與前端人員脫節,特別是在創業公司擴大規模的過程中。對 Lustig 來說,電話拜訪這一習慣與軟件開發中的隨機測試有點類似。“這是軟件測試中的一個常用方法,就是隨機輸入數據來測試程序。這個方法可以保證系統的完整性,并測試系統在‘外部環境’中是否穩定,”Lustig 說道,“領導者也十分有必要這么做,因為他們實在太容易與現實世界脫節。事實上,只與高層管理人員交流就好比僅在舊金山測試你的應用,這么做很容易局限你的視野。IBM 的高管經常和整個公司員工交流。身處前線的戰士們有著不一樣且重要的觀點。”

在哪怕只有 IBM 十分之一規模的公司里,高層領導也應該每天進行隨機電話拜訪。當 Lustig 加入 Vendavo 后,他通過組建一個6-10 人的跨部門團隊來推行這個方法,這樣他就可以親自了解到所有的 150 名員工。“這么做的目的是減少等級和摩擦感。這樣,我會見員工的同時,就不會有同部門的人在場。并且,每個小組里的人都不會與自己團隊的管理者相遇——這更有助于讓他們感覺到自己是 Vendavo 的一份子,而不是僅僅作為工程團隊或銷售團隊中的一員。”

“現在,作為一名 CEO,我不再認為嚴肅地坐下來交流可以解決所有問題,”Lustig 說,“有時候,小團隊的隨意交談,不僅讓我在他們面前顯得更平易近人——不是董事會派來談人員變動的代表——也讓我作為一個先例,每個人都可以參考學習。”

從IBM工程師到創業公司CEO,程序員經歷教會了我如何領導一家公司

語言投資——學會變換交流方式

工程師會討論到,一個老練的開發人員到底需要掌握多少種編程語言?但毫無疑問的是,掌握一種以上的編程語言確實好處多多。對于交流方式,亦是如此。懂至少兩種以上措辭表達,可以讓你通過對比了解每種表達的優勢和限制。即便你不能完全理解,你也會對其他表達有更強的理解能力。

Lustig 在從工程崗位轉到 IBM 的銷售部門時,很快就意識到了這一現象。“第一天,我的經理就交給我一項任務:讓我證明,我對人的了解甚于軟件,”Lustig 說,“作為一名工程師,這實在難到我了。他告訴我,我需要學會一種交流方式,可以讓別人在和我聊完后說:‘這家伙不錯,我愿意和他一起工作。’”

每一個 Lustig 曾經嘗試過的職位——工程、銷售、市場營銷——都把他造就成為了一個更好的管理者和 CEO。“語言流利是我作為領導的最大優勢。如果你可以根據人們的專長和他們感興趣的點,改變你的語調、節奏和措辭,那么你就成功了。”

以 Lustig 向他的工程團隊、銷售團隊以及客戶團隊介紹 Sailthru 的新搜索引擎解決方案功能為例:

  • 對工程師:“該功能旨在最小化索引信息所需的時間,從五小時減少到數秒鐘。從產品角度來看,這是一個難以置信的提升。這是一個解決大難題的好機會,需要好好將其利用起來。我們將把這項功能作為我們的技術基礎。接下來就是你們展現才華的時候了。”
  • 對銷售人員:“Elasticsearch 可以讓客戶以前所未有的方式管理市場營銷活動。它可以顛覆行業現狀。它不僅可以提高我們的客戶滿意度分數,可以幫助我們在市場上打敗其他競爭對手。”
  • 對客戶團隊:“這關乎消費者能力和滿意度。消費者對 Elasticsearch 期待已久,希望盡快嘗試他們許久以來渴望實施的戰略。我們可以幫助他們最終實現這個愿望——并監測分享結果。”

再有,交流不僅停留在語言表達層面,實際行動在有些團隊中能更快地引起共鳴。比如,當 Lustig 在 Ariba 工作時,每年他們都會獎勵最佳銷售人員一年的保時捷租期。“把保時捷開出來,鑰匙交給獲勝者是非常直觀的行動,”他說,“其余的銷售人員會在心里想:‘下一個就是我了。’銷售的競爭是激烈的,最直觀的行動最有激勵效果。但是相同的獎勵卻不一定對工程團隊有效,金融團隊更是不可能。不同的部門都應有相應的獎勵。”

公開企業戰略路線圖

當大多數領導說要合作時,其實有個問題仍沒有明確——團隊要在哪方面合作。他們往往忘記提及,需要多少自主權才能讓合作順利進行。“如果合作是一個進程,控制基礎比控制長期結果要更容易。比如,和很多公司類似,Sailthru 的團隊定期開會——我們是每月一次——回顧我們的發展路線圖,研究每個部門完成的目標業績,”Lustig 說,“我們會為這些環節創造足夠的空間。當我們談到指標時,我們以對話形式體現,會問:‘是否按計劃發展?是否需要調整?’用討論的方法來取代作報告。”

以下是 Sailthru 每月會議上涵蓋的內容:

  • 公司目標回顧,以及目前進展
  • 新業務的完成情況
  • 重要更新內容
  • 專題介紹,比如內部滿意度調查數據回顧等
  • 大聲說出個人為工作所做的貢獻
  • 自由發言,可以討論或提出任意問題

Sailthru 的每月路線圖會議的實踐已經獲得成效。“在最近的滿意度調查中,90% 的公司員工表示他們清楚自己的日常工作是如何為公司目標做貢獻的。”Lustig 說。

最后,公司戰略路線圖有必要讓其他人知道,而且還得讓他們熟悉和了解,甚至更多。“我見過很多早期階段的創業公司的 CEO 和創始人對此十分糾結。一人攬大權的行為,如果只是在 20 個人的小公司,那還好辦,產品技術、用戶都還在掌握之中。但是當你公司發展到 50 人時,這種專制就會成為公司發展的瓶頸,會放緩了整個公司的發展步伐,”Lustig 說,“當我加入 Vendavo 時,CEO 兼創始人說,我們三個人經驗最豐富,應該參與到每一項交易中。但我不這么看。我們有 20 個銷售人員。如果讓每個人都參與到交易中,我們的年銷售額就會達到 1500 萬美元。所以,你得信任你的團隊,然后向他們公開你的計劃。”

保持謙卑,不斷學習

這幾十年來,Lustig 見過許多技術變革。這讓他明白,去年的方法放到今年就不一定有用——更別說來年了。他說:“你去年做的事情很快就失去價值。這個世界上,沒有最好,只有更好。”

以下幾個方面是 Lustig 時時保持與時俱進的:

公司管理不能拖。就像工程師重審和完善他們的代碼庫一樣,管理者也需要定期重新審視他們的管理。“IBM 的前高管 Jerry York 曾跟我說:‘公司就像中年男人,放任不管就會日益發福,’”Lustig 說,“管理中的惰性等同于代碼中技術債務。公司——就好比產品——雖然仍在運作,但是真的有效嗎?你應該問自己,如果重新再來,你會雇傭誰?如何建立團隊?投資誰?你現有的團隊是為去年的業務而建立。今年需要今年的團隊。”

拓寬你的基準。作為工程師,Lustig 在公司和行業內總是尋求自己產品與其他同事的基準。Lustig 說,“我有嘗試去有意識地標準化我的管理風格和決策。我目前在兩家公司擔任董事,要每月在兩個不同的方向標準化關于“成功”的指標,這對我來說是個不小的挑戰。”

分享信息,不如換位思考。Lustig 在工程、銷售和市場營銷領域的工作給予了他感同身受的能力,這一同情心幫助他很好地處理了各種領導難題。“因為各種原因,不是每個員工都可以像我這樣在各個領域都有工作經驗。但這并不妨礙你嘗試復制這種體驗,”Lustig 說,“我們的工程經理常常跟在我們的客戶服務團隊后面,而且很快高級工程師紛紛自愿來加入。他們開始研究各種對客戶有意義的細枝末節,不過當然也是從技術角度出發。事實上,他們需要的僅僅是親身感受和體驗。”

總結

當軟件工程師打算從代碼跳槽到商務時,他們可以依靠自己的開發技能來指導自己前進。首先,公司好比軟件系統,盡管復雜,可以用分解分析的方法將復雜事物一一分解為可以管理的模塊單元。通過電話拜訪員工,隨機測試你系統的完整性與健康。這有助你校準對公司發展進度的了解。開發人員通常掌握至少一種動態編程語言,但是掌握的編程語言越多越好——領導亦如是,熟悉各部門領域的語言有助于管理公司。公開你的路線圖,別欠下管理工作,拓寬基準。

“那個說我如果從工程領域跳到銷售會終結我職業生涯的老板,其實他想的還不夠遠。從職業角度分析,他并沒有說錯——我的確沒再回到軟件開發領域,”Lustig 說,“但是他所忽視的是,我轉型后可能對其他人的職業乃至公司帶來的影響。作為工程師,我也許可以繼續開發產品,和團隊合作,實現指數級增長。但如果要我為其他工程師的早期職業生涯提點建議的話,我會說:真正做到‘全堆棧’,在一定時候踏出軟件開發領域,勇敢轉型!因為,你已經在軟件領域建立了足夠的基礎了。”

來自: www.lieyunwang.com

 本文由用戶 jopen 自行上傳分享,僅供網友學習交流。所有權歸原作者,若您的權利被侵害,請聯系管理員。
 轉載本站原創文章,請注明出處,并保留原始鏈接、圖片水印。
 本站是一個以用戶分享為主的開源技術平臺,歡迎各類分享!