网上很多分析大公司，小公司的文章，都会提到在大公司工作就是螺丝钉，岗位分的非常细，每个人把自己的专职工作做好就行；而在小公司需要每个人都是多面手，一岗多职。

这种观点我同意一半，在小公司中，某些阶段人手不足，确实需要每个人都做很多职责之外的事情，比如开发人员除了写代码，还需要测试、写需求文档、用户手册、运维等。但大公司再大，最终也会分解为很多小的团队，从团队最小的颗粒度来说，差别就没那么大了。小公司的团队想要走的更好，也需要能发挥每个人特长，职责清晰。

这样最小颗粒度的一个团队 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公里。在一个极限环境里面，你不仅要做到最好，而且要做到可持续的最好，最关键的就是持续。斯科特团队就是因为天气不好就拖延，找各种借口来休息，最终全军覆没。

随便唠叨了几句，如有雷同，交个朋友！