創(chuàng)業(yè)公司經(jīng)常會(huì)聽到這樣一條建議：一定要招聘那些最出色的員工，無論你的公司有多大，都不能降低招聘員工的標(biāo)準(zhǔn)。這條建議沒錯(cuò)，因?yàn)橹挥杏沙錾珕T工組成的優(yōu)秀團(tuán)隊(duì)才能夠?qū)⒁粋€(gè)好的想法轉(zhuǎn)化成偉大的產(chǎn)品。
有關(guān)這條建議，思來想去，總感覺哪里不對(duì)。我們總是口口聲聲說要招聘全世界最出色的員工，事實(shí)上，我們做的僅僅是雇到我們周圍那些還不錯(cuò)的員工，而非全世界最出色的員工。如果我們真想做到雇到全世界最出色的員工的話，我們應(yīng)該真正的努力那樣去做，而不是僅僅說說而已。為此，我們就必須摒棄這個(gè)想法：招聘的員工必須能夠來公司上班。
當(dāng)我和另外一位聯(lián)合創(chuàng)始人Joel Spolsky在2008年聯(lián)合創(chuàng)立問答網(wǎng)站Stack Overflow（現(xiàn)在的StackExchange）時(shí)，我當(dāng)時(shí)的辦公地點(diǎn)在伯克利，而Spolsky的辦公地點(diǎn)在紐約，當(dāng)時(shí)我們每周主要通過電話溝通工作方面的事宜。后來又陸陸續(xù)續(xù)加入了來自北卡羅來納、德克薩斯和俄勒岡州、英國和德國等地的開發(fā)者，加入公司后他們依然在原先所在的地方辦公。我現(xiàn)在已經(jīng)不在這家公司了，據(jù)我了解，現(xiàn)在這家公司的員工近150位，分別在全世界的不同地方辦公。
從在Stack Overflow的經(jīng)歷中，我學(xué)到的最寶貴的經(jīng)驗(yàn)之一便是：很多出色的軟件工程師其實(shí)并非來自硅谷，只有在全球范圍內(nèi)進(jìn)行招聘，而非僅局限于舊金山灣區(qū)，才能讓你真正有資格說你只招聘最出色的員工，并且說到做到。
Discourse是我新創(chuàng)立的公司，它是一個(gè)能夠讓全球的客戶、粉絲和觀眾圍繞某一個(gè)大家共同感興趣的話題進(jìn)行討論交流的論壇平臺(tái)。我認(rèn)為，公司內(nèi)部的架構(gòu)應(yīng)該能夠反映自己的用戶情況。如果你想讓全世界的用戶都來使用你的軟件，你應(yīng)該讓全世界都來幫助你開發(fā)這個(gè)軟件。
實(shí)踐時(shí)間
以GitHub為例，它的至少三分之二的員工都在全世界的不同地方辦公。再看看Word Press，它的大部分員工也都是異地辦公。這些都是深深影響了互聯(lián)網(wǎng)的成功公司的典型，它們?yōu)楹文苋〉萌绱舜蟮某晒?，我認(rèn)為讓異地辦公成為公司DNA的一部分在其中起到了至關(guān)重要的作用。
最理想的情況是，公司最初就是在異地辦公這種理念模式下創(chuàng)立起來的，異地辦公已成為公司的內(nèi)在文化基因。
展示你的工作成果VS.僅僅是人出席露面
一個(gè)員工按時(shí)上班并不能說明他在有效地開展工作。這是在公司，不是在學(xué)校。在公司看重的不是出勤，而是工作成果。
以工作成果來考核員工更為科學(xué)：
（1）一位員工本周開發(fā)出了幾項(xiàng)功能？
?。?）他一周修復(fù)了幾個(gè)bug？
（3）他一周和客戶進(jìn)行了多少次有效的交流？
?。?）他的編程速度有多快？
在Discourse，我們通常依據(jù)員工提交的工作日志來判定他工作做的是好是壞，這樣你就能對(duì)員工的工作有準(zhǔn)確的了解。在這個(gè)過程中，你可以使用一些工具，如Asana和Basecamp?？傊稽c(diǎn)：
“讓員工記錄下自己已經(jīng)完成的工作。記錄的不是"待辦事項(xiàng)"，而是"完成事項(xiàng)"”。
我不在乎員工何時(shí)來上班，不在乎他們的工作安排是怎樣的，不在乎他們?cè)诘厍虻哪膫€(gè)角落里辦公（前提是網(wǎng)絡(luò)暢通），也不在乎他們是如何開展工作的。如果你招聘的真的是最出色的員工，那么這些員工是能夠以自己的工作成果來證明自己的。
你怎么知道這是否行得通呢？當(dāng)你雇的員工發(fā)現(xiàn)產(chǎn)品有個(gè)問題，并自己主動(dòng)將問題解決的時(shí)候；當(dāng)你能夠放心地充分授權(quán)員工讓他們自行對(duì)產(chǎn)品做出改變，雖然你知道過程中他們可能會(huì)犯一些錯(cuò)誤的時(shí)候。在這些時(shí)候，你就知道這是行得通的。