从工程师转型为管理者,意味着职业生涯的重新开始。新经理不仅要学习团队沟通、信息筛选、跨部门协作和情境切换,还要学会说“不”、建立信任,并通过团队扩大自己的影响力。

我的管理生涯,始于一场误会。
“兰兹,你在工具开发方面做得非常出色。我真心希望你能把这项工作领导起来。”
听上去,这不过是一句标准的职场赞扬:干得漂亮,继续努力。
问题是,我没有听出那个大写的“L”。
我的经理所说的,不只是让我在项目中发挥领导作用,而是要让我正式成为这项工作的负责人。他问得含糊,没有明确说明职责,也没有提供任何具体细节,但他的确发出了邀请。
两个月后,我对他说:“照现在的进度,我们下个月可能完不成。我需要更多时间。”
他一脸困惑地问:“那为什么不再招一名工程师?”
我愣住了:“等等,我有权招人吗?”
工程师通常如何成为管理者
我认为,一个人通常会通过以下三种方式成为管理者。
第一种,你主动选择管理。
“我相信自己做管理会比继续做工程师更出色,所以我选择成为管理者。”
第二种,你在不断承担责任的过程中,自然而然地成长为管理者。
我就是这样。你做出一连串看似微小的决定,承担越来越多的责任,采取越来越多具有管理性质的行动,最终有一天,你发现自己已经成了一名管理者。
第三种,你根本没有选择。
“你,去管理这支团队。现在就去。”
无论你是否拥有选择权,管理工作中都有一些事情是你必须提前了解的。
从工程师到管理者,是一次职业重启
成为管理者,几乎相当于把职业生涯彻底重启。
如果你是循序渐进地走上管理岗位,这种变化可能没有那么明显;但如果你是在毫无准备的情况下突然被委以重任,就会清楚地意识到:尽管你仍然身处同一个行业,游戏规则却已经完全改变了。
你几乎要从零开始。
你依然会用到那些曾经让你成为优秀工程师的能力,但与此同时,你还需要学习和发展一整套全新的管理能力。
这种变化最明显的时刻,通常出现在一天结束之后。
你问自己:“我今天到底做了什么?”
一个令人不安的答案浮现在脑海里:
“好像什么也没做。”
过去那种中午之前就修复十个缺陷的日子已经一去不复返了。你不会再坐在回家的公交车上继续写代码,而是会反复琢磨:怎样才能把一件重要但对方并不想听的事情说清楚?
管理工作中会有戏剧性的场面,也会有一些弥足珍贵的时刻——办公室里居然没有任何人来找你要东西。
当然,这样的时刻通常只能持续几秒钟。
新经理需要参加哪些会议
这一点你大概早就知道:管理者需要开会。
会议几乎是我的噩梦。我的个人目标一直是尽可能少参加会议,但即便如此,我还是不得不参加很多会议。
在我看来,真正有价值的会议只有两种:协调会议和创造会议。
协调会议听起来通常是这样的:
“这件东西是红色的。我们都同意它是红色的吗?很好。等等,菲尔觉得它是蓝色的。菲尔,这里有十八个极具说服力的理由,可以证明它是红色的。现在你被说服了吗?好,问题解决了吗?”
协调会议的价值,在于让所有人对目标、责任、进度和下一步行动达成共识。对于任务较多、参与者分散的团队,管理者也可以借助 Worktile 这类通用项目协作系统,将任务、项目、文档、目标和日历集中管理,减少会议结束后仍然出现“谁负责什么”的情况。
创造会议则通常是这样:
“我们需要更多蓝色。应该怎么做?菲尔,你最了解蓝色,你觉得我们该怎么办?”
当然,还有其他类型的会议,但你迟早会学会避开它们。
其中一种,是“心理治疗式会议”。
它听起来大概是这样:
“喜欢讨论蓝色的人请举手。或者红色也可以,其实我并不在乎。接下来的六十分钟,让我们一起探索自己面对颜色时的内心感受。”
随着经验增加,你会逐渐判断出哪些会议值得参加,哪些会议应该拒绝。
但在刚开始的时候,你很可能会参加所有会议。
因为你正在成为一个沟通枢纽。
管理者是团队的沟通枢纽
作为管理者,你的一项核心职责,就是成为沟通枢纽。
你不仅要为所有直接下属提供支持,还要帮助所有依赖你、需要你协调资源或推动事情的人。
这意味着,你会花大量时间坐在不同的会议室里,认真倾听,并不断在心里提出问题:
这些人是谁?
他们真正需要什么?
我理解他们的意思了吗?
我应该现在就拒绝,还是先让这件事继续发展一段时间?
令人困惑的是,管理者有时仅仅通过到场、坐下和点头,就能获得认可。
当然,把“坐在一旁点头”当成一种职业发展策略,既谈不上积极主动,也不会真正产生多少价值。
但在某些重要时刻,对方需要的确实只是一个愿意倾听的人。
你不需要立即解决问题,也不需要马上给出建议。你只需要听他们抱怨,让他们知道自己的观点已经被听见。
仅仅做到这一点,你就已经提供了帮助。
不过,你不能只负责倾听。
会议中的信息并不只是说给你个人听的,其中有些内容与你的团队有关。这意味着,你还必须具备一种非常重要的管理能力。
抽象、整合与筛选信息
在信息过载的时代,沟通当然重要。
但如果你只是把一天之内接收到的所有信息原封不动地转述给团队,那你并不是在管理,只是在充当一个机械的信息中转站。
管理者真正需要做的,是对信息进行抽象、整合和筛选。
在一场三十分钟的状态同步会议中,你要逐渐培养出一种思维过滤能力:从纷繁复杂的信息里,提炼出真正需要在团队会议上传达的三件事,并在三分钟内说清楚。
对于研发团队而言,这种能力不仅依赖管理者个人,也依赖信息能否在统一的工作环境中持续沉淀。例如,借助 PingCode 将目标、需求、项目、开发、测试和发布过程连接起来,并通过知识库记录关键决策和经验,管理者可以更容易获得完整信息,而不必依赖零散会议和人工转述。
你可能会想:
“既然我只需要知道三件事,为什么还要浪费三十分钟参加这场会议?”
首先,我完全理解你的沮丧。
其次,你需要带走的三件事,和其他参会者需要带走的三件事并不相同。
最后,如果你没能正确提炼和传递这些信息,后果通常是——还要开更多会议。
你的世界已经扩大了。
管理者需要理解不同团队的语言
公司里的每个团队,都有自己的语言、目标和需求。
作为管理者,你必须学会理解那些与你相互依赖的团队所使用的各种“公司语言”。
想想工程团队和质量保障团队之间那种健康而持续的张力。
你还记得自己曾经和质量保障同事在缺陷管理系统里争论整整一周吗?
工程团队和质量保障团队表面上使用的是同一种语言,但彼此追求的目标并不完全相同。
当你成为管理者之后,你会发现,整家公司都充斥着不同的语言和目标。
例如:
销售人员关心的是把产品卖出去,往往不太在意为了满足客户需求,产品实现起来究竟有多困难。
市场人员热衷于品牌、内容和品牌调性,并且会为一些在你看来无足轻重的细节争论不休。
技术支持人员每天都在与客户沟通,却依然常常觉得没有人真正听取他们的意见。
行政人员掌握着许多不同的“组织语言”,而且拥有的影响力通常比你想象中更大。
每个人都认为自己的工作至关重要。
每个人也都认为别人的工作相对容易。
令人困惑的是,他们往往都没有错。
这些角色之所以存在,自然有其意义。每个团队都在用不同的方式,为公司的整体运转贡献独特价值。
作为个人贡献者,你或许会嘲笑某些团队使用的古怪缩写;但作为管理者,你必须理解他们的语言。
因为只有理解他们如何表达问题,你才能真正理解他们的需求,并推动跨部门协作。
学习一种新语言并不容易,更不用说同时学习这么多种语言。
在刚开始的九十天里,你很可能会一直处于彻底的困惑之中。
而且,事情还会变得更加复杂。
因为组织里到处都是戏剧性的场面。
新经理将看到更多组织问题
周一早上,你的经理上班后做的第一件事,就是把你叫进办公室。
显然,出事了。
她让你坐下,然后说:
“我正在对组织架构做一些调整。阿曼达在工具开发方面表现得非常出色,所以我决定让她接替杰里的管理职责。我认为这样会让所有人都更容易取得成功。”
你是不是很想知道杰里到底发生了什么?
你是不是觉得自己只听到了半个真相?
错了。
你听到的可能只有全部真相的十分之一。
人是一种复杂的生物,而管理工作很大一部分内容,就是处理这些复杂性。
谁知道杰里究竟遇到了什么个人问题或职业问题,才导致这次管理层调整?
这件事未必与你有关。
但它与你的经理有关,因为管理员工正是她的职责。
作为个人贡献者,你通常只能看到经理所面对的组织矛盾和人员问题的百分之十。
我知道,了解全部真相似乎很有吸引力。但大多数时候,这些事情与你无关,也不属于你的职责范围。
而成为管理者以后,你会获得一张前排门票,近距离看到组织中几乎所有混乱、矛盾和冲突。
这也是为什么,你可能需要定期与人力资源部门沟通。他们的职责之一,就是帮助你学习如何应对这些复杂的人事问题。
而处理这些问题,还需要另一项非常关键的能力。
管理者必须学会快速切换情境
今天上午,从九点开始,你连续安排了六场三十分钟的一对一会议。
这一天原本没有什么特别,直到第四场一对一会议中,你的架构师突然提出辞职。
这个人用了十八个月时间,设计了软件最核心的功能。现在,一家创业公司开出了一大笔钱,把他挖走了。
听上去,几乎已经没有挽回的可能。
情况糟透了。
更糟糕的是,当你结束这场令人崩溃的一对一会议后,下一场会议已经开始。
你要去见质量保障负责人。
她完全不知道架构师刚刚辞职,而且她急着和你讨论缺陷管理系统。
而这正是你此刻最不想讨论的话题。
但你必须暂时放下“我们彻底完蛋了”的念头,恢复冷静和自信,全神贯注地参加眼前这场会议。
管理者会面对源源不断的挑战,而每一个挑战都可能带来完全出乎意料的问题。
你的职责,不只是妥善处理这些看上去古怪甚至荒谬的情况,还要冷静地应对它们,并做好随时迎接下一个更离奇问题的准备。
为什么管理者总会看到那么多反常、怪异的组织问题?
原因很简单。
普通、常规的问题,本来就应该由团队成员自行处理。
你真正想要的,是一支不会事无巨细地把所有问题都抛给你的团队。
但如果你真的成功建立了这样一支团队,那么最终被送到你办公室里的,往往只剩下那些最古怪、最棘手、最难以处理的问题。
当这些奇怪的球朝你飞来时,人们通常会从两个角度评价你。
第一,你是怎样处理这个问题的?
这样的事情以后还会不会再次发生?
第二,当球几乎擦着你的鼻尖飞过时,你是否依然保持镇定?
你看起来是在沉着应对,还是已经惊慌失措,随时准备转身逃跑?
领导力不仅意味着高效解决问题,也意味着通过沉着和稳定,让别人相信你不会被突如其来的变化轻易击倒。
幸运的是,你会获得一种能够控制混乱继续蔓延的重要工具。
团队管理中如何学会说“不”
“不”,是你作为管理者拥有的第二强大的工具。
无论你已经是管理者、正在考虑成为管理者,还是只是来上班赚钱,我都希望你认真想一想:当前最困扰你的问题是什么?
就是那个会在凌晨四点把你惊醒的问题。
现在,我希望你作出决定,并大声说出来:
“不。”
我们不会做这件事。
质量保障团队没有能力完成测试。
工程团队也无法按时交付。
如果我们强行尝试,就一定会失败。
而我们不能允许自己这样失败。
所以,答案是“不”。
作为个人贡献者,你同样可以说“不”。
但通常情况下,你需要先找到经理,向他详细解释为什么拒绝才是正确选择,然后由经理正式说出那个“不”。
成为管理者以后,你就成了团队中负责说“不”的人。
当组织需要采取正确行动、及时止损时,你的职责就是果断拒绝。
你要用这个“不”,保护团队免受组织混乱、不合理需求和无休止优先级变更的影响。
当然,说“不”并非没有代价。
如果你只是因为自己拥有拒绝的权力而说“不”,而不是因为拒绝确实是正确的决定,那么随着时间推移,你会逐渐变成一个控制欲极强、沉迷权力的混蛋。
不过,这毕竟是你新获得的工具。你当然可以选择如何使用它。
而且,“不”并不是你唯一可以使用的答案。
你还可以说:
管理者也需要学会说“是”
“是”,是建立关系和发展事业的起点。
它不仅是一个表达积极态度的词,更是构建行动框架、推动事情向前发展的基石。
“是的,开始行动吧。”
“是的,我知道他要离开了。现在我们该怎么办?”
“没错,我们应该尝试挑战一些大胆的目标。”
有时,你所说的“是”,甚至不应受到眼前现实的完全束缚。
它需要成为一种鼓舞,一种面对未知时的坚定判断,让别人看到你如何理解那些尚未发生的可能性。
“是的,我相信你会成为一名优秀的管理者。”
信任团队,才能扩大管理者的影响力
作为一名新经理,一旦遇到突发情况,你很容易重新退回工程师的思维模式。
你会本能地依赖那些自己最熟悉的工具,因为你理解它们,也信任它们。
但现在,你需要开始信任其他人。
也就是你的团队。
如果只能用一个词概括我的管理建议,那就是:
规模化。
作为管理者,你的职责,是把那些曾经帮助你获得这份工作的能力放大,并通过团队产生更大的影响。
过去,你是那个能够解决所有棘手缺陷的人。
现在,你要建立一支能够共同解决那些看似不可能完成的问题的团队。
你需要把自己擅长的事情提炼出来,传授给同事,并帮助他们发展出独立解决问题的能力。
而这一切,都始于一件事:
相信他们能够完成那些你过去只敢交给自己完成的工作。
建立并维护这种信任,会形成一个令人满足的生产力正向循环。
当你信任团队时,你就能扩大自己的管理影响力。
当影响力得到扩大,你就更有可能腾出时间,去做更多自己真正热爱的事情。
你做得越多,积累的成果就越多。
成果越多,获得的经验就越丰富。
经验越丰富,你能够学到的东西就越多。
而你学得越多,对管理、组织和人的理解就会越深入。
当新的机会出现时,你也就拥有了更大的成长空间。
文章包含AI辅助创作,作者:liu,如若转载,请注明出处:https://docs.pingcode.com/baike/5250504