國慶過后，最侄訓是做出了決定，告別兄弟們，離開這家呆了兩年多的創業公司，作為最早期的核心人員，我經歷了公司專案從零搭建，上線，迭代，最終作為某國家級考試指定平臺的整個歷程，不過老實說，公司過的并不好，幾輪融資的失敗，原始股東信心的逐漸下降，資金始終是最頭大的問題，作為技術，融資不是我們所能左右的，但是回顧過去，還是想記錄一些學習到的知識，主要是對技術經理這個職位的介紹，以及我的經歷和感想，希望和大家交流，

技術經理、技術總監、CTO

首先可能還是有人不清楚技術經理、技術總監、CTO三者分別是什么，大致描述下，

當程式員入行4/5年，變得更禿更強，開始邁向高級程式員乃至架構師之后，或多或少會接觸一些管理，此時的你可能深受boss的信任，擁有自主招人、辭人、績效考核等等核心權力，同時也負責著專案內的任務分派、質量管理等作業，負責了一個team內的各種具體事情了，此刻你的角色就是技術/研發經理(下統稱技術經理)，技術經理我認為帶的團隊最多也不要超過10人，一般的產品線負責大概7、8個人左右（根據具體情況），

隨著公司的日漸發展，當研發團隊壯大到20+或存在多條產品線時，可能帶隊的技術總監就已經有多名，此刻可以設定一名技術總監，向下對整個研發部門負責，向上對接leader，中間對平行部門進行業務協調，

CTO需要有強大的前瞻性思維，他決定了整個團隊/公司的前進方向，這個方向并不體現在某個team業務中的技術選型、架構判斷，而是領域的選擇，某種程度上，他決定的是公司的業務發展方向（特別是技術型公司），他需要對新技術有著超前的敏感，并以此驅動整個企業新的產品戰略和商業戰略，搞不好影響的是整個行業更有甚者可能直接創造出一個行業，

對于廣大程式員來說，邁向管理崗的第一步就是技術經理了，

公司鐵三角：產品 技術 業務

產品 、技術、業務是一個公司最基本最主要的三部分，以我的個人經歷看，在一般的小公司/創業公司，業務為第一導向：初創老板本身自帶領域資本，這個資本可能是錢，是某項技術，或者是某個領域的關系，而這些衍生出來的業務實際上幾乎決定了這家公司未來的一切，

產品是業務的翻譯：產品經理是boss本身，又或者額外有產品經理，實際職能只是boss需求分析者 or boss需求翻譯器，在這種情況下，技術是更加沒有存在感的，

理想型的情況應當是產品、技術、業務互補協同，但實際上這種情況在小公司并不存在，只有在稍大型的互聯網公司，產品乃至技術才擁有一定的話語權，

技術經理的職責

做好事情，帶好隊伍，搞好文化

如果此時此刻，公司決定讓你去成為team的技術經理，你首先得明確，有關這個團隊的一切，多少都開始與你有關了，

首先，做事是第一位：從一線開發或者某個高級程式員轉為技術經理后，首先要確保的仍然是開發需求的完成，

其次，團隊負責人是你，你需要帶好隊伍，這包含很多因素，比如團隊的績效制度，職責體系的確立，晉升體系的確立等等，

然后是隊伍文化，并不是大公司才會談所謂的文化，往低了說，一些共同信仰，基本共識和整體性格，是無論什么團隊都具備的，

做事情

首先作為技術經理，你需要做的事情有哪些:

自我職責確認

分派開發任務；提升代碼質量；專案管理；團隊管理（招人績效等方面）；這些事情都需要你來著手做，

思維的改變

技術經理更注重于架構決策和保持技術敏感，技術經理比小弟少了很多一線code time（只是少不是無），一線的作業交出去，做架構決策，架構升級，對比和參考新技術，

我見過把自己累的要死的技術經理，小弟遇到的問題你可以去引導，去提供思路，但是絕對不要親手幫他完成這個模塊自己寫，

無可厚非的是，作為技術經理，你的技術水平才是決定小弟是否信服的標準，小弟只看你技術，但是此刻你需要側重的是架構決策，并培養技術敏感度，對于小弟的問題，確保給出方向正確的思路，引導他完成任務，其實對于高級程式員來說，哪怕你側重后端or前端，只要明確了問題的正確解決思路+百度or谷歌，哪怕是不同方向的問題，依然可以比較容易的解決，這涉及到一些基本功，能解決問題，哪怕是能用好搜索引擎，也是一種能力，我見過連搜索的key words都提煉不好的，

不斷的學習

技術經理其實需要的能力有很多，技術經理在我看來另一個角色可能是低配版的產品，因此基本的產品經理的思維是要具備的，需要對業務具備洞察力（一定的產品思維），小公司沒有專案管理DMO，你就是專案管理者，分派任務，估算工時，風險評估你得來（基礎的專案管理能力），小公司沒有資料分析師，你得具備資料思維，去通過業務資料的例外變化分析問題和預測（基礎的資料分析思維），向上管理即和boss打交道，同級別跨部門的協作，需要你的人情世故，說到底，產品需要賺錢，鐵三角中的產品甚至業務也需要你的建議并參與決策（商業思維），

帶隊度

帶隊即帶人：招人、培養人、淘汰人，

招聘人

隊伍的前提得先招人，當然，很多IT屆破怕滾動多少年的老手來說，本身就有一定的圈子可以“呼朋引伴”直接拉起一支熟悉又有戰斗力的隊伍，技術經理一般配合公司hr做好這件事情，但這個程序是非常漫長痛苦的，招一個不合適的人，人產生的問題，需要更多的成本去解決這個問題甚至這個人，然后開始回圈；

招聘的時候技術經理得根據業務算好配比，比如粗略舉個例子 產品：前端：后端：測驗 1：2：4：1 這種比例，

在招人的時候往往容易忽略層次配比，這和上面的業務結構配比不一樣，比如你手頭隊伍有7、8個人（純技術方向），你得確保能核心技術骨干2名（大概阿里P6級？），其次也能扛起某塊業務的，能比較不錯完成任務的成員3、4名（P5？），剩下幾個可能是基礎的CRUD型別的（P4？），這種結構健康在個別成員的替換性不會影響整個team的健康性，且整個team內部技術仍然具有很大的提升空間，

培養人

從招人、確定他的職責，引領他融入team的文化或者往小了說，team氛圍中后，其實整個團隊就可以開始運轉了，一般的小公司也確實是這樣做的，但作為技術經理，無論是為了個人以后的發展還是公司以后的發展，心中得預留一份職責體系的存在，并在發展到適當規模時引入，

職責體系的確立往往在技術團隊壯大到50人以上的規模，下圖是阿里的P技術崗和M管理崗的級別劃分，

職責體系的確立，從員工層面，為其提供了上升通道，其實也是一種激勵措施，畢竟晉升意味著加工資，但晉升考核的原則依然需要技術經理參與評定，評定標準比如：所創造的企業價值、個人的成長、態度上的積極主動、原則上如沒有觸碰公司紅線等等，其次一般大公司晉升也需要進行一次答辯來具體評判，

職責體系的確立也為招人提供了明確的對比參照，我的經歷中，一些小公司的招聘，面試官特別是初級的面試官，盡管水平達到了該崗位的要求甚至超出，但是并沒有豐富到足以彈性地改變自己來有效測量出不同水平不同層次應聘者的真實能力的，具體體現在一組面試題，不管誰來面試都是問這些，在有了職責體系后，不同級別的劃分顯得清晰，可以直接根據需要確定招聘崗位的級別，并考察對應級別內的應試者能力，

職責體系也包含了責任體系，其中最重要的肯定是重大事故的懲罰制度的確立，這一點具體制度方面我不是很熟悉，但最侄訓是看你給公司造成了多少錢的損失來評估事故等級，

淘汰人

沒開過人的技術經理不是好技術經理，

當然從個人情感上，肯定是不想開除任何一個人的，但是由于公司或者團隊又或者個人能力上的各種因素，技術經理這個職責需要你承擔這個角色，好好說就行了，人情世故，

文化

企業文化不談，從一個技術經理出發，你應該需要建立或者影響這個team的團隊文化，我不是想說很虛的東西，舉幾個例子：

學習文化：團隊內部是否有持續有頻率的分享；

幫帶文化：團隊內部老人帶新人的風氣；

做事原則：對自我的要求，比如代碼風格上，比如你的責任心原則心上…

從前我也以為很多的所謂“文化”是扯淡，也確實很多人形式上在“扯淡”，這種文化的形成是內部順其自然順水推舟的，而不是強迫性命令性的從上層開始形成的，

其次這種文化的潛在作用可能非常容易被輕視：通過一些分享，team可以保持對前沿技術的關注；分享不一定需要你對最新最難的技術有了不起的認知，也可以是同事彼此的作業，比如你是后端，我是前端，彼此做一些不同方向的分享，這對保持了技術深度探究的程式員來說，也是一個廣度擴展的良機，team應該提供這種機會和氛圍，讓成員成長，這種型別的分享還有一個好處就是，team成員能快速了解彼此手頭在做的事情，在有了不同擅長領域的溝通后，增強了團隊內作業內容的可交叉和人員的可替換性，分享看似浪費時間，反過來確可以兜底團隊文化甚至團隊水平；再比如check list，這也是一種良好文化的體現，往小了說其實就是一些日常的習慣或者細節，

我個人非常喜歡分享這種形式，但是作為一個技術經理，你可能需要考慮更多分享前的規劃：確認找的人是有責任心、愿意思考復盤、且有分享欲望，分享的內容是什么，給分享者的激勵…

一些感想

我作為早期的核心參與者，經歷了兩家創業公司，也許是成功來之不易，所以只能多從失敗中去多思考，

技術

一個產品的失敗有很多因素，作為技識訓者技術團隊管理者，在創業團隊早期承受的壓力是比較大的，很多時候，不僅是產品經理或者boss，自己技術團隊內的任何一個人都可以依據自己的理解來指出產品上技術實作上的某點不足，技術經常背鍋是常態，“用戶體驗”是產品的核心，可以被任何一個人掛在嘴邊，來指責你所實作的產品的話題，因為人人都是用戶，這點正確嘛？正確，這是產品存活的關鍵嘛？我認為不是！

市面上（專指國內），其實我很難找到某項app所實作的功能是完全無法復刻的，換言之，技術無法實作的產品很少很少（當然暫不討論一些AI大資料類的專技術指向型公司），在我看來，國內大部分公司，包括最小也是最廣大的創業型公司，技術其實永遠不是短板，一個產品或者業務體系中，技識訓本是處于領先地位的，

從技術人的角度去看，技術可以不斷進步，產品也可以不斷優化，用戶體驗我也可以一點一點地哪怕花80%的精力去提升5%點地方的細節來優化用戶體驗，但是以我的經歷，產品或者業務的失敗與技術關系真不大，

市場

很多賺錢的業務，可能沒什么技術，

你的商業模型中真的需要一款重型的app？公眾號、小程式、乃至抖音快手b站，哪個都可以作為渠道去嗅探市場，一個真正切合市場的業務，其實不需要多么高深的技術，以風口豬理論為例，在風口下，只要你做出來的東西能跑，你就能賺錢，這時候技術人喜歡的類似于性能優化需要嘛？需要，也重要！但這并不能讓產品或者公司活下去，

運營

模式是運營出來的，不是技術開發出來的，

產品的商業模式，是運營出來的，我不知道在哪里看到的這句話，不過在經歷過一些事后，這句話深深地印在我腦海中，在我看來，任何一家非技術型的公司，運營的投入都是要遠大于技術的，

其他

創業公司，在基本盤業務上，不運營用戶，不做商業資料分析，不采集用戶的問題和建議，僅僅是領導層作為用戶覺得某個方向可以深挖，并且自恰出一套邏輯，這套邏輯或許可行，但是沒有經過嚴格預案和深入的調研（往往這一步也并不被重視），交于了產品，產品此刻也只是boss需求的翻譯器，開始根據老板的需要，設計原型 開始 -> 開發 -> 測驗 -> 上線…，上線之后由于沒有配套的運營方案，大部分也只能根據自有的稀少的自然流量，去產生這個新功能（或者這項新業務）的體驗用戶，轉換量極低，整個團隊一個月的作業可能最終只服務到極小部分用戶，且不產生創收，此刻領導層可能覺得效果并不理想，并已經醞釀出了另一個自恰的邏輯…這是死亡回圈的開始…

參考

CTO職責鐵三角：商業、技術、團隊