曾有人问过我，“管理者什么的，跟开发人员到底有什么区别？”这两个角色都是我经历过的，但我仍花了一点时间来考虑。这个问题真的蛮重要的。
编程是从我六岁就开始的消遣。那时我写了第一个程序：从我爸爸的书里照抄了一段游戏的源代码，随即就着了迷，并且一直未曾放弃，直到编程成了我的事业。多年来，在我解决了各种有趣的或者复杂的编程问题之后，我觉得是时候去迎接新的挑战了。
但是转行就意味着放弃，放弃我多年来磨练出来的专业技能。然而，经过一番挣扎与向专业导师咨询之后，我毅然决然的跨出了这一步。
现在，干了三年半的管理，我终于有资格来回答这个问题了。管理者和开发人员最大的区别就在于衡量成功的标准不同。
具体来说:
(一) 你的成功会更琐碎
当我还是一个程序员的时候，每天来上班脑子里都会有一个工作计划，通常这天结束时，我都能完成好这个计划。这种感觉就像是每一天我都在进步。
而作为一个经理，常常在回家的时候，都不知道我那天到底干了啥。并不是我什么事都没做，只是实在没有可供衡量的结果。
身为管理者，任务之一就是帮助工程师去做改变，但改变不会是一朝一夕可以完成的，需要时间和关注。
- 你努力去实现的变化，可能模棱两可并且很难有清晰的定义。
- 要认识到需要改变，这件事本身也可能很难。
- 工程师们很难抛弃旧的习惯，需要不断的提醒他们。要改变他们的思维定势，是一件有挑战性的而且不轻松的事。
在 New Relic，我们每季度都会举办一个定期检查，用于提供一个反馈的渠道，让工作的重点放在长期的目标上。有些季度的发展可能突飞猛进，但大多数时候，会有的只是还叫不错的进步。
当团队人员真正出现大的变化时，就需要管理者不断的引导。我们经常使用的工具叫做“regular info-bits（定期的信息交流）”。具体做法是，工程师把他们工作上的进展用简短的 email 发给管理者。Email 的主题通常与专业发展，团队合作，项目更新，沟通交流和工作与生活的平衡有关。这个过程有助于他们更加系统的去思考问题，你也可以通过这些信息，获悉他们的成长。
这种做法会需要很长的时间才能看到结果，但是最终可以看到你团队的成员们建立了自信并且成长良好，你会觉得一切辛苦没有白费。
（二）你的成功有战略上的影响
好的开发者可以对企业造成巨大的长期的影响，好的经理会引导整个团队的成功。
工程上的问题常常不是黑就是白。但是人的问题，几乎总是模棱两可的。即使你知道你要解决的问题是什么，解决的方法却并不是总是那么清楚。过去你用这个方法解决了这个人的问题，不代表你就可以用它解决现在的问题。人类行为这个东西实在是有太多的变量了。
要建立一个合作无间的团队，就有一系列的挑战：
- 团队的建设并不是把一个个明星成员拼凑起来这么简单。
- 一个有凝聚力的团队需要充分理解每个人的长处和短处。
- 团队不会是一成不变的，每当有人加入或者离开，都需要重新磨合。
作为经理，你的工作是确保你的团队尽可能的高效的运行。但你不能指望稍有变动，就来一次大刀阔斧的革新，不能指望流程上动辄就做彻底的改变。有效的管理者需要：
- 不断的评估你的团队需要什么帮助。
- 注意，这个需求对于不同的工作和不同的团队可能是不一样的。
- 使用和发明正确的工具来支持你的团队。
这个关键是逐渐的变化，不断的观测，而后不断的做出改进。例如，如果你发现你的团队没能得到足够力度的支持，首先找到办法使局面不要那么混乱，而后再寻求工具来优化你的团队。和你的小伙伴们一起努力克服困难，先选择重要的问题来处理，然后回头检查这个变动是否得当。
（三）你的成功往往就是帮助别人获得成功
在 New Relic，我们相信 Invisible Manager（隐形的经理）这个理念。这意味着我们在幕后工作，让工程师站在聚光灯下，突出他们的成功。我们确信工程师应该获得荣誉，这是他们应得的。所以 New Relic 的新功能推介会，我们鼓励让团队成员站在公众面前去介绍产品，而不是产品经理或工程经理。
大多数人管理者之前都是成功的工程师。而作为一个经理，会产生更大的影响，不仅在生意上，也在员工的生活里。许多管理者会发现，帮助别人也是帮助自己成长。
先管理好你自己
对于有工程背景的我来说，专注于手头上的问题比什么都重要。在我心里总是有一个完整的计划，涵盖了团队所需要的一切：成长，动态，质量，支持，产品交付，会议，博客发表等等。我会有一个清晰的愿景：我的团队在未来一年里要成为什么样子。这有助于我做出日常的每一个决定，而最终走向我们长期的目标。
要管理好一个团队需要大量的工作。但它也带来了大量的喜悦和自豪。作为经理你能做的最好的事情就是思考。一个月一次，找一个安静的空间，去想想你团队里的每个人，去看看旧的邮件和项目报告。你会发现你的影响力，不仅加诸于你的产品，还影响了你团队里的人。这就是成功的真正标准。
本文作者Kirby Frugia，就职于SaaS服务提供商New Relic。原文载于New Relic博客。
