網上很多分析大公司，小公司的文章，都會提到在大公司工作就是螺絲釘，崗位分的非常細，每個人把自己的專職工作做好就行；而在小公司需要每個人都是多面手，一崗多職。

這種觀點我同意一半，在小公司中，某些階段人手不足，確實需要每個人都做很多職責之外的事情，比如開發人員除了寫代碼，還需要測試、寫需求文檔、用戶手冊、運維等。但大公司再大，最終也會分解為很多小的團隊，從團隊最小的顆粒度來說，差別就沒那么大了。小公司的團隊想要走的更好，也需要能發揮每個人特長，職責清晰。

這樣最小顆粒度的一個團隊?Leader，卻是可以很輕松地就帶跨這個團隊。

1、什么事都不給下屬做

Leader 通常也是技術出身，從工程師做起，主動或被動走上了 Leader 的崗位，對自己的能力絕對的自信，啥事都大包大攬，手下的人卻得不到鍛煉，能力也不能提升，最終 Leader 自己累死，還沒有好的結果。

2、什么事都交給下屬做

和上面的相比，這是另一種極端，這種 Leader 可以對下屬使用到極致，也有足夠的信任，任何事情都分派出去，只注重結果，不重視過程，團隊的很多問題會在過程中被隱藏，直到某個時刻大爆發，問題發現的越晚，修復成本就越大，團隊成員士氣也會變的低落。

3、用行動上的勤奮來掩蓋戰略上的懶惰

戰略是方向，是規劃，是需要思考和花大量精力的，而行動很直接，也很容易去做，俗話說「兵來將擋水來土掩」，等出現問題再去救火，看起來都非常的忙碌，其實做的事情從長遠來看價值不大。舉個例子：

一個小公司的技術 Leader，除了本職工作外，還需要負責服務器的相關運維，但沒有去規劃磁盤、內存、CPU 的使用，有需要就在服務器上進行部署，直到發現某某環境出問題了，再安排人去排查，最終發現磁盤空間不夠，一通清理后，系統恢復正常，然后等待著下一次系統出現問題...

4、隨意地開會

會議有很多種，例行的日站會、周會、需求溝通會、下達通知的會，團隊成員間互相溝通的會等等，反正看到別的團隊開，我也組織開，感覺不組織開會就不是一個好的 Leader 。

臨時組織團隊成員到會議室，也不用準備會議大綱讓團隊成員提前熟悉，會議現場想到那就說到那，最后一問大家還有問題沒？在一片沉默后散會。

Leader ?個人喜歡傾訴，不喜歡聆聽，好好的一個溝通會，變成了 Leader 的個人演講秀，最后留給每個成員也沒多少發言的時間，零星的一些發言可能也不是內心真實的想法。

5、不關注下屬的能力

孫子兵法有講「知己知彼，百戰不殆」，西漢晁錯的《上書言兵事》也提到「卒不可用，以其將予敵也；將不知兵，以其主予敵也」。

但做到這些很麻煩，需要跟團隊成員持續保持溝通，不光是工作，還有生活上的，這樣才能了解到每個人員的性格、能力甚至是健康和家庭狀況。但 Leader 很忙啊，沒空做這些事情。所以在 Leader 分派任務的時候，也就非常隨意，做不到最優的分工。甚至當有成員提出離職時，Leader 還會覺得很詫異，我平時對你很照顧的啊，為什么還有這么多的不滿意？

6、分配任務，簡單粗暴

作為一個團隊的技術 Leader，需要將上級安排的事情，吸收消化后，準確無誤地傳達給團隊成員。在團隊中起到承上啟下的作用。

Leader 可以接收到任務后在群里簡單說明下，就讓開發人員去進行功能實現了，有沒有理解需求的意思，是否清楚真正的業務背景，不去想那么多了，按照字面意思照單全收。團隊成員有沒有理解你在群里傳達的意圖，也不用去管，都在一個團隊合作這么長時間了，這點默契肯定還是有的。

有些積極點的開發人員會主動提出自己的疑問，更多的是按照自己的意思理解去做，最終的結果可想而知。有的需求點漏掉需要補充，有的需求理解有誤需要返工，又是一片繁榮的加班景象。

7、拖延

一個開發團隊經常會有兩個奇怪的現象：

• 總是能在 Dateline 的最后時刻「搞定任務」；

• 在一個迭代的前期總是很輕松，到后期就瘋狂加班。

Leader 對自己很自信、對團隊成員也很信任，在一個迭代的前期，每天任務沒有按時完成，會覺得沒有關系，后面時間還足夠。直到臨近 Dateline ，才發現有各種各樣的問題。

最近看《長期有耐心》這本書，里面講到挪威的阿蒙森團隊和英國的斯科特團隊競爭南極探險的故事。阿蒙森團隊最后的成功，可以總結為：不管天氣好壞，堅持每天前進大概30公里。在一個極限環境里面，你不僅要做到最好，而且要做到可持續的最好，最關鍵的就是持續。斯科特團隊就是因為天氣不好就拖延，找各種借口來休息，最終全軍覆沒。

隨便嘮叨了幾句，如有雷同，交個朋友！

總結

以上是生活随笔為你收集整理的技术 Leader 怎样带跨一个团队？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。