全新任務中心上線了!
會員專屬好禮都在這

立即前往
任務中心
聽 Instagram 創始人詳解 如何打造百人菁英技術團隊
收藏文章
很開心您喜歡 獵雲網 的文章, 追蹤此作者獲得第一手的好文吧!
獵雲網
字體放大


分享至 Line

分享至 Facebook

分享至 Twitter


聽 Instagram 創始人詳解 如何打造百人菁英技術團隊

2017 年 10 月 30 日

 
展開

無論從哪個角度看, Instagram 的主要里程碑都是突破性的。憑藉著僅成立 1 年就被臉書(Facebook, FB-US) 相中,並以 10 億美元的價格收購,這家新創企業的整個生態系統穩定下來,並開始獲得關注。這既是它用戶暴漲的結果,更是未來進一步爆發的開始。從 2012 年被收購時擁有 3000 萬用戶,到兩年後,這一數字已經直逼 2 億,現在更是突破 7 億大關。

在公司內部,聯合創始人兼 CTO Mike Kreiger 圍繞如何擴大、升級技術團隊,從而獲得更多用戶給自己定了一套里程碑目標。在收購的時候,Kreiger 手下只有 6 名開發主管。今天,他的工程團隊已經達到 300 人規模,功能和產品開發速度令人咋舌。僅僅 7 年,Kreiger 從新手經理,成長為多層次工程師管理人,手下工程師許多都是各自領域的頂尖人才。

在此次獨家採訪中,Kreiger 分享了他幾年來學習到的經驗,以及如果能夠回到 2010 年,他會對自己說些什麼。對於想要複製其成功的其他新創企業,Kreiger 探討了如何溫和地將早期技術團隊發展成熟,如何引進新管理層,以及如何創建能夠不斷推動進步與創新的機制。

早期團隊應適應早期需求

想讓一家新創企業順利起飛,你需要準備好這些東西:勤奮、能量,以及一位解決問題的領導。專業工程師?不需要的。

Kreiger 根據自己的經驗說,這一時期你所需要的多面手應具備幾種關鍵特質和能力:

  • 知道什麼時候給牛剃毛

“你沒有有聽過那種表達,‘給牛剃毛?’”Kreiger 說,“有時候,寫程式意味著你要解決機器複雜的技術問題。但很多時候,你所面對的,是一長串的任務,解決了這些任務,程式也就寫出來了。’”

在組建多面手工程團隊時,你需要那些已經準備好並願意一路追隨到底,解決各種問題的人。你需要那些渴望學習自己所不具備的知識的人,這些知識或許非他們的職責所在,但是完成任務必需的技能。

如何找出這些人,以下幾個面試問題可以嘗試:

(1) 討論最近的一項副項目或工作項目,在著手真正的工作之前,需要先“剃掉哪些毛”。

(2) 詢問他們何時參與過跨學科項目,甚至是一些開始之前並不熟悉的項目。

  • 知道何時不值得剃毛

從上面我們可以知道,對於一家早期階段新創企業來說,沒有什麼比開發項目更重要,你必須確保自己的工程團隊得到了高效利用。“員工很容易對剃毛上癮。”Kreiger 說。一個聰明的工程多面手知道何時應當向前看。Kreiger 回憶說,在 Instagram 的早期時候,他得到一條受益頗深的建議:什麼都要管。這條建議至今都非常重要。

最初採納這條建議的時候,Kreiger 每天都要花 4-5 個小時整合 Nagios — 一款領先的基礎設施監測服務。“最後我終於醒悟,‘我得回頭去開發產品。’”與此相同,有些時候,你或許也可以自己開發什麼。但如果市面上已經有不錯的解決方案,你還應當花費這個時間嗎?

“一開始,我們想,‘嗯,我們可以想像怎麼做推送。但 Urban Airship 已經提供這個功能了呀。’”把你的驕傲放到一邊吧,真正的目標才值得你的注意。“我們的目標不是把 Nagios 或 Munin 搞得多好,而是開發出一個軟體,讓人們都能用上。”

  • 以行動為指南

你不可能同時做許多事情,因此,搞清楚哪件需要首先完成,哪件可以再等等就很重要。不是說你的排序系統要多精緻,但至少要有。在 Instagram 的早期階段,Krieger 和他的團隊在 Google 文檔上,按主題記錄下了行動項目。

“我們有這樣一個主題:成為全球發展最快的照片分享應用程式。在這個主題下,我們需要怎樣努力?下一步,我們想讓所有照片看上去更漂亮,怎麼做?跟這兩個目標無關的通通站邊去。另外,你要讓工程師也明白這兩個目標的重要性。”

Google 文檔是完美的最小化團隊任務管理可行性產品,它可以確保所有任務都直接關係到公司最重要的目標或當務之急。它將任務按天拆分,每天又分為不同主題。每個主題下面未完成的工作會遷移到第二天。最緊要的任務會做出特定標示。這樣一來,即便任務繁多,團隊成員也不會混淆,大家也方便留言、問問題,他們的注意力也就永遠放在下一步需要達成的目標上。

Google 文檔在 Krieger 建立早期團隊的過程中發揮了至關重要的作用,誰也不用因為對任務重要性意見相左而大吵大鬧。有了這款工具後,也不會有人一心想著自己的事情而忽略公司的規劃,你也不會遇到那些專門撿輕鬆任務的人。

招聘熱情、多變的多面手

雖然大型公司的招聘團隊已形成特定的機制,但新創企業也有它們自己的優勢:他們可以在思考、招聘的時候跳出固有模式。Krieger 回憶說,他和他的聯合創始人 Kevin Systrom 找到的第一位工程師名叫 Shayne Sweeney,後者就是跳出固有模式的典型案例。“他大學沒有畢業,編程基本自學。

我們在 Dogpatch Labs 孵化器認識的他,坐在我們對面桌。雖然學歷不好看,但他具有新創企業的精神:如果我有一個想法,我願意學習一切來使它成為現實。”

不過,不是所有人都能每天坐在對桌觀察別人的,那麼如何找到擁有這種潛質的人呢?Krieger 說,他的經驗是,對一切的好奇心是這類人最基本的性格特點。“我們喜歡的求職者是那種,‘這周我對圍棋開始感興趣,然後我就製作了一個圍棋模型,進行了好一番研究。’我們不喜歡那種,‘嗯,我就職的公司用 React,所以我也用 React。’”

自然,你也可以通過幾個巧妙的面試問題試探一個人的好奇心。Krieger 說:“我喜歡問 — 尤其是在早期階段,‘你感興趣的副項目是什麼?你上一次細緻研究一個項目是什麼時候?學習到了什麼?’”

工程師的靈活多變對早期新創企業來說也很重要,這一點甚至意味著,有時候你不能招聘某些技能點最高的求職者。

“我們之前面試過一個我認識的人,他是頂尖優秀的 iOS 工程師之一。但在對話中,他所說的基本就是,‘我得知會你一聲,我拒絶做服務器端的工作,因為我認為這是在浪費時間。’”Krieger 說。

這種思維的問題在於,對當時的 Instagram 來說,他的要求過於細緻。

招聘能夠在各類工作間切換的工程師,可以保證早期工程師團隊的敏捷性。同時,它也能幫你避免一些隱患。“我記得和 Kevin Rose 討論 Digg,他說,他們早期犯過最大的一個錯誤就是,招聘和當時技術極度吻合的工程師。”

Krieger 說,“這種做法錯在兩個地方。第一,你將來總會升級技術;第二,如果工程師們把自己的工作安全性捆綁在,比方說PHP上,那麼你最終一定會做出錯誤的技術選擇。”

Keirger 的最後一個建議是:儘早開始多樣化招聘,要比一般新公司都早。組建多樣化團隊的好處不言而喻,在近年來的科技文學作品中,這一點也被經常提及。但在瘋狂的早期發展階段,新創企業可能會認為這些建議不適用它們 — 或者也不是什麼著急的事情。

“早期階段的時候,我們在組建多樣化團隊上花多少精力。”Krieger 說。這就導致了,當團隊開始壯大時,引入更多女性和少數族裔和背景的人就更難了。“比方說,在面試第一位女性工程師時,她會想,‘哇,這個團隊規模好大,全是男的,’這就讓入職阻礙更大了。這種情況真的會發生,如果你想避免,最好早些行動。”

該細緻時就細緻

Instagram 的下一章故事現已稱為矽谷佳話之一:2012 年,這家 13 人的公司被臉書收購。當時,Krieger 和 Systrom 既可以獨立招聘人才,也可以從臉書內部尋找。而自從掛上臉書這一家喻戶曉的名字,越來越多求職者找上門來,他們的背景是兩人此前想都沒想到的。

當然,不是每家新創企業都具備這樣的條件,但無論你的情況如何,多樣化和細緻化都是不可避免的下一步。

隨著越來越多功能的上線,公司的不斷發展, Instagram 團隊開始感覺需要更多專業技能人才。比方說,能將產品拆開並升級的 iOS 和 Android 工程師。在新創企業的生命發展中,這是非常正常的時刻。當出現以下跡象時,你就需要考慮招聘專業人才了:

  • 你正在創造的東西,超越了平常使用的平台的能力;
  • 你開始進軍新市場,需要調優的代碼。拿 Instagram 來舉例,當時他們希望在新興市場提供更優質的影音服務;
  • 你的代碼庫越來越大,需要技術領導來指導未來發展。

在你還沒意識到的時候,你已經需要經理了

就像工程師團隊會升級一樣,你的領導團隊也需要成長、成熟。最開始的時候,你的公司會呈扁平狀態。不必要的管理階層會有損公開性和敏捷性,而後二者是小型公司最重要的資產。不過,這也不意味著創始人們應當讓早期團隊自我發展。

作為創始人或早期領導人,當你自己的產品和管理工作無法滿足需求時,就需要引入另一位經理了。而當你意識到你可能需要一位的時候,十有八九已經晚了。

獵雲網》授權轉載

【延伸閱讀】

 
週餘
 
 
分享文章
分享至 Line
分享至 Facebook
分享至 Twitter
收藏 已收藏
很開心您喜歡 獵雲網 的文章, 追蹤此作者獲得第一手的好文吧!
獵雲網
分享至 Line
分享至 Facebook
分享至 Twitter
地圖推薦
 
推薦您和本文相關的多維知識內容
什麼是地圖推薦?
推薦您和本文相關的多維知識內容