想從技術轉管理？這些坑你可要注意了！
大概 2 年多的時間，我經歷了從一個純的技術人員轉變到一個技術管理者的歷程，所以給大家分享一下技術人如何成長成為一個管理者？
我們講技術人如何成為管理者，主要是講如何，How 這個話題，但是我自己覺得在討論如何成長為管理者之前，我們應該先想明白技術人為什么要成為管理者，這就是 Why 這個問題。
只有我們搞清楚為什么成為管理者，我們才能努力去成為管理者，成為管理者更偏向于執行，偏向于具體的工作，而想清楚 Why 是更難的。
技術人成為管理者的“理由”
就我自己來看，我覺得技術人成長為管理者有這樣一些理由。
突破個人貢獻的天花板
***個是突破個人貢獻的天花板，釋放更大的貢獻。每個公司都有自己的職位劃分，比如說百度的技術是 T 級別，管理可能是 M，產品是 P。阿里的技術是 P 級別，管理是 M 級別。
一次機會和蘋果公司的人聊，在蘋果他們只有兩種類型的級別。一種是叫做 IC，另一種是 M。IC 是 Individual Contributor 就是個人貢獻者，M 就是 Manager。
蘋果公司把一個人的類型分為個人貢獻者和非個人貢獻者，我認為他就代表著一個職位很大的特征。
一個個人貢獻者的所有貢獻產出都來自他自己，很少依賴別人，比如寫代碼，我的產出就是我一行行代碼所構成的最終產品，我做設計我的產出就是我的設計稿，我做產品我的產出就是原型圖和需求文檔。這些都是依賴個人能力貢獻出來的。
但是如果你是一個管理者的話，你的產出很多時候是很難說清楚的，你會發現，產品稿不是你做的，設計稿不是你做的，代碼也不是你寫的，但是你在做什么呢？
你做的可能是協助他們把這些給做出來，還有組織溝通和相互協調。這是另外一種工作方式，我覺得當你嘗試管理工作，他會突破你個人能力的天花板。
一個個人能力貢獻者，他的上限就是每天 24 小時不停的工作。他就算是不休息，一周也就是工作 7 天的樣子。
但是一個好的管理者的話，他可以發動身邊的團隊的人，朝著一個目標努力，他的貢獻可能是釋放了十倍百倍的。
我覺得這是一個成為管理讓人激動人心的地方，他能驅動更多人朝著一個方向努力，做出一個有更大貢獻的一個產品。
你終究需要面對管理
有些人說我就不喜歡做管理者，我就喜歡做技術，在國內其實也是這樣，有些技術人往上的職業階梯很美好，比如我們老講的阿里多隆，他成為了阿里的 11 個合伙人之一，他的級別是 P11，并成為每個人的偶像。
就算大家從一個基礎的技術者，往后做，做到架構師，做到多隆這樣的職位，你終究要面對一個事情，就是你需要管理幾個人，或者幾十個人，在技術上達到一個目標。
那個時候，你多多少少是需要和別人協調，你除了自己攻堅那些最難的問題之外，你還需要指導你下面的幾個可能幾十個技術人，大家一起朝一個方向努力。從這個角度講，技術人，即便是做技術也需要一些領導技能的。
即使你是一個架構師，你也需要 Lead 一個技術團隊。對大家來說，你的未來成長不管是走純技術路線還是走非技術路線，你都需要增長自己的管理技能。
因為到***你總歸是需要管理溝通的，很難出現你級別非常非常的高這樣的情況，但是你還不跟任何人打交道，完全靠自己的個人能力來貢獻，我幾乎沒有見到這樣的情況。
所以這是我覺得一個技術人為什么要成為管理者的原因。
技術人成為管理者的“誤區”
講完成為管理者的原因，我覺得還有一些誤區大家需要特別關注。我見到一些技術人他們想做管理者，但是當問這些技術人他們為什么要成為管理者時，我覺得他們的理由是不對的，這里我列給大家。
期望拿更高的薪水
總有人覺得管理就應該高人一等，拿的比別人多，其實不是的。很多公司技術崗和管理崗都有相應的薪資，純技術做到架構師的工資也是很高的。
在很多公司，高級技術人員的 Manager 的工資是比他低的。就是高級技術人員技術很牛逼，在業界就那幾個人能做到。
所以說你要是想拿很高的工資的話，這不是一個很好的理由，因為做純技術也能夠找到很高的回報，之后的一步步的技術提升也很高。
期望指使別人
很多人覺得做管理就是指使別人做事情，其實不是的。很多時候領導都是，負責背鍋，負責給大家抗壓力，負責擦屁股，負責端茶倒水的伺候大家的人。
我印象最深的就是我們剛剛創業的時候，我們做一個網站叫做粉筆網，但是這個網站掛了，當時這個網站有一個功能就是 PDF 預覽功能。
我們調研了一下市場上的技術，PDF 只能用 Flash 來完成，大家知道 Flash 已經是一個日落西山的技術了。
當時我們大家都覺得這個技術學了過幾年會完全沒人用的，所以當時所有人都不想做這個東西，都不想學。
那怎么辦呢？我們 CTO 去學，我們 CTO 當時就是完成我們網站上的 PDF 預覽功能。這就是一個很好的例子，他就是負責去擦屁股，去做最臟的活，最累的活，大家都不愿意去做的活。
指望更輕松的工作
很多人覺得程序員很累，我知道整個業界，整個中國互聯網大家的壓力都很大，有些公司 996 是常態。
我們公司還好，但是有時候，比如上線，改 Bug 會改到很晚，熬夜加班，大家就會覺得程序員太苦了，是不是我做管理就不用加班了呢？我也不用寫代碼了？
我之前有時候也是這么想的，后來我自己轉管理了，我發現這個想法完全是錯的。
就拿我自己來說，我之前做 iOS 開發，下班之后就完全可以去做別的事情，周末把工作的事情做完了我就可以自己看看博客，寫點東西，或者玩些別的事情，但是我發現做管理之后我的事情做不完。
總會有一堆事情堆著，每件事情也沒有一個完成的定義。所以我上班也要想著這些事，下班也得想著這些事，周末也得想著這些事。
大家發現我現在寫博客的時間比以前更短了，這就是一個很好的例子，做管理并不是一個輕松的事情。有人說技術是累體力，管理則是累心的工作，我覺得真的是這樣。
技術就單單和電腦打交道，代碼寫好，沒有 Bug 就算是做的很好。但是做管理你需要和人溝通，需要反復的和別人去交流，去解決他的問題。
很多時候做法是沒有標準的，目標也沒有最明確的，這個過程你需要非常的勞心勞力去把事情做好，這時你會非常的累。
指望更容易換工作
剛剛我們說到技術人是一個 Individual Contributor 個人貢獻者，個人貢獻者的好處就是這家公司垮了，第二天你就能找到一份好工作。
只要你的能力是足夠強的，比如你代碼寫的特別好，沒關系啊，這家公司不好，你第二天就能找到一個更滿意的公司上班，很容易，前提還是你技術是厲害的。
但是一個管理者換工作的難度是相對高的，因為很多時候你的管理能力是取決于你對這個團隊和業務的了解。
對于我來說，我能管理團隊，是因為我持續在這個團隊工作，我熟悉團隊中每一個人的性格特點，他們擅長的，不擅長的，哪些人做得好，哪些人是溫和的，哪些人是激進的。
和每個人打交道要用他喜歡的方式，我也非常了解我們產品的用戶特點。我們的用戶場景是什么，用戶行為是什么樣子的，我們為什么要做哪些功能，我們未來的產品發展方向。
大家明白嗎？這些全都是和團隊及產品相關的，如果我要換一個工作，我面對不一樣的人，不一樣的產品，我的整個管理方式可能完全都不一樣了，所以說我很難去管理一個新的團隊。
大家都知道空降一個高官是非常難的，管理者大多數時候都是從這個團隊里培養出來的，而不是空降到那里的。
對我來說除非我把整個團隊帶走，這樣是非常奇怪的。正常情況下你離職，那你很難去融入一個新的團隊，價值也很難發揮出來。所以，相對于個人貢獻者來說，一個管理者是更不容易換工作的。
所以說基于期望拿高薪，期望指使別人，期望更輕松的工作，或者更容易換工作，基于這些理由找管理工作的話是非常不合適的。講完誤區，我們來看一下技術人如何成為管理者。
如何成為管理者
時間管理
我覺得技術人轉管理的***課就是時間管理。當我們做程序員的時候，我們每天的工作都是有人給你安排好的。
可能是產品經理也可能是項目經理，他會告訴你這周你要完成一個什么樣的產品開發目標，他會把產品稿和設計稿都給你。
你會給他估計一個時間，這段時間你要做一個什么事情就已經定了，你每天做這個安排好的工作就可以，這個工作做完之后又會有新的工作過來。
對于一個純程序員來說他的時間管理是非常簡單的。他甚至不需要時間管理，他只需要每天完成別人給他的工作就好了。
但是它可能會遇到一些技術挑戰，可能會遇到一些延期，他頂多是通過加班，或者項目延期的方式來解決，他不涉及很強的自我時間管理。
但是一個管理者完全不一樣，等你管理一個團隊的時候你會發現，沒人過來說今天你要做什么，明天你要做什么，這個星期你要做什么。
所有的事情是你自己來安排，如果你去列下來你會發現你有一堆的 TO DO LIST，還有一堆人在找你，那你就需要做時間管理了。
因為你管理不好的話，你會發現你一天工作下來感覺自己累的要死。但是好像什么事情都沒做一樣，或者做的東西并不是你想做的。
所以時間管理是技術人轉管理所遇到的***個挑戰，因為他在之前的工作中并沒有得到鍛煉。
我在這上面也遇到了很大的困難，怎么辦呢？我就去看各種技術轉管理的書。
看了《管理的實踐》，《卓有成效的管理者》，《成為技術***-掌握全面解決問題的方法》，《格魯夫給經理人的***課》這幾本書，我感覺這是管理者***個需要學習的。
每本書講的角度都不一樣，但是我發現他們講的套路都是一樣的，就是換著方式在說一件事情，怎么做時間管理呢？
套路就是這四點：先記錄，然后分析，然后改進，***回顧。
具體怎么做，就是你先拿筆記錄下來，你每天的時間花費到底在哪里。比如說，你早上幾點到幾點做了哪些事情全部記錄下來。
記完之后，就可以分析了，一周下來你看到底時間花在哪里了。到底是花在和別人溝通上還是花在項目的推進上，還是花在招人上面，還是花在別的事情上面，你把它列出了之后就知道你每塊的占比是多少，然后你就可以做分析了。
我天天盯他們進度或許是不必要的，大家可能都很自覺，是不是這塊時間我可以減，你和他說你遇到問題了再來找我，如果說進度是正常的話就不用來找我了。
那你的這塊時間可能會減少，但是還是取決于你的同事的工作方式是不是讓你信賴。
通過思考你會想到一些改進的方式來優化你的時間，最終會得到一個結果，你的改進可能是讓你的時間變得更好了，或者你發現這么改不行，然后你會去重新的調整。
經過這樣的一個反復迭代，就能最終的找到一個讓自己舒服的工作節奏和工作方式。
這個就是我 2015 年底某一天寫的時間花費清單，那段時間我經常覺得自己時間很亂，然后我就專門花時間記下來，然后去分析自己的時間花費，做著做著我就發現，確實在時間管理上要好很多了。
最終我會把我的時間分成兩部分：一部分是被動時間，一部分是主動時間。
被動時間就是別人主動來找我的時間，比如說有些會議需要我去參加，有些產品稿或者設計稿需要我去評審，我會把我的時間專門在軟件上記下來。
剩下以外就是我的主動時間，主動時間我就會去想，未來三個月對于我來說最重要的事情是什么，然后我就會把我的主動時間全部花在這個上面。其他的事情我覺得不重要的我就把它忽略掉，或者交給別人來做。
接下來就會有人問了，我現在每天就是寫代碼，沒有機會做時間管理啊。我的工作都已經被別人安排好了，怎么辦呢？
這里我有一個辦法，就是可以嘗試從規劃你的個人時間開始，什么是你的個人時間呢？就是你工作之外的時間，比如說下班之后、周末這些時間你可以嘗試規劃一下。
有人說想寫博客平時沒有時間，或者是不知道怎么寫。你可以周末的時間來總結寫篇博客，或者你規劃學習一些技術或者總結一些技術。
你自己主動的嘗試去做一些時間規劃或者時間安排，看看自己執行的好不好，這就是一種自我的時間管理的嘗試。
這種事情做多了，能管理好自己的時間安排了，等你工作上從技術轉管理了在工作中也可以做好這一點。
所以我覺得大家可以從管理好個人時間開始。
學會表達
第二個就是學會表達，這個為什么要提呢？我覺得如果是一個非程序員轉管理的話可能都不用說。
比如說產品經理轉管理就不會需要這一點，因為他的工作每天都是需要和別人去講的，他需要說服別人去認同他的產品稿，還有和用戶交流，他天天都在溝通。
但是有時候我就覺得程序員做的就是一個翻譯的工作，把產品經理的產品稿翻譯成電腦能懂的東西，翻譯成一行行代碼，電腦能聽懂，能夠正確的執行。
大多數情況下面對電腦做就行了，他不涉及到人與人的交流技巧，所以說大部分的程序員都會比較悶，然后不善于表達、不善于溝通。
這和他的工作環境有關，因為他的工作就是對著電腦，所以說這方面鍛煉的少了自然就弱了。
我剛工作的時候我就特別的恐懼，我這么工作天天從早到晚都對著電腦，會不會就是以后見人都不會說話了，然后我就會刻意的去想辦法提高自己。
所以說我覺得大家如果感覺到自己在表達溝通上能力還有欠缺的話，也可以試著去彌補這方面的能力。
怎么做呢？我覺得可以嘗試著去寫作，寫點博客，做個演講，如果覺得演講這個事情是比較恐懼，你可以先試著做你們公司內部的技術分享。
甚至是不用很大的范圍，就做你們組內的技術分享，大家很熟三五個人還是可以鍛煉自己的表達能力的。
指導新人是一個很好的機會，有些人總覺得帶新人是一個很累的事情，我覺得是不對的，指導新人是一個非常好的去鍛煉自己的表達能力的機會。
每個新人的特點都不一樣，你需要針對每個人的特點，來定制針對他的個人學習和成長計劃，并且和他刻意的去溝通。這個過程就是鍛煉自己的表達能力和溝通能力。
比如我之前帶一個 iOS 新人，他就很內向，那我怎么辦呢？因為他很內向，不會主動找我問問題，我就對他說，你每天下午的 5 點到 6 點就過來找我，這就是我們討論問題的時間，我不做別的事情，你就只需要向我提問題。
這就變成我主動和他構建了一個時間來交流，他就會覺得 5 點這個時間本來就是向我提問的，他就會把當天遇到的問題主動向我溝通。
這是我自己想出來的方法，怎么去帶比較內向的遇到問題不好意思去提問的新人。你在認真的帶新人的過程中也會成長，會學到一些新的東西。
還有一點心得就是把你自己最熟悉的東西給他做，為什么這么說，因為你再寫一遍非常沒有成就感。
一樣的代碼再寫一遍就像是一樣的日子再過一遍一樣的感覺，你沒有任何的挑戰，你交給他做，他肯定會出各種問題對吧，你心里會想，哎呀！還沒有我自己做的快。
你不要這么想，你指導他成長，這個指導過程對于你來說是很有意義的。
所以說你自己很擅長的事情就不做了，交給他來做。然后你去想他在這個過程中會遇到什么問題，你提前幫他想好，他遇到的問題你跟他講清楚解決方案。
對于他來說，在做的是新的東西，還有人知道，不會出太大的差錯，他很放心，他也很開心。
然后對于你來說，你會做的事情已經不用自己做了，你也很開心。你學會了新的東西，怎么去指導別人，這是很好的技巧。
***，交朋友也是一個很好的辦法，如果你是單身的話，試著去追一個女朋友也是很好的方式。你能把自己心愛的女朋友追到手，順便你的交友技能也得到了提高，表達和溝通的技能也得到了提高。
刻意練習
特別要說一點就是以上這些都需要刻意練習，不能說我說寫博客好，那你周末就花兩個小時寫博客吧，然后每次寫都敷衍了事，把博客寫出來。如果你每次都是不求精，不求越做越好的話，你在這件事情上就很難有成長。
比如你寫博客，剛開始你寫的很爛沒關系，大家可以看我五年前寫的非常爛，我還專門看過 bang，就是那個寫 JSPatch 熱更新的作者。你去看他 10 年前寫的博客，我去翻了一下，寫的非常爛。
bang 現在的博客寫的非常厲害，排版以及整個表達。寫了 10 年了肯定厲害了，什么事情做 10 年做不好呢。
只要你堅持的寫，努力的去提高自己的技能，堅持幾年下來肯定就很厲害了，所以說你只要是刻意練習那肯定是沒有問題的。
所以說在表達上不管是寫作還是做演講還是帶新人或者是交友，你只要是刻意的在想怎么做是做的更好的，老在想這個事，老在嘗試去改進做一些不同的嘗試，這件事情肯定是能做好的。
我去看我 5 年前的博客也是寫的非常糟糕，我現在覺得我的博客還是不錯的，這就是刻意練習帶來的成效。
下一個需要做的就是偏執行的事了，管理上面的事情其實很多人都已經遇到了。有人也有總結，市面上有很多很多的書，就是需要你去花時間翻一翻那些書，看看這些人是怎么講他遇到的問題的。
其實和做技術一樣，遇到問題了就去網上搜一下。GitChat 上有沒有別人解決的，去看看書上是這么說的。
很多的時候別人也遇到了一樣的問題，并且解決的很好，你去看書上講的然后自己再實踐一遍，然后自己有所體會和收獲。
這里面有些需要注意的，***點就是看書，但是不能照搬。因為管理這個東西不像是技術，技術一就是一，二就是二，但是管理很多的時候都是偏實踐的。
每個團隊都有不用的文化，溝通方式，書上講的不一定是適合你的團隊和你個人的。
我個人推薦兩本書，***本是《格魯夫給經理人的一課》，第二本書是《成為技術***》。***本書的格魯夫是因特爾的總裁，他帶領因特爾從半導體時代轉型做 CPU。
大家知道嗎？因特爾最早不是做 CPU 的，他是做內存芯片的。大家知道日本做內存芯片基本上是處于壟斷地位的，他們被日本廠商搞的快要倒閉了。
然后格魯夫帶領因特爾轉型從內存芯片轉型做 CPU，后來的故事大家都知道了，因特爾成為芯片行業的霸主。
格魯夫帶領因特爾做了一次成功的轉型，格魯夫也是一個技術人員，他最早的時候就是一個程序員。
所以看他的書會非常的親切，他會用程序員的語言給大家講，給你列各種管理學的公式，還有各種例子，文字都非常的有條理。一眼就能看明白他在講什么，不會繞來繞去的，非常適合大家去看。
第二本書的作者也是一個技術人員，都是從程序員的角度來寫的如何管理。我覺得是非常好的兩本書，即便是你不做管理你也可以看一看，你可以看看你部門的領導是不是按著這樣的方式來管理的。
下一步就是我剛剛說的實踐了。我覺得管理就有點像是學游泳，你在岸上是怎么都學不會的，那些理論都是你實踐之后才能夠體會的。
對于你來說就是一個個的知識點，你沒辦法深有感觸。所以說***的學習方式就是實踐。
當你真正的開始帶一個新人，指導一個技術團隊，慢慢的這個團隊你管的越來越大，慢慢的你就會有各種的體會了。那才是被你吸收的一些管理能力，書上講的都是別人的。
我自己看過這六本書都很好，又《管理的實踐》、《卓有成效的管理者》、《格魯夫給經理人的***課》、《管理3.0：培養和提升敏捷領導力》、《領導梯隊》、《成為技術***》。
前兩本是德魯克的，第三本是剛剛說的格魯夫的，每本書的講法都不太一樣，總會學到一些不一樣的見解，其中有些東西就會成為你自己的。
心得體會
***講一講我的心得，說是心得其實就是遇到的坑，所以我弄了一個很大的坑在這里，掉了不少坑，這里給大家做一些分享。
不寫代碼
***個坑就是你會發現沒有時間寫代碼了。我開始的時候講了我是 2014 年底開始轉管理的，開始我還有一點時間寫代碼，但是到后面很快就沒有時間寫代碼了。
那個時候我還是幻想應該要寫點代碼，不能把技術丟了，我就給他們說，還是給我分點活吧，我少做點。
后來我發現完全做不了，因為做管理的很多時候是做協調，做協調工作就會發現別人老是過來找你，需要和你溝通，但是程序員又是需要很長時間安靜的思考的。
有個理論就是說程序員被打斷一次需要 15 分鐘才能接上上次的思路，我覺得是有道理的。
比如你剛剛想好一個邏輯，剛剛開始寫了，啪被別人打斷了，那個時候就想殺人，所以大家都說程序員大家不要輕易打擾他。程序員的工作方式是需要盡量安靜的思考，而管理的工作特點是頻繁的和人溝通。
所以我那段時間就頻繁的被人打斷，我就只能用晚上或者周末的時間來寫代碼，那樣又會影響整個項目的進度，后來我就完全不寫代碼了。
但是我還是很喜歡寫代碼的， 我就用周末的時間寫點 demo，看一些新技術做一些研究或者做一些分享，通過這種方式來學習。
但是公司的項目代碼我是完全寫不了的，這是我遇到的***個坑，嘗試邊寫代碼邊做管理工作，我發現這樣是不行的。
懷疑自己的價值
第二個坑就是迷茫，我是誰？我要做什么？管理很多時候給大家帶來的價值，或者給團隊帶來的價值會有點虛。
好像自己什么都沒做，事情都是別人做的，有一段時間我有這樣的擔心，但是后來我發現不是這樣的。
因為一個團隊每個人要過的開心，會遇到各種各樣的問題，可能是人際關系的問題，可能是溝通方式的問題，可能是和別的組協作的問題。
面對各種各樣的問題，你能幫助他把這樣的問題全部解決，讓每個人都工作的很好，很開心這是很難的。
剛才我提到的《成為技術***》的那本書，給管理的定義就是所謂的***就是要創造一個環境，讓每個人都開心的舒服的工作，發揮他***的價值。所謂的管理其實就是這個樣子，你看起來什么都不做。
但是你一旦構建出一個團隊，每個人都很舒服，很開心很高興工作沒有遇到各種問題，這其實就是你的成功和價值。
我花了很長的時間來扭轉自己的觀點，可能大家在剛剛開始管理的時候也會有這樣的問題或者困惑，看上去你每天只是動動嘴皮子，但是里面是要花很多心思的。
懂向上管理
***一個坑就是不懂的向上管理，這也是程序員本身這個職業帶來的。很多時候作為一個程序員你只需要寫代碼，把代碼寫好，你不需要去和你的老大去提什么要求。
漲工資有時候會提的，或者也不用提，你干的好他就給你漲了。但是當你管一個團隊的時候，除非你是 CEO，就算是 CEO 也會和董事會匯報。
你總是會有一個向上的管理過程，你需要向你的老大去溝通，他希望整個團隊在未來主要去解決什么問題，這就是一個向上管理的過程。
通過和老大的溝通，獲得他對整個團隊的期望和目標。也通過溝通提出你遇到的困難的和挑戰，讓他給你相應的資源和幫助，這個過程是很重要的。
剛開始帶一個團隊很可能會忽視這樣的一個過程，你可能會覺得不好意思，或者不重要，其實這是非常重要的。
在德魯克的那本書里舉過這樣一個例子：主管寫下一個目標，然后讓上司寫下他對主管的工作目標和期望，你會發現大部人寫的都不一樣，這就是缺乏溝通的一個問題。
如果沒有這個向上管理的話，你可能把整個團隊都給帶偏了，***老大會說我要的并不是這個，我要的是另外一個東西。所以說一定要做好向上管理。
每隔三個月我就會找老大聊一聊未來三個月的工作目標是什么，讓他看看有沒有問題。
最近一次溝通下來我確實發現他想的和我的不一樣，然后和他聊，最終我接受了他的觀點，這是一個很重要的過程。
***我大概總結一下，開始的時候講了成為管理者的一些好處和誤區。我分享了成為管理者的三個非常基礎的方法，一個是時間管理，一個是強化表達，***一個是看一些方法論的書。
如果你去看書的話還會發現各種各樣的技巧和方法，我覺得那些不重要，你只要記住這幾個基本的東西都能學會。
***我介紹了一些我遇到的坑，期望能夠指導大家，我覺得這件事情值得每一個程序員去嘗試去積累自己的管理能力。
不管你最終是一個架構師還是整個團隊的管理者你都會需要這樣的能力。
