📖 ZKIZ Archives

投資者及Board of Directors的決定及責任：Level 5 Leader還是明星領袖？ 紅猴股評

你是個好人，但不是個好Leader | 黑馬薦文

菜刀少爺 2016-09-05 09:02

本文授權轉載自微信公號菜刀少爺（ID：mrcaidao），作者菜刀少爺。

推薦星級：★★★★

閱讀時長：4分鐘 

推薦理由：你是一名CEO，但你真的是一名好的leader嗎？本文作者菜刀少爺，從另一不同視角，冷靜的分析管理者需要雙重人格：雷霆手段，菩薩心腸。內容很精彩，值得所有創業者閱讀與思考。

一

兩個月前，朋友的創業公司倒閉了。

朋友是溫文爾雅的白面君子，有著光鮮的履歷和出眾的能力。和他聊天，永遠覺得沐浴春風。溫潤如玉，充滿魅力。朋友細致而體貼。

他記得你的生日時，並在那天給發送祝福和紅包；

從大阪旅行回來，他會給你帶的白色戀人作為禮品；

對於工作不達標的下屬，他會耐心開導安慰；

他也會在眾人之下為員工顧全面子，把到嘴邊的批評指責咽進肚子。

他相信，在自由寬松的環境下，更有靈感更有效率。所以員工的上下班時間自己定：在完成任務的前提下，想來就來，想走就走。

每個人都很舒服，所有人都喜歡他。

朋友傾註了極大的心血，但在不溫不火了一年多之後，項目終於掛掉了。安慰之余，我對他說，“你是個好人，但不是個好的管理者”。

慈不帶兵，義不行賈。

二

我的第一任領導，非常犀利。

他的思路敏捷而清晰，做事務實而高效，永遠沒有廢話，永遠雷厲風行。

和他共事，絕對不會輕松。他不會講段子哄你幹活，他也不會笑瞇瞇地安撫你的情緒。

每周的例會，是一場例行考試，每個人都小心翼翼、如履薄冰。如果順利，他會扔個梗讓大家笑一笑，然後收起臉繼續挑戰你；如果不順利，他會打斷你，生生把你拍在墻上，毫不留情，但有理有據。從此，你再也不敢造次。

他不會掩藏不爽，他對愚蠢的忍耐度很低，他說變臉就變臉。如果被他認定為“不求上進”，你就成了他眼中就是個廢物，從此不會落下好臉色。

他有個口頭禪，“什麽意思”。如果他連問三遍，你的汗都會下來。

有時候，你簡直覺得，他是刻薄冷酷的資本家，是不近人情的吸血鬼。

事情的另外一面是：下屬犯下大錯、魂飛魄散，他會一起加班，收拾殘局；在家里，罵得你體無完膚，出去了，他替你出頭；他會抓住機會，向大老板進言，不斷為團隊謀取福利；他會在下屬家人過世時，額外批準兩天假期……

再就是，團隊高速運轉，業績噴薄增長。

說來有點殘酷，但事實的真相是：評判一個管理者的好壞，從來不是看測驗的民意，而是看輸出的成績。良好的幹群關系和群眾基礎，有助於達到目的，但卻不是最終目標。

一個好的經理人，就是要做出好數字，對老板負責；一個好的 CEO，就是要做高利潤或股價，對股東負責。

這才是職業的素養，這才是商業的邏輯。

就像他常說的，“我是來把事情做成的，不是來交朋友的”。

三

格雷格·波波維奇是馬刺的主帥，是名副其實的人生贏家。

他是 NBA 最成功的教練之一，是北美職業體育史的傳奇，也是美國國家隊的主教練。執掌馬刺二十年，三獲年度最佳，一千場勝利，五個總冠軍。

球場上的波波維奇，是出了名的暴君。

蠻橫，獨裁，暴躁，刻薄，六親不認，追求細節，容不得沙子……

他是最難纏的教練，他不斷的提出要求，忽略你的表現，如同你是世上最蠢的人。你犯了錯？祝你好運了。那副憤怒咆哮的嘴臉，你幾個星期都忘不掉。

他是個大混蛋，咆哮著，“打得更臟一些”；他是個混不吝，不會對任何人留下情面，不管明星球員，還是板凳替補。

球場下的波波維奇，眾所周知，一個超級逗逼，一個大大的好人。

在他的治下，馬刺成了一支歡樂奇葩的球隊。逗逼故事數不勝數，球隊氛圍令人陶醉。這里全是有天賦的人，這里充滿了對籃球的討論，簡直是籃球人的天堂。

他和弟子，彼此信任、感情深厚。有人說波波維奇是“所能遇到的內心深處最善良的人”。

在鄧肯的退役發布會上，這樣一位鐵血教頭聲音顫抖、幾度哽咽：“想和他告別不可能”。場面令人動容。

他是世界上最壞的人，他壓榨你的身體，他撕碎你的自尊，他是兇狠貪婪的吸血鬼。他又是世界上最好的人，他關心你的家庭，即使全世界拋棄了你，他還會陪著你，希望你能做到最好。

波波維奇是一個優秀的管理者樣本。成功的教練都需要具備這兩方面的性格，並在兩者間切換自如。

場上暴君，場下朋友；工作魔鬼，生活好人。

四

白崇禧教育兒子的故事挺好玩。

兒子白先敬喜歡打架，白崇禧先問，"你欺負別人，還是別人欺負你？"如果是欺負別人，兒子當場要挨頓打，然後拎著耳朵到人家里道歉。如果是被人家欺負了，他會問，“你回手了沒有？”如果沒有，這頓打挨得比前面更慘。

懂得戰爭，但不發起戰爭。

李嘉誠教育子孫：做人的最高境界是“仁慈的獅子”。仁慈是本性，但單靠仁慈，還無法成功。要有獅子的力量，才能賺錢養家，才能保護親人，才能反抗欺壓。

“做個好人”和“做個好的管理者”，其實並不沖突。

據說，柳傳誌的情商超高，接觸過他的人都被其人格魅力折服。你以為他只是個慈祥的老頭？看看他處理孫宏斌、倪光南的恩恩怨怨，那真是雷霆萬鈞、毫不猶豫。

世上最討厭的詞是“爛好人”。善良發展到極致，就是無原則的妥協。發生在歐洲大陸的暴恐事件，就是現代版的《農夫與蛇》。

要做好人，但不要做爛好人。

很多時候，做爛好人不是因為品德高尚，而是因為技術不夠。你不懂地拒絕，不懂壓力傳遞，不懂當斷則斷，不懂“扔掉背上的猴子”，不懂“揮淚斬馬謖”，不懂優雅地撕逼……

狡猾如狐貍，善良如鴿子。

五

對於我的第一任領導，我曾經也不理解：覺得他不近人情、太過苛刻。當我到了新的崗位，當我成為中堅力量，我開始感謝那段時間的高壓鍛造和紮實積累。

帶團隊不是請客吃飯。嘻嘻哈哈、舒服安逸不會有執行力；溫良恭儉、皆大歡喜不會有戰鬥力。

不要放縱紀律，不要對制度寬容，這是對員工的不負責；要幫助員工成長，提升收入，獲得更體面的生活，這是對員工最大的負責。

胡林翼曾送給晚年的曾國藩一副壽聯：“以雷霆手段，顯菩薩心腸”。曾國藩閱後百感交集、熱淚盈眶。

委屈誤解是人生的必修課，雙重人格是領袖的鐵布衫。

送給每一位管理者。

文章評論

匿名用戶

發布

全部評論：10

發布

初來乍到，如何做好創業公司的技術 Leader？

MacTalk 2017-03-27 14:22

本文由MacTalk（微信ID：sagacity-mac）授權i黑馬發布，作者虞衛東&MacTalk。

2017年3月，一段新的旅程開始了，我加入了一家新公司 —— 極客邦科技。每次到新公司，都會涉及到建立團隊的事情。二爺在杭州抱著吉他嘲笑我，辛苦兩年建團隊，一朝回到解放前。又得重來一次了吧？我說，那你吉他能彈個單弦的曲子嗎？二爺消失在了微信的時間線上。

其實每次建團隊都是一個有趣、有挑戰的新過程，就像春天里種樹，雖然時令和樹苗是一樣的，但每顆小樹的成長方式都千姿百態，因為土壤不同，空氣不同，養分不同，最後結出的果實也不同。這次就更不同一些，因為產品、技術和設計都需要理順或重建，還要能快速推出新產品，更有挑戰，也更有樂趣。

小夥伴們也沒閑著，今天極客邦旗下公眾號「聊聊架構」的主編扔給我一篇文章，是作者的投稿，說，池哥，這篇可能對你和你的讀者有幫助，你發吧。我讀完之後，感覺確實不錯，文章立意和思路都非常清晰有效，於是首發在 MacTalk，也希望你能喜歡。

作者介紹

虞衛東，新浪網高級技術經理，前趕集網移動事業部技術總監，主要供職於新浪網，經歷所有新浪博客技術演變，有十余年的互動類產品開發經驗，熟悉 LAMP 平臺 和 Python 的開發，提倡益軟件開發理論。

以下是正文。

自己閑的時候總是思考一個問題，將來有一天我成為一家創業公司的技術負責人，哪些錯誤應該是避免犯的呢？人從一種狀態到另一種狀態的時候，先思考的不應該是如何快速去做，而是如何避免犯一些錯誤，這就是本文的出發點。

首先為了避免太跑題，先設置一個限定，一個創業團隊近期融了一筆錢，需要快速的搶占市場，需要有一個技術負責人（全局負責）來帶領技術團隊更好的支持業務發展，這個創業團隊原來的技術團隊人員沒有超過 5 人。

請善待原有技術團隊

這個產品目前融資了，而原有技術團隊肯定付出了很多，也許他們技術能力並不突出，也可能聽不懂你的技術術語，也沒有做過高負載的網站。但是他們肯定足夠辛苦，因為一直在默默付出，對待他們要抱著幫助的心態，不要一上去就提出批評或者質疑，不要提擴展性、可維護性這樣很虛的概念，而要了解目前遇到了什麽難題，你能夠坐下來仔細和他們分析，並實實在在幫助解決問題，技術人員都很單純，你幫助了他們，就會服你，會尊重你。

假如技術負責人不能幫助他們，那就不要去添亂，比如用行政的命令要求他們遵守代碼規範，畫架構圖，進行代碼審查，不要有高高在上的感覺，你過來是解決問題的，而不是來生產制度的。

就算你看到了技術團隊有很多問題，也要逐步的去優化，因為在現階段，原有團隊是最了解目前的技術組成，不要全部推翻，也不要用新來的人去替代他們，尊重他們，幫助他們，才是最好的方式。

整鍋挖來一個團隊需要慎重

很多公司負責人找技術負責人的一個標準，就是看這個人的人脈，能不能找到很多技術人員，快速搭建技術團隊，這個思路其實是沒問題的，因為公司負責人需要放權，專業的事情交給專業的人去做，可是假如技術負責人招的人都是原來的朋友、同事，形成家族式技術團隊，那麽就要警惕了。

首先這個用人成本非常高，招來的人並不完全是因為技術負責人的個人魅力而來的，他需要平衡是否值得，所以高工資成為必然，當然假如確實是高水平的技術人才，這也是合理的。

其次以關系這種方式引進的員工，技術水平肯定良莠不齊，很多人因為和技術負責人良好的關系而進來的，更要命的是技術負責人引進人只是為了證明他的人脈那就危險了，所以技術負責人只要覺得一個人聽話，這個人可能就會被引進，而不是以技術能力而衡量了。

另外一般技術負責人的年齡可能不小了，而必然原來的同事年齡也不小了，可能他們原來是技術人才，可隨著年齡的提升，他們可能是個“技術管理者”，而失去了編碼能力，對於創業團隊來說這是非常不好的事情，創業團隊其實更需要業務開發人員。

家族式管理的弊端

在特定的時間，家族式管理很有用，因為技術人員任何的行為都是建立在幫助技術負責人的角度，所以幹勁會很足，對於技術負責人來說就更好了，不用動員，不用講管理技巧，只要建立兄弟之間的關系就行了，任何事情都能搞定。

假如這些兄弟確實技術能力很強，那麽技術體系可能會很好，假如技術能力不強，設計和開發出的東西沒有任何的審查，技術負債就會很多，而技術負責人本來的職責不就是掌控技術質量嗎？你完全放開，要你何用？

家族式團隊很有可能和原有團隊產生摩擦，比如原有團隊感覺受到了排擠，很有可能處處不配合，而新進團隊可能為了有更多的話語權，會搶班奪權，所以這兩個團隊就為了私利，不會專註於技術，內耗會很嚴重。

這種事情就很多，比如某個公司，新來的技術負責人帶來了自己的團隊，並且都是級別很高的職位，而老同事感覺這些人啥都不懂，什麽也解決不了，而新來的團隊又各種的變革，導致互相利益不平衡，很多老同事走了。

請先進行技術方案的設計

對於一個剛來的技術負責人來說，有許多工作，比如組建團隊、了解產品，但更重要的是設計靠譜的技術方案。

首先要了解系統存在的問題，要了解產品未來的走向，要了解技術團隊的現狀，針對這三點，你需要親自操刀，設計一個針對目前最優的技術方案。

為什麽要親自呢，因為你是技術負責人，不了解技術問題，就無法進行技術管理，親自設計了，才能有針對性的去解決問題，將來系統遇到瓶頸，就能更好的優化或者重新設計。不要用各種理由不去做這個事情，在早期這很重要。

不要過度追求專業化

其實在創業公司，一般追求小而快的概念，但是很多從大公司出來的技術負責人充滿激情，任何事情都想追求專業化，這可能會出現很多問題，這里舉幾個例子。

存在很多沒有意義的技術崗位，比如現在很多產品並沒有多少的用戶，可非要搞數據挖掘，很多數據通過簡單的 Shell 腳本就能解決，可專業的數據挖掘崗位要求並不低，從成本和效益看，並不建議有。

喜歡造輪子，在創業團隊，其實應該多用開源的解決方案，現在發現很多公司喜歡自己實現或對原有軟件做擴展，假如沒有特殊原因，應該用成熟的解決方案，原因第一就是研發成本，第二就是這個開發成本會很長，第三就是穩定性有待考量。

過度設計，就是設計的方案不結合目前的實際情況，考慮的太複雜，所以實現的也特別複雜，和造輪子一樣，也存在同樣的浪費，其實過度設計到還好，就怕錯誤設計，比如我原來單位，非覺得 MySQL 性能不好，要加一層 Memcached 緩存，最後設計並線上使用發現後，緩存命中率非常低，白白浪費了大量服務器，損耗了性能，並增加了系統的複雜性。

不要有開發語言歧視，比如前端業務層用 PHP，後端數據層用 Java，性能沒有想象的那麽誇張，這也是細分崗位的一種缺陷。

專業化的反面其實就是技術負債，上面也只是簡單的說下，有很多的最佳實踐指導，想表明的就是太專業化是對效率的最大打擊（時間、成本等等），我原來也遇到很多類似的情況，這個傷害分為兩個階段，第一階段就是短期的一錘子傷害，比如說技術方案上線了，浪費了一些時間和成本，但是這個浪費是固定的，可衡量的。第二階段就非常難衡量了，為早期的決策還債，比如說原來的技術方案上線後，後期開發特別難擴展，維護也非常困難，累計起來是對生產力的極大打擊，成本非常昂貴。

招人要慎重

關鍵詞就是數量和質量，沒有合適的情願不招。在創業團隊，項目一個接著一個，很容易造成一個假象，開發人員不夠，所以就大量的去招人，這是非常不成熟的行為，尤其假如這個技術團隊沒有太強的最佳開發實踐，新來的人員可能會很茫然，各有各的開發習慣和模式，會導致 1+1 < 2 的現象產生。人一多，分工就要細化，一細化協作就會產生一定的問題，所以招人要控制數量。

第二就是重視質量，質量這個詞每個人都有自己的標準，我核心的觀點就是情願使用一個技術底子紮實的畢業生，也不願意使用一個有多年開發經驗但無技術底蘊的人。一個沒有技術體系的開發人員總有一些瓶頸和不好的習慣，會有很多累。

不了解公司負責人

很多公司負責人找技術負責人的時候，都是求才若渴，目標就是希望這個人去搞定技術事宜，可在頭腦中並沒有衡量標準，一切都是變化的。

對於一個技術負責人來說，可以天天和他聊，告訴他架構的重要性，人員的重要性，這些確實很重要，但並非必要性，對於公司負責人來說他其實就關註開發速度、穩定性、產出，他並不關心深層次的技術內部是如何運轉的。

舉個我遇到的情況，原來一個同事去一個公司做負責人，他天天搭基礎，優化系統，後來不知道什麽原因走了，而產品負責人這麽評價他「來這麽久一個產品也沒上線」。這個例子對技術人員應該很具有打擊性。

不要有求必應

和技術合作最多的就是產品人員，個人覺得產品人員思維有點發散，做任何事情都比較著急，天天思考這個功能，那個功能；一個簡單的數據需求就問技術要不要弄個後臺出來。反正一刻也不會讓你閑著。

對於一個成熟的技術負責人來說，不能什麽都快速答應，因為這是對自己的傷害，第一開發人員就算多一倍也會不夠，需求會源源不斷的來；第二產品人員很多情況會考慮不成熟，假如你完全按照他們說的去設計，方案會非常複雜，有的時候邏輯性也會顯得有問題，會讓系統很難有效的持續運轉。第三有時候人工完成的時間比開發一個系統完成的時間少得多，所以少開發一些無意義的腳本或後臺，比如剛開始產品人員覺得這個數據很重要，過了幾天就會突然覺得沒用了。

這樣的例子很多很多，我的意思並不是不去配合產品人員，而是從自己專業角度出發，給出合理的意見，當然需要避免激化矛盾。

不要依賴測試

在創業團隊，由於開發時間要求特別高，開發人員在評估時間的時候，特別喜歡加上測試時間，等同於拿測試時間完成其開發時間，這是一種非常不好的行為。比如說一個項目開發時間要 5天，測試時間要 5 天。看上去好像開發時間只占一半（開發人員好像很高效），但實際上測試時間開發人員肯定還在開發，給測試人員的是一個半成品。另外開發人員知道有測試人員會測試出問題、會把關，初期的開發質量肯定不高，這種案列見過很多。

所以不要變現的用測試時間彌補開發時間，有可能的話，開發人員自己負責測試，當然這個實際操作起來有困難。

這篇文章有點偏理論，每個公司有其特殊的情況，中心想表達的思想就是先考慮不犯錯，然後再考慮更好的改進；在創業早期，追求輕量而不是重量；技術成本非常昂貴，需要效率。

在這個高速發展的互聯網時代，人們總是喜歡快中求快，希望站在別人的肩膀上做自己的架構。很多開發者和架構師花了大量時間研究知名公司的企業架構，把這些資料當個寶，但拿回家後發現並不是那麽回事。究其原因，只能說是參考的架構實踐太多，但了解和領悟的架構知識太少。

道是事物發展的本質規律，術是事物發展的具體途徑。《架構漫談》系列文章其實就是想和大家聊聊架構之道，希望大家能領悟架構的本質，不拘泥於現有的實踐和理論框框，而是以最直接的方式解決問題，無招勝有招。

文章評論

匿名用戶

發布

全部評論：10

發布