“当你是一名程序员时，你只有一个高于你职位的老板给你任务。当你是一名经理时，你可以收到一个老板和你下面的几个人给你的任务。老板可以从顶端扼杀你，而下面的人会从底部掐住你。”
从普通编程岗位到工程经理，同僚会贺一句晋升之喜；放弃工程经理回归程序员起点，总有人会疑惑“你是怎么想的？”……Nick McHardy 在一篇博文中记述了自己的这场开发者体验之旅，他在担任工程经理几个月后，选择放弃继续前进，其半路掉头回归的决定在开发者中也引发了不小的讨论。
作者 | Nick McHardy
译者 | 虎说
责编 | 仲培艺
出品 | CSDN（ID：CSDNNews）
如何挑战百万年薪的人工智能！
https://edu.csdn.net/topic/ai30?utm_source=csdn_bw
以下为译文：
我担任工程经理已经有几个月时间了，现在应该是回顾整个过程的最佳时机。对于一些人来说，下面的一些观点可能是显而易见的，但也并非都适用于所有情况，我希望能够准确地描述自己的观点。
首先先介绍一下我工作的经历，我工作的公司在过去几年经历了几次重组，但最近的一次可能对我来说影响最大。这是我第一次有机会担任工程经理，从事人员管理工作。
过去的几年中，我在该公司担任的大多数角色都是设计解决方案的设计师或架构师。我习惯于与许多不同的利益相关者群体进行沟通并提供技术领导，即使我没有意识到这一点。我在过去四年间，一直致力于开发和支持各种在线和数字平台及产品，因此我所在部门的核心职责并没有真正发生重大变化。
最近重组的一个关键要素是，不再以项目的形式持续投入资源，而是作为长寿命产品来运营。
简单起见，任命了六名新工程经理，其中一半是代理职务，我便位列其中。较之我此前的职务，这是很大的晋升。我想我应该试一试这个“角色”，尤其是在高级管理人员的大力支持下，我还有机会学习新的技能。
在我的组织中，工程经理是管理工程团队的人，团队由开发人员、测试人员、运营人员以及解决方案设计人员组成。
我同意承担这个角色的一些原因是：
-
我从未经历过管理岗，想要掌握一套新的技能；
-
我对这个部门的每个人都非常了解，所以我能够在同事的支持和尊重下“完成任务”；
-
这只是一个代理职务，所以如果我不喜欢，也就不会被困入其中；
-
我将负责管理四个关键平台领域的员工：分析、搜索、身份管理和内容运营，而且这四个平台我都很熟悉。
工程经理的职位很有意思，因为我们有很多高质量的工程师，但管理人员很少。所以，我会收到 13 份直接报告，而其他人则会有多达 35 份直接报告。仅仅看数字，管理 13 个人有点令人生畏，但实际上并不是每个人都是全职员工。我的团队里面有全职、外包和兼职，每种职员都有不同的要求，从绩效管理和发展计划到合同续签流程。
我之前从未见过的新流程包括：
-
批准请假、差旅和费用索赔（限额）；
-
绩效管理、工作计划、个人发展计划和评估；
-
一对一会议；
-
Timesheeting；
-
预算；
-
招聘；
-
……
一血：拥堵的日程表
我的工作一直被一个匪夷所思的日程表所支配，这对之前的我来说可以用不可思议来描述——我每天都会有 7 个小时的会议！老实讲，“参加会议也是有钱拿的”这的确是事实，但这会也实在是太多了。
尽管我的日程已经如此紧凑，但我认为我想做的一件事就是与我的团队中的每个成员进行一对一的对话。我想每两周进行一次，持续长达一个小时，在那里我会试着倾听我的团队，而我不说话。为了使这个时间更有价值，我会在交谈过程中记笔记，每个一对一会话都有一个条目。其中一个原因是我不可能记住所有事情，而且因为我只是“代理经理”，如果需要我移交项目的话，我希望后来者可以很快熟悉整个项目的发展情况。此外，我的团队成员也对此表示赞同。笔记中没有写入任何超级机密，因为其他人可能也具有管理访问权限，所以我在这么操作时会非常谨慎。
有时你可以让 1 对 1 对话更高效些：
-
如果你的团队成员不需要，你也大可不必花费整整一小时；
-
如果定期会议是在假期，你需要重新安排；
-
你可以边散步边交谈。场地要有创意，它并不总是在会议室里。
我学到了什么
我很快发现，此前的技术经历让我在这个过程中如鱼得水。我很喜欢在这里或那里涉足一些代码，只是为了保持敏锐。这也是为什么我在实际工作之外还有其他项目的原因之一。
工程经理的职位是纯人员管理角色。这一切都是为了建立一个伟大的工程团队，而不必自己做任何技术工作。这就给许多高级技术人员提出了一个问题：
什么时候放弃编程并成为工程经理？
许多组织都有一个明确的技术轨道，一旦达到足够高的水平，通常会被特殊对待。在技术方面，我仍在研究如何与首席工程师和首席科学家等角色合作。我认为对于我们很多人来说，做出这个决定是非常艰难的，因为一旦你达到一定的技术高度，除了学习新的语言或技术之外，很难取得进一步发展。
第一次被贴上“经理人”的标签也是一种有趣的体验，实际上，我花了很长时间来适应！在我作为工程经理五个月之后，我不得不做出决定。是选择工程经理这个角色，还是回到我们的开发岗位？我有成功的机会吗？
我最后的决定
我最终选择了技术路线——不申请工程经理角色。你可能会问为什么？
我花了一点时间去考虑这个问题，并不是因为自己懒到不想更新简历去申请工作！
以下是让我作出选择的几个原因：
-
我没有多少时间做绘图或是随处写写编码（而这些是我真正喜欢的东西）；
-
我喜欢在多个解决方案和产品上工作，并希望继续下去；
-
我有很强的技术理解深度；
-
最主要的原因：我认为，凭借我的技能，作为解决方案设计师/架构师会更好。实际上，我们确实需要有人来填补这个角色，将许多系统联系在一起，以提供这些知识，以确保我们在技术上保持一致，并且不会以浪费资源的方式遗漏或重复事物。因此，我实际上可以通过不申请工程经理角色来确保继续解决方案架构师这一角色。
有时，你所工作的组织可能需要你出于战略原因而担任某个角色，但请记住：这是你的生活和事业，因此它必须为你工作。我相信我可以通过我的实质性立场实现这种平衡。
帮助公司培养人才是艰难的！但这并不意味着你不应该尝试。解决系统或计算机的问题要比解决人们的问题容易得多（至少对我而言）。了解一个人的所有的细微差别和复杂性是一个挑战，但是当你拥有一支积极进取的团队时，一切都会变得更好。
如果你有机会亲自管理人员，请务必试一试！在你尝试之前，你可能并没有真正理解所涉及的内容。有时我发现管理者这个角色也可能非常令人满意：当你能解决人们的问题时，你可以对某人的职业生涯产生真正的影响。这是一个崇高的角色，并且需要很高的技能才能成为一个更优秀的领导者。我目前还没到达那个高度，但也许有一天我也可以。
我对'技术'的认识
作为一个技术人员，你所处位置需要的领导力比你意识到的要多。这可能包括影响他人并将其带到“船上”，让他们参与进来，以及一直向他人学习。因为技术人员不仅仅需要更多关于技术上的硬实力也需要关于同理心、分析、沟通和影响他人的“软”技能。如果你可以根据各种约束条件（时间、人员、技能、预算、绩效可访问性、规矩、政策）发明最佳解决方案，那么你的团队一定会更加团结且富有战斗力。
我还发现我喜欢与工程师打成一片，在担任工程经理期间我会极力确保正在努力工作的团队成员真正受到重视。没有工程师社区文化，事情很难向前推进，这里有很多门道，如果你想很高效地和工程师们一起工作，那就并不总是坐在工作场景中审查代码或完成解决方案设计，还可能包括共进午餐或抽出时间玩棋盘游戏等，类似的沟通场景会更有效率。相互尊重是一种重要的力量，当组织“进步”成为焦点时，往往会被忽视。
我找到的一些对我有用的方法：
-
我喜欢分享解决方案并说它是“我们的”，而不是说它是我的。这是事实，因为随着解决方案的定义和发展，团队一定会参与进来；
-
如果你打算在一个组织中呆很长时间，那么专注于构建可持续的解决方案将大有裨益——自然没有人想背负上从一个项目跳到另一个项目时留下的累累技术债务，保持运营团队的参与是最重要的；
-
同时面对很多事情会带来挑战，但这意味着你可以更有效地做出决策，因为你了解更多情境；
-
平等地跨越高级管理层和工程团队可能具有挑战性，但也是有益的，因为你需要大多数人站在你这一边；
-
在大量文档（即使是正在进行的工作）中，保持开放和思维共享有助于构建完整性
Ta 说
这篇博文发出后，在开发人员当中引发了热议，下面节选部分 Hacker News 上的评论和大家分享（https://news.ycombinator.com/item?id=19186657）：
初级开发人员对这段经历的看法：
我只是一名开发人员，我非常喜欢你的建议。
然而，根据我的经验，我看到的工程经理人往往做了让公司陷入困境的事情。他们无法被委托、信任，他们有时过于骄傲和傲慢，以至于不承认别人可以做他们正在做的事情。有时事情像权力游戏一样糟糕：如果我成长一点，他们会想要从我身上获得更多。我认为工程经理如果想要有长期的发展，必须要懂得关注团队实际的成长，而不是为了赶进度而一味压迫开发人员去做事情。
高级开发人员对这段经历的看法：
作为一名高级开发人员，我非常内向，而且我熟练掌握自己应有的技巧，这样我才能够深入研究那些深度的问题。我不需要关心团队外的世界，也不需要关心我的队友。作为个人贡献者，你的成功在很大程度上取决于你贡献的质量和频率。
作为一名经理，需要更加关注团队外部的事情而不是内部，你是团队和其他外部的沟通官。
作为经理，你使用你编写代码的经验，在开发人员碰壁时帮助他们找到正确的方向，引导他们进入正确的解决方案，并为他们提供他们可能甚至不知道的资源。也就是说，经理，你无需编写任何代码即可为代码问题提供模糊的解决方案。你的编码经验允许你这样做。但是你忽略了一点：代码标准往往是高度主观的。
即使你是一名工程经理，世界上仍有许多你无法控制的人。强有力的领导者应该积极主动地尽可能保护其团队免于愚蠢，而不是让他们在你既定的标准下做事。如果标准设定高，你的团队成员会抱怨。没有强大发展背景或弱软技能的经理可能会更容易让团队满意。记住你的团队内部的职责，他们为你工作，而不是反过来。
作为经理，你应该做的事情是让你的团队比个人更有价值，从而让团队支持的产品创造更大的价值。因为如果你团队把一款非常有潜力的产品搞砸，那么你们有可能会被全部解雇。
资深高级开发人员对这段经历的看法：
当我还是一名初级程序员（约 25 年前）时，我认为成为一名工程经理会很棒。有一天，一位资深程序员告诉我他曾经担任过一段时间的经理。我很惊讶，我认为回到编码岗位是一个倒退的行为。于是，我问他为什么回去编程？
他的回答是：“当你是一名程序员时，你只有一个高于你职位的老板给你任务。当你是一名经理时，你可以收到一个老板和你下面的几个人给你的任务。老板可以从顶端扼杀你，而下面的人会从底部掐住你。”这段话对我来说很有意义。
对此，你怎么看？欢迎在评论区参与讨论，留下你的想法！
原文：https://nickmchardy.com/2019/02/on-being-an-engineering-manager.html
本文为 CSDN 翻译，如需转载，请注明来源出处。
新工具性能满分令你惊艳？
辣鸡产品毁你青春？
想卖安利为心仪项目疯狂打 Call？
程序员眼里容不得 bug，不过是想吐槽罢了！
「程序员硬核评测」专栏征稿啦！
人工智能的现状及今后发展趋势如何？
https://edu.csdn.net/topic/ai30?utm_source=csdn_bw
评你想评的！
热 文 推 荐
☞ 跨界打击, 23秒绝杀700智能合约! 41岁遗传学博士研究一年,给谷歌祭出秘密杀器！
☞ 90后美女学霸传奇人生：出身清华姚班，成斯坦福AI实验室负责人高徒
print_r('点个好看吧！');
var_dump('点个好看吧！');
NSLog(@"点个好看吧！");
System.out.println("点个好看吧！");
console.log("点个好看吧！");
print("点个好看吧！");
printf("点个好看吧！\n");
cout << "点个好看吧！" << endl;
Console.WriteLine("点个好看吧！");
fmt.Println("点个好看吧！");
Response.Write("点个好看吧！");
alert("点个好看吧！")
echo "点个好看吧！"
点击阅读原文，输入关键词，即可搜索您想要的 CSDN 文章。
喜欢就点击“好看”吧！
4347
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
