我是一名上市公司的技术总监，我来回答一下。

先交代一下背景：

我负责的技术团队，现在有 100 人出头。团队里包括了：前端、后端、测试、运维&DBA、还有几个客户端和 AI 工程师。

我下面分了 7 个组，每个组都有一名组长，组长们汇报给我。

我管理团队的方式，主要自己一点点总结出来的，可以说是野路子吧。

今天也不想和大家讲那些关于管理的大道理，就是列举一些小事，想到哪写到哪。

1.

第一条，也是最重要的一条就是：责权利下放给组长。

我对组长们都特别信任，他们的工作我基本不干预，更不会指手画脚。

组长们工作年头也都不短了，都有各自的优点，我没觉得我比他们厉害多少，能不管的事我就不管。尺有所短寸有所长。

另外，每个人都有每个人的管理风格对吧，没必要把我的风格强加给组长们。放手让组长们按照自己的方式去做事。事情能做成就好，和过程相比，我更关注结果。

毕竟条条大路通罗马。

在我们团队，大部分工作排期是组长排；组员的月绩效、年绩效也是组长评；组员的加薪，也是他们来定。他们定完了，我基本不再调整，毕竟组长对组员更了解。

还有技术招聘，组长们负责前几轮面试，面试意见基本都是他们定，他们来决定人选是否合适。我负责最后一轮面试，主要是替他们把把关。

因为信任，所以简单。

2.

责权利的下放，并不代表我就是一个甩手掌柜。这话怎么说呢？

重要的事情还是由我来负责的，我会和组长们一起完成，比如重大的版本升级、技术框架更新、项目的重构、故障监控和复盘……

我还会帮组长们去做一些偏外围的工作，比如我经常会问组长们有没有困难、有没有诉求。这样我在和老板、其他部门沟通的时候，能帮大家表达出去，尽量帮大家争取。

就像最近组长们反映，最好能给同事们涨涨薪，否则人员流失风险比较大，我需要做的就是和老板、HR 沟通，帮大家争取加薪的机会。

再比如，年初的时候公司定 KPI，我亲自牵头来定 KPI。定完之后我会和大家一起商量，把 KPI 分解到各个组，这样大家的工作既不会跑偏，又给他们留了空间去施展。

3.

责权利下放的基础是对大家的信任，信任的前提是我必须要了解大家。

怎么来了解你的同事呢？说一个我之前的例子。

我们部门曾经合并了一个十几个人的团队，我干的第一件事就是把那十几个人的情况先拉了一个表，包括了他们的姓名、学历、工龄、司龄、过去的绩效、晋升情况、技术特长、工资……这样，我对每个人的情况就能心里有数了。

后面工作中我再主动和他们多沟通，多了解，了解的更多更全面，才能挑出那些渴望成长、渴望承担的靠谱同事。

4.

“了解你的同事”，这句话说起来容易，但是想做好也没那么容易。

我们团队现在 100 多个人，我现在能叫出每个同事的名字。并不是因为我们认识时间有多长，即使新认识的，我也会特意的去记同事的名字。

其实吧，记 100 多个名字也是挺费劲的，记住名字还得对的上人，省的把张三叫成李四。最开始真是特意花时间去背名字，对照着工位图去背。

为什么要记大家的名字呢？再说个我的经历。之前一个领导，比我高两级，我和他平时也没啥交集。一次偶然的机会他叫出来我的名字，我当时的感觉就是“领导居然知道我的名字？”，感觉非常好。

作为管理者，你和同事无论是平时碰面还是工作中交流，能喊出来他们的名字，他们会觉得你很亲切。

另外，我始终认为，大家共事一场，能聚在一起是一种缘分，希望大家能成为朋友，比同事的关系能更深一些。程序员的圈子说小不小，说大也不大，将来指不定谁能帮谁一把，也没准还能一起再成为同事。多一个朋友，将来的路就好走一些。

5.

我和底下同事关系比较近，也是因为我对同事几乎没发过火，一年到头也没和同事拍桌子瞪眼的。

很多年前我看过一个电影，任达华演一个帮派老大，别人评价任达华演老大的时候，有一股劲——不怒而威。

我当时对“不怒而威”这四个字印象特别深刻，感觉特别酷。

我希望自己也能做到不怒而威，自己的威严不用靠着发火动怒才能体现出来。

6.

我平时在团队里也没有什么架子，办公就和大家都坐在大开间里。

我在团队里，和大家说的第一个规矩就是，别对我称呼“您”，直接说“你”；别叫我“领导”，“x 总”，喊我名字就行了。

都是同事，都是兄弟，没必要摆出一副高高在上的样子。

7.

说说上线吧。

我们这里上线都是在晚上挺晚的时候操作。团队大，项目多，几乎每周二、四都有项目要上线。按道理来说，上线有组长和同事在就可以，不需要我在公司。但实际上我都会陪着大家上线。

上线的时候，我也不去掺和，只是默默的陪着。我陪着上线的目的就是，万一上线后出现问题，需要在短时间内做决策的时候我不能不在场。

假如出现问题之后，是直接排查解决问题？还是回滚？需要我来决策。和大家一起在公司现场，我得到的信息能更全面、更及时，能迅速做决策。

另外就是我陪大家，大家会觉得有主心骨，大家心里会踏实不少。上线出现问题，不管是多严重的问题，我心里再着急，也不会表现出来，别人看我都是很镇定的样子。因为我如果慌了，大家都会跟着乱，在慌乱的情况下，可能就会做出错误的决定。

8.

你想让同事把你当朋友，必须你先主动和大家拉近距离，你自己要先坦诚一点。

我和团队里的核心同事说过：

如果你有了跳槽的念头，希望你能在离职之前两三个月告诉我，你越早告诉我越好。
一方面是我希望挽留住你，有什么不满的，咱们想法去改善。不管是因为工资、压力、还是因为其它。合理的要求，能解决的咱们尽力解决。毕竟你是核心同事了，我肯定不希望你走。你早点告诉我，在你跳槽念头还没那么强的时候，我努努力，还有希望把你留下。
如果你坚持要走，实在留不住，你早告诉我，给我多留点时间安排人手去交接工作。虽然都说对核心同事要有备岗，但是这个说法太理想了，实际中不可能每一个核心同事随时都有备岗。
就算有备岗，短时间想完全接手工作也很不容易。你早告诉我，咱们早交接，我保证不会给你们设置障碍。

起初大家听了半信半疑，离职也没提前告诉我。后来时间久了，大家知道我不是那种言行不一的人，告诉我之后不但不会为难他们，甚至有合适的机会，我还帮他们内推。

9.

我们一个系统出了一次生产故障，影响到用户使用。

事后找原因，是我们 DBA 失误操作造成的。

这次故障要扣绩效工资，当时我自己把责任全扛下来了，只扣了我个人的钱。哎，扣了我不少钱，当时挺心疼的。

其实可以同时扣我和 DBA 的绩效，这样还能少扣点我的钱。不过考虑到 DBA 平日表现挺好，因为任务比较重，一时疏忽出错了，所以就免了他们的责任。

对待下属犯错，要适当包容，谁成长过程中不犯错呢？

另外，管理者对外的时候应该保护下属，要有点护犊子的劲儿。所以上报事故的时候，锅我来背了，毕竟我更抗压一些。

虽然对外我扛责任，但是在内部，还是要关起门来批评 DBA，需要让他们吸取这次教训，避免重复出错。

10.

第 10 条凑个整。

总之吧，就像我之前文章写的：

不管是做项目，还是带团队，争取让所有涉众都满意。

我尽量让我身边的领导、老板、组长、同事都满意吧。

以上就是我带团队的方法，真的没什么大道理和套路，我就是用心去对待大家。日久见人心，时间久了大家肯定能感受到你是不是真心、是不是真诚。

你真心待人，别人也会真心待你。

我特别反感有些人把团队当做是自己升职加薪的工具。那些人经常给团队灌鸡汤，画大饼，让大家加班加点多干活，然后干出成绩来自己升职加薪。

我觉得管理者不能只会使用权力，要注重提高自己的领导力。

二、

管理结果-系统性解决问题我们先提出了五维模型体系用以评价一个leader；其次解释了其本质是对管理的认知，还没到具体案例，整个事情就已经很复杂了，这是因为管理本来就是一件复杂，并且反人性的事情！管理需要解决复杂的问题这里举个例子，在我刚刚接手一个200人研发团队时，收集了一波问题，是这样的：聚焦到团队问题，初步做下分类，做出了一张简要（简陋）的系统循环图：里面有一个负循环：新人占比高会导致更多的业务理解问题，业务理解问题越多会导致研发BUG数越多，这样会导致更多的系统事故，然后整体研发士气下降，然后导致离职率加高，然后导致更多人离职，然后导致新人占比更高......除此之外，团队之间矛盾不断，互相甩锅，大家都更专注在自己的领域形成效率竖井：长此以往，团队崩不崩不知道，但换个技术总监是必不可少的，而这里面的所有问题环环相扣，一团乱麻，这个时候就需要管理手段切入了，我们这里的解决方案是：用不同的机制，解决不同类型的问题，多数问题到最后都是人事物+目标的问题，于是形成了这张图：① 首先要回答一个问题，什么样的研发团队是好的，需要定义评价体系，得出数据指标，这个评价体系放到产品团队也是可行的。反复迭代，一旦完成数据指标要求，就能证明我们是最好的提示下：所有评价指标都可以从成本、质量、效率着手② 要打造一条人才上升通道，大概告诉大家做了什么就能得到什么，并提供相关的培训指导③ 具体到做事（做项目）层面，需要有完善的流程制度以及指导手册用以兜底④ 工程建设必须跟上，无论流程机制或者工程建设都必须长期投入才会有成果其中流程机制信息量较大，如果大家感兴趣，我们后续再探讨管理的一大工作是系统的解决复杂问题，这要求多角度的思考、多维度的方案，在复杂的场景中，简单的方案很难解决全局问题，简单方案很可能只是转移（转嫁）问题从管理的角度来说，提出了不同的机制去解决不同的问题，这里马上就会碰到其他问题：机制谁去迭代、谁去落地？这个项目凭什么会落到我手里？为了回答这个问题，我们提出另一个逻辑：势能与能力值基线。