读:当上管理者后容易犯的五个错误
Camille Fournier(《The Manager's Path》作者)写过一篇短文 (How New Managers Fail Individual Contributors),讲新管理者在带技术团队时常犯的错误。很多公司已经有了独立的技术线和管理线,但技术骨干仍然觉得不转管理就没前途。Fournier 认为问题的起点在新管理者身上:他们刚从技术岗转型,自己都没搞明白技术线怎么走,却要带想走这条路的人。
不肯放手技术决策
新管理者通常刚从 IC(个人贡献者,Individual Contributor)或技术负责人岗位转型,对技术细节还非常熟悉,经常会不自主的自己做出技术决策。小团队这么做没问题,但如果一直把技术决策攥在自己手里,团队成员就没有空间去成长和承担责任。
你的团队可能人手不够,其他人沟通能力或项目管理经验不如你。但如果你每次都替他们填坑,很快就会碰到两个瓶颈:一是你自己忙不过来,没法带更大的团队;二是你找不到可以委以重任的人。
包揽项目管理
小团队阶段,管理者确实适合承担大部分项目管理工作。但从技术线晋升的角度看,高级工程师需要的不只是解决技术难题,还要能把方案拆成里程碑、拆成多人协作的子项目。
教人做项目管理很痛苦,对方可能不情愿、会抱怨。但这是你能为他们晋升做的最有价值的事之一。培养出既能做技术设计又能管项目的技术负责人,你自己也就腾出了精力去承担更大的职责。
不给反馈
很多新管理者给技术反馈时毫无心理负担,代码写得不好直接指出来。但在协作方式、沟通风格、主人公意识这些非技术领域,就不太敢开口了。
团队成员只收到技术层面的批评,其他方面没人管。这传递了一个信号:技术权威只有管理者才有,技术线的人没有话语权。
怎么改正呢?先搞清楚公司对高级工程师的技术能力和非技术能力分别有什么期望,然后围绕这两方面给团队设目标。这样反馈有明确的职业发展背景,更容易被接受。
囤积信息
当了管理者之后,你会比团队里任何人都更了解全局:更多的会议、更多的上级沟通、更多的外部信息。但如果你只是把任务和工单往下传,不给背景和上下文,团队就会觉得自己只是"干活的",你才是"拿主意的"。
沉迷个人产出
管理者的产出看的是团队整体,不是你自己写了多少代码。你选择做的事和选择放掉的事,都会被放大。
如果你继续把精力放在自己的技术贡献上,团队的产出就被限制在你的时间表里。每次都是你的代码救了项目,那你对团队的价值只是加法:多了你一个人的产能。当你转向提升团队整体能力,给他们足够的上下文自己做决定,你的价值就变成了乘法。他们变得更不依赖你亲自动手,你的时间就释放出来了。
说到底,管理者的核心价值是杠杆效应:通过委派技术工作和培养团队,用一个人的精力撬动整个团队的产出。如果你发现自己心里始终放不下代码和系统,也许你真正该走的是技术线。