趁着年轻

最近几年慢慢挪一些精力到团队上面，其实这方面觉得摸着石头过河，然后自己呛了一口水，也很多事情没做好，挺对不住兄弟们的。

其实非常不想提‘管理’这两个字，因为我理解谈不上谁管谁，而是大家一起努力，一起干，只是工作分工不同，有些人不得不抽时间去做一些support工作，有些人喜欢专门投入精力到coding， profiling中去而已。所以百度技术人才有T序列，和M序列的拆分。

这里写的东西大都是在平时总结或者说想到的，不要对号入座，基本上大都跟work无关，只是记录一点上下班路上的思考而已。要对就对我^.^，我就是那个反例，想到和做得到是不一样的。

当个好服务员/兄弟，而不是领导

什么意思呢？平时多想想大家的困难点在哪，主动提供帮助，至少平时别一副严肃的样子，多关心下大家，组织个TB，提醒个事情什么的，该表扬表扬，该批评适当合理的注意场合批评（这点我做的很差~）。多给大家提供帮助，做个好服务员，姿态很重要。

不要高高在上，遇到同学找你说事情的时候一定要好好听，耐心讲，千万不要先预设立场，一开始就是一副自己是正确的，我得给他指点问题才行的姿态。

平时多跟大家一起吃饭一起玩，不要做个很难接近的人，最可怕的是大家找你的时候得准备一下，得小心翼翼的来找你，那一定是你的问题了。

太过追求技术完美

有些时候技术人喜欢挑细节，会钻到某个小点上追求完美，做到极致，不这样不行。这样对技术人员可能还好，但是一旦到团队管理上，太过于追求完美反而不好，举几个例子就清楚了：

1. 产品这么设计有漏洞，如果XXX怎么办？什么？用的少，用的少就能这样了吗？ --- 有利有弊，别在不应该的地方钻牛角尖。
2. 你这功能被黑产利用了怎么办？被刷了怎么办？不行，这方案不行。 --- 黑产变成第一挡箭牌了，好搭档。
3. 这东西我知道他怎么做的，但这很low，还不如自己重写一个呢？ --- 全世界就你牛逼？老板给你发工资让你带团队造轮子呢？
4. 我们先找出根源问题吧，出问题先忍着，产品来了也没招，我在找原因呢。 --- 你就不能先保证用户体验别继续挂？

不要凡事亲力亲为，冲在最前面

很多技术出身的人都有一个特点，就是看到bug就冲动，看到好玩的技术点就跃跃欲试。而这个时候负责人往往经验丰富，做起来很快，也拥有着分配工作的权利， 所以经常奋不顾身就冲到前面去了。

最典型的就是，每次线上出问题了，第一个跑出来解决问题的往往都是你，团队的其他人还没反应过来呢，你就发了个fix diff， 完了还在群里一顿骂，骂这个怎么设计的，骂那个为什么不review，数据库怎么能这么用。 这个时候上帝可能会说，你早干嘛去了？

时刻记住一定要给大家解决问题，成长的机会，可以适当引导，找不到问题的时候提醒一下，提供必要的帮助，但千万不要什么事都帮大家干了，然后自己爽爽的，一副救世主的姿态，外加溜达一圈，这其实挺不适合大家成长的。

一定要记住，TL不是兵，你的优越感从来都不应该是自己解决了什么问题，而是团队一起解决了什么问题，大家有什么成长。
一个人的牛逼不是牛逼，团队壮大了才是你的优越感。找好定位啊。

手不要伸太长

这种情况一般出现在你管的人比较多是时候，比如线上出问题了，老板经常第一个跳出来@ 一线技术，客服群里发出问题后没几分钟，CTO 跑出来开始说“这个问题xxx看一下吧”，或者“这问题XXX 找你的人看一下吧”。 注意跨级沟通是个挺让人有压力的事情，挺郁闷的， 有以下几点：

1. 官大一级压死人啊，虽然互联网公司扁平，但多少让人有压力；
2. 不紧急的问题别整天在群里@ 人，你的话很可能大家优先级比较高，频繁打断开发很让人讨厌的；
3. 给大家个反应时间，你可以整天没事干盯着群里的消息，但是大家不行啊，知道为什么程序员晚上写代码效率最高么？
4. 你确定你还懂细节业务？确定那是个问题？

这问题归根结底是“在什么位置做什么事情，不要随意跨级沟通，除非你能提供必要的帮助，不要做那个群里的Mr.@ATer”。
送一张图体会一下：

舍不得放权

这点经常也会遇到，因为你很可能是从基础干起的，很多核心功能都是你做的，你最了解最懂这代码。然后由于这功能比较核心，不小心就会出问题，于是紧握着权限不给别人，不放心给大家去运维，去改。

最直接的例子比如： 一个服务里面的核心功能，每次线上有问题或者有bug的时候，就自己冲在前面，不给别人机会去了解，自己吭哧吭哧的在那敲代码，敲完也不发给其他人review，也不讲讲具体原因和解决办法。 最多就是“这问题我解决了，你们看一下反馈，看看监控还有没有问题吧，一个很隐蔽的问题” ， 然后就没有了，留下团队的其他人一脸懵逼~

还不用比如线上某个服务不太行了，需要升级或者换一个别的框架或者开源库。这个时候你是自己默默的去找别的框架试呢，还是让其他同学去调研，了解，评测，最后大家一起评审出一个最优的解决方案，然后让他们去搞起？第一种自己很爽，也许你会觉得你自己先选一个部署好，让大家去用更安全。其实你是错的，你完全可以做那个引导着，在评审的时候不断引申出疑问和注意点，带着大家走到正确的路上。

殊途同归，但是过程完全不一样。甚至别人比你做的更好，毕竟术业有专攻，何况大家所能付出的时间是不一样的。

要了解大部分代码，却别替别人写

这个跟放权，不要亲力亲为类似。
你应该去了解大家实现的代码，设计的功能，不然只能瞎指挥。但别把别人的事情干完了。你应该干你该干的事情。
所以扯远一点，这挺重要的，团队负责人整天冲在前面写代码，那怎么服务大家？让大家给你点赞么？其他人怎么成长？ 好的TL每天确实忙但是忙着做计划，想着怎么给大家带来帮助。

适当让大家试试新东西、服务

包括两点，别一直安排某个人做某件事情，适当轮岗换换工作，收益很大的哈，不信试试。
另外就是技术人很多都有个特点：特别喜欢尝鲜，想试试某新的开源服务。 条件允许的情况下，确实能带来一些实质的好处，其实可以支持大家适当尝鲜，适当引进新功能。当然要悠着点，别整天造轮子，别整天core了。

充分考虑大家的成长和公司需求

不扯了，我就是个反例吧可能。^.^

最后，怎么看你是不是做好了呢，简单点： 看大家平时能不能跟你打到一块去，看你哪天创业的时候，有没有人愿意跟你干。