导言
当下科技圈中，这样的情景屡见不鲜：一个刚刚孵化的创业团队中省去管理层，创始人负责做所有决定。随着公司认可度提高，聘用更多工程师迅速提上日程，管理的需求无法忽视 。创始人找到团队里最信任的工程师求助：“我要忙疯了。你能帮我管理一下这个小组吗？”
Twitter 前任工程部主管大卫·洛夫特尼斯(David Loftesness),就是一个“被选中”的工程师。在他20年的职业生涯里，他曾就职于包括Xmark（跨平台同步书签）, GeoWork（地质分析软件）等六个科技公司，经历了多次工程师到管理者的角色转变, 也指引了许多开发者走向他们第一个管理职位。
他将自己在这个领域的经验凝练成一个九十天计划。在这篇文章中，他将这个计划拆分至确定工作优先级，建立管理基础，评估自己的表现等方面，帮助新晋工程师管理者迅速成长并开始授权其他人的工作。
I. 你为什么需要一个计划？
“诚然，关于如何管理这个话题，各个社交平台上不计其数的博文频频涌现。然而他们普遍自相矛盾，并且缺少具体的实施要点。“ 洛夫特尼斯在提到计划必要性的时候说：”我需要的是一个有时限和进退空间的计划。这是我搭建这个从工程师到技术管理者90天计划的着手点。“
洛夫特尼斯意识到大多数科技公司都倾向于将自家工程师放在团队管理者的位置上（有时并不考虑他们的兴趣或经验）。一方面，初入管理层的工程师对工作流和公司技术的清晰理解可以在产品管理和开发上帮助他们。然而，作为一个新的领导者，他们大多对团队管理一无所知。
在一次非官方调查中，洛夫特尼斯发现每15个工程部经理，只有一人在成为管理者前接受了正规的管理培训。当让他们指出对学习管理最有帮助的几个方式中，75%选择了”试错“,其中一半的人举出了在某些具体案例中的得到的反馈，40%选择了观察同级的其他管理者。
洛夫特尼斯对这一结果深有体会。”我最开始成为管理者的时候，我至少用了半年的时间在假装自己是一个管理者。我在规划时间表的时候想的是’我猜我们需要开会...’，于是我就在时间表中留出开会的时间。我基本知识在复制我看到身边其他管理者在做的事情。“
若不正视这个问题，许多工程团队最后可能被技术大拿但同时也是领导菜鸟所管理。而这些新晋团队领导人也常常面临跟艰难的困境，临危受命的他们可能被要求去紧急补充一个重要的职位空缺，拯救一个过了交付时间的产品或者是其他的公司危机。
洛夫特尼斯的这个九十日规划可以分三个独立阶段，引领管理新人们顺利度过第一个季度。这三个阶段包括：第1~30天 建立知识体系；第31~60天 确立工作节奏 第61~90天自我评测。 但是首先，最重要的是，决定是否决定接过这个管理职位，这比大多数人想的要难很多。
Day 0 那些你不能不知道的事
大部分工程师在代码相关领域上投入了大量时间和精力，他们可能在被临危受命前从未担任过什么领导职务。发觉员工身上的潜力通常都是资深精力的工作。洛夫特尼斯说“自我从业以来，在工程师中选拔领导者主要靠直觉。但是如果这个潜在的工程师无法想象自己转换到其他和写代码无关的角色的话，这个任命也不会是成功的。” 经验发现，优秀的新经理人都曾思考并且接收这些新的事实。
#准备好从三个方向开始你的管理历程#
”两年前，一个工程师问我，‘我如何知道自己是不是准备好了？’”,回答这个问题之前，洛夫特尼斯先画了这样一幅画。
“如果你在开始的适合意识到管理包括三方面而不仅仅是看管一群软件开发者而已的话，你应该就已经准备好了。” 一个即将踏上管理岗位的程序猿应当能回答洛夫特尼斯指的这三个方面的问题：
你的团队 你能有效的领导曾是你同事的工程师们么？你真的了解你要做的工作吗？你能否为整个团队的目标承担责任？
你的同级 你能和其他的管理者和谐共事，有效沟通吗？
你的上级 你能简洁明了的向你忙碌的上级汇报项目重点？
当你的上级质疑你的项目的细节时，你是否能够熟练的回答？
洛夫特尼斯指出一个杰出的团队经理应该懂得如何和上至管理高层，下至团队成员以及同层其他管理者相处。这个计划不是一个循序渐进的指南，而是一个在最初的九十天内一定要搞定的任务清单。
“这是一个全新的工作。不要指望一些囫囵吞枣苍茫补充一些管理知识就可以称自己为管理人了。” 洛夫特尼斯说，”你队里所有人工作时是否感觉幸福，是否高效，大部分都取决于你的管理。你要为整个项目负责人，但是你不能够自己一个人做所有的事。“
作为一个经理，你不再是过山车的乘坐者，而是它的操控师。这应该让你感到兴奋不已，如果没有，或许这个职位并不适合你。
在为他人负责前，你最需要的诚实面对自己，先好好剖析一下驱使自己选择这个职位的内在动力是什么。洛夫特尼斯曾看过许多好的动力和坏的动力既能洗礼也能摧毁一个新科技管理者。下面这几项是需要注意的三要三不要：
不要为取悦领导而管理。
”为了让老板开心而无视自我的喜恶不是一个从事管理的好理由。尤其是在领导是你的朋友和同事的情况下，更难以抉择。这个时候记住，退一步，先聆听自己内心的声音。”
不要为自身职业发展前景而管理。
许多科技公司在技术和管理双方面都有各自进阶的途径。”如果你想领导一个团队，这自然是极好的，但是首先要盘观一下形势。问问自己现在是不是最佳的时机。你此时是否准备好迎接这一职位角色转变？如果在你羽翼尚未丰满的时候过早接受这一工作并搞砸了它，这并不能助你在职场上的晋升，反而会有相反的效果。”
不要因“我不上谁上”的想法而管理。
如果你之前曾扮演过“烈士”的角色，请先按下暂停键。作为一个管理者，一个团队里的“超级英雄”，你的成败起伏影响的不只你一人。洛夫特尼斯指出, 你将来是否会后悔你为团队挺身而出取决于你对自己的愿景是否了解。为团队挺身而出的想法是好的，但是如果这是驱使你选择领导的主要原因，可能并不长久。
若你重视他人的成长，请考虑管理。
”有一个夏天，我手下两个工程师刚成为团队经理。那时正是夏季新实习生涌入的季节，一个经理因被分到一个实习生抱怨不跌，认为这是一个浪费时间事；另一个工程师则将至视为一个培养未来优秀工程师的机会。“ 洛夫特尼斯指出这两位都热爱技术工作，但是好的管理者是将提高他人的工作能力当做自己的事。
若你认为自己有共情的特质，请考虑管理。
作为一个管理者，共情是需要具备的基础条件之一。”共情并不是人人具备，与生俱来的特征，我个人有一个喜欢测试它的方法。我会让候选者详细描述一次他在工作时和他人的冲突，并让他描述另外一个人的闹钟在想什么。如果他们能清楚的解释出对方想让他们做什么，这就是共情，也是一个好的管理者的标志。“
若你能给予他人你所希望获得的信任，请考虑管理。
或许最重要的一点建议就是：”不要撒谎，不要在一对一的会面中泄露敏感信息，要尝试建立而不单单是保持你的诚信”。”一个优秀的管理者就像一个好的面试官, 优秀的面试官会满足被面试者的愿望，他们会分享难忘的瞬间，有趣的故事，他们也会从被面试者中得到这些。他们明显不会霸占整个时段，通常他们给予点滴，也从对方身上收获良多。我认为这和管理者很像。询问问题，让对方知晓你发自内心的关心将会创造很多交流的空间也会逐渐建立起相互的信任。”
当你看到你的队友在挣扎的时候，你是否是最先过去伸出援手的人？这就是一个标志。
准备好向代码说再见
当你成为一个管理者，写代码，构思代码结构，做技术上的决策都不再是你的主要工作。这对于很多刚刚转型的工程师最难适应的一点。
”你可以给自已一段转型期是可行的，但是你执于现状越久，你需要蜕变成一个优秀的管理者的时间也相应越长。” 洛夫特尼斯指出“虽然说工作内容通常取决于一个公司的增长情况，考虑到需要汲取的大量知识和信息，我建议新工程师需要至少有一年的时间远离代码，专心于管理。”
想想看： 大部分工程师花了大学整四年的时间学习成为一个初级码农。为什么不用一部分时间去学习管理呢？然后再决定，你是否能从代码领域里休假离开一年。
当洛夫特尼斯说到从代码中休假，他指的是从写代码中休假。”对于一个管理者来说，阅读代码相比写代码更为重要。写代码对于一个管理者来说是一种分散注意力的行为。阅读大量人们写的代码,了解他人项目的内容和进度，以更好的对队伍进行管理。注意不要沉浸入写代码的模式中以来逃避自己的管理职责。“
洛夫特尼斯曾目睹过许多技术管理者在这一角色转变中的挣扎。” 我曾经遇到一个工程师，她理论上充分理解可能会发生的情形，但是实际上却无法身体践行。最终她发现管理是一个比想象中更大的挑战。她乐忠于观察像我和其他的管理者，看到我们每天都处理大量的邮件，会议和其他非代码性质的工作。“ 但是她没有发觉自己是多么想念码代码的时光，最终重新做回了一个独立程序媛。
和大部分的新工作一样，在任何时间最重要的任务都一定是处在非舒适区中, 也应当是如此。
“最初，在我升职到管理者的职位后，我没有立刻的停止码代码因为首先这是我熟悉的工作，其次这可以让整个项目进行的更快。但是，我也付出了相应的代价。我没有告诉我的老板某一个项目已经偏离了正规，也没有正确的对我的队员进行评估。如果我能专注进行表现评估， 我会在几个月之前炒掉一个表现不好的工程师。这在长远看来，对工程师，项目以及整个队伍都有益处。我应该早早停止写代码。”
“ 要充分的理解拐杖和方向盘的区别，”洛夫特尼斯指出一个新晋管理者如果能够履行一个”方向盘“的作用，他会做一些能让整个团队在未来能够运行的更快更好的决策。但是在进度有问题时直接冲上去自己来做这些工作，没有给周围人学习和提升的机会，那么他也只是起到一个拐杖的作用。”
“信任自己队伍的同时也要履行监督的职责.” 你不需要就看着队伍的每一个写每一行代码，但是要细心检查其中重要的部分，并提出正面或者负面的建议。“ 并且，找一些时候让他们实现一些你一开始可能并不同意的点子。这是对队员最大的信任。
“找到那些可以让新晋工程师去定义以及探索新鲜事物的时刻。如果一项任务对项目的成败只管重要，那么这不是一个好时候。然而有其他时候他们想做X，你认为他们应该做B。这个时候解释你对X,Y分别的看法和观点。让你的队员不论成败做X，是建立团队信任的良机。”
准备好向你的团队Say Hi
当大卫·洛夫特尼斯成为Twitter工程师主管后，他很早得意识到关键性的沟通比几行优良的代码对他的成功而言更加重要。“我接手了一个公司技术副总裁开发的项目，我的领导引了很多可能的方向进来，让我从大局从新审视并监督项目的进程。唯一的目标就是让这个项目成功上线。“
洛夫特尼斯干劲十足，他申请调用了额外三位工程师以保障项目进程速度达到最快。一位新加入团队的工程师问了他一些并不容易回答的关于项目背景和目标的相关问题。”一直到那个时候，我一直以为这个项目是独一无二，决定Twitter命运的项目，是不容置疑。“ 洛夫特尼斯回忆道，”直到听到那个工程师的提问，我们意识到我们搭建了了一个错误的产品并取消了这个项目。我们找到了另一个发展方式，但是这一刻对于我们团队和整个Twitter的管理队伍都是极为重要的。“
决定成为一个工程管理者意味着你的工作不再专注于代码和设计；为了更好的了解你队伍成员并能让每个人的工作达到最优化，你需要想方设法创造更多的交流机会。以下两个鲜为人知的技巧是洛夫特尼斯在聆听团队成员讲话常用的两点。
持续进行关于职业规划的谈话 “这也许不会出现在你的第一次谈话内容中，但是我认为很快你就想知道你管理的人想实现的是什么？如果有的话，他们的职业目标是什么？通常他们可能会说，“我只想做一个工程师”, 但是他们可能有些更具体的目标比如说“我想在几年后成为一个管理者”或者是说“我之后想成立一个创业公司，现在在学习我以后可能需要的只是知识。亦或者说“我希望成为一个广为人知的技术专家。“ 无论是什么，不定期的询问他们的现状是一项不容忽视的任务。
根据等级和人数来制定日程 ”每周周一早上我和我的上司开会，下午是我的整个团队的会议，第二天再接着进行1：1的谈话。这个自上而下的顺序可以保证工程师在进行工作前能够充分的理解工作内容。如果不是这种模式，我就得像挤牙膏一样一点点从我这儿或者别人那里蹦出信息。不分层的交流是最容易让一个管理者迷失的交流方式。”
如上所述，要完成从工程师到管理者的角色转变，在工作开始前都需要许多的思考，准备和战略上的思考。如果能更快的思考这些问题并想好相应的处理方法，在正式开始工作前，也能更有准备。如果听完这些你仍认为管理就是你所希冀的那条路，下面是你接下来应该做的。
Day 1-30: Own your education
如果你下定决心走向技术管理岗位，你第一个月的主要任务就是专注于你个人的学习。这三点是洛夫特尼斯重点安利的：
为你的学习预留固定的时间。没有什么能比在你的日历上明确标注出管理知识学习时间更有效的方式了。 这应是除了公司培训之外的，专门用于练习和应用你学习成果的时间段。“我是认真的。打开你的日程本，写下你的时间安排。“ 这段时间是专门用于让你成长为更优秀的管理者，你可以用这时间读管理书籍抑或是和导师聊天。” 以下书单是洛夫特尼斯推荐新任工程管理者阅读的书目：
《人件》http://book.douban.com/subject/25956450/
《人月神话》人月神话（英文版） (豆瓣)
《首先，打破一切常规》首先，打破一切常规 (豆瓣)
还有很多短篇的优秀管理方面的作者，像Spolsky(Joel on Software), Rands（http://randsinrepose.com）和Sutton（http://bobsutton.typepad.com）。不要将他们当八卦，好好利用他们丰富你自己的管理知识，如何能更好的管理自己的团队。
不要隐藏你的学习时间 新任管理者会积极从团队中汲取知识，同时也应当从其他渠道，利用其他资源充实自己。“当你预留大块时间准备用于培养自己的管理技能的时候，好好利用这块时间。” 让你的团队知悉你的时间安排，很多时候新晋管理者并不公开他们的工作时间安排，这样可能会产生团队内的时间冲突。即使在他们因此获益前，你的团队也会对你的努力心怀感恩。请明确的在你的日历上划出这段时间，可以给他起一个类似于“管理技能修炼”这种名字。
找到三两个管理导师 洛夫特尼斯带领的工程师管理者中有近一半的人都从未想到过找一个有管理经验的前辈取经。这是一个被忽视和错失的良机。“在第一个月里，向你的老板寻求导师推荐，不要让你的老板成为你的导师”，洛夫特尼斯指出“你应当已经从老板那里得到发展建议。找一个其他组里的领导者前辈，可以从不同视角给你建议。”
你会惊喜的发现，很多工程管理者对于这样的请求都极有热情。“Twitter和亚马逊都不乏乐于花时间辅导年轻管理者的主管。若你不能直接向别人询问这样导师人选的推荐，直接向公司管理岗位所有联系人发邮件，不需要什么复杂的邮件组织，可以简单的说‘ 我有一些管理方面的问题希望可以找一些前辈解答。有人有空吗？’ ”
Day 31-60: 寻找节奏
在第二个月里，你的目标就是重组你的时间表 --- 一个异于你之前作为程序猿/媛的日程规划，以寻求新的节奏。以下是工作了Loftesness和许多他的劝告其他管理人员。
取消会议。这听起来似乎有悖常理，但被无休止的会议卷入困境是对新任管理者来说最常见的陷阱。 “我认为是谨慎的 - 甚至是大幅度的 -取消会议是应尽早养成的习惯。”Loftesness说。 “当然，要有礼貌的拒绝会议的邀请，但要铭记始终保护你的时间。 “人们会邀请你参加会议，因为其他经理参加或只是广泛撒网。这很容易让你觉得有义务必须参加。我常常鼓励我的经理扪心自问：“参加这次会议是否比出完成自己的任务更加重要？”
当涉及到你手下工程师的时候，尊重并捍卫他们的判断。 “我曾有过一个同事经常向我抱怨'你知道苏珊还没有走到最后三次会议？你可以跟她谈谈吗？“这个时候我会让他知道，苏珊能够为自己做决定，如果你真的需要她出席那个会议，请自己去说服她其中的重要性。”
在保证时间最优化的前提下,继续进行严密的日程安排
在你的三十天内，你预留了时间用来不断的和你的团队进行会谈，学习如何成为一个更好的管理者。你应该接着在不影响你的工程师们的情况下，规划你的日程。“如果我需要和一个工程师进行一个简短的会议，我通常会将会议的时间订在一天一开始或是快要结束的时候，防止打断他们的创造时间。” 洛夫特尼斯指出” 早上的一个小时要比一天中间的半个小时成本要低。”
给自己建立一个“事件循环表”
“一个事件循环表是一个每天，每周，每月都需要重新审视的代办清单。这一循环的目的在于确保你在繁杂的工作中不要忽略了最重要的那些事件。每周和每月的事件循环是最艰难的，因为你并不常常思考这些问题，但是他们的重要性也不容小觑。“ 下面这个是图表是洛夫特尼斯给一个工程部管理者的事件循环例表：
最有效的运用这张表格的方式之一就是在日程表上标注出固定时间来重新审视回答这些问题。如果需要的话，你可以需要重新改时间或者延迟几天，至少这个事件循环可以给你一个提醒，让你能有机会重新调整事务的优先顺序。
处理某些具体事务时，最好不要拖延时间，回避问题。
”在招聘的期间，每日的事件循环会帮助你缕清思路。这些时候，很少有比想办法搞定一个优秀的候选人更重要的事情了。但是你很容易因为会议或其他杂事，推迟给候选人发邮件的时间。但是如果你在日程中预留出时间专门处理，你就能避免这样的问题。“
Day 61-90: 自我评估：你是否真的想要这份工作？
九十天计划中的最后一个月的重点在于诚心的自我评估自己是否希望并能胜任管理者的工作。有两方面需要额外注意：首先，你应该能够清晰阐释每个报告中的关键和发展方向。其次，你应该清楚的认识到自己是否真的希望成为一位技术经理。这里是洛夫特尼斯让他的初级经理们用来自我评估的问题：
你队伍成员每个人独一无二的特点是什么？你准备如何最好的运用它？
洛夫特尼斯从《你需要知道的那件事》(The One Thing You Need to Know (豆瓣))的作者,Marcus Buckingham, 那里借鉴了这个问题，用来衡量一个新的技术经理是否了解团队里每一个人不凡的优点。给自己一分钟来评估团队里的每一个人，说出他们的有事。接下来，你应该能够清楚具体的阐述出你准备如何最大化团队的优势让其能够助益于整个团队的表现并且能够让他们每个人都能走向自己希冀的职业路径。
“我团队里的一个工程师在设计软件结构的时候非常不走心。他总是飞快的略过设计部分然后迅速进入视线的阶段，我之后才意识到了原因。他在发现代码错误方面非常出色。“ 他在软件设计方面缺少动力对于整个团队和产品来说都是有害的，然而他自己独特的能力往往对于整个队伍和产品的工作至关重要。洛夫特尼斯因此创造了一个”消防员”的职位，这样可以让他全职的修改代码问题。
有些时候，事态并不像想象中简单易见。工程师们可能表现出的特殊才能可能对团队有帮助，但从他们的职业发展看来却并非如此。 “一位工程经理格伦，工作上非常出色。他自我意识非常清晰，并对预期的目标有很清晰的决断。 他最优秀的技能就是他能指出团队出现的关键问题，并迅速做出解决方案。有一次，他给团队的工程师写了一个条理非常清晰的代码标准，之后整个团队的效率随之有了巨大飞跃。“
格伦在团队里深受爱戴，但是他决定重新做回一个工程师。他发觉相比人事关系，他更喜欢开发代码带来的快乐，纵然他在两方面做的都非常出色。最终，洛夫特尼斯认为让格伦充满活力的呆在公司比不开心的工作并有可能从公司离开相比更为重要。
90天之后，如果你还无法回答团队每个成员的独特之处是什么的话，你很有可能没有进行有效的沟通。
反思你是否因为技能，时间或者动力上的不足未能达到预期。如果是前两个原因 ，尽快做出调整来改善现状。如果因为最后一条（缺少动力），这也是一个重要的发现，这个角色可能并不适合你。
团队是否有产出？
这个问题主要是关于团队写作的。以下几个具体问题可以帮助你回答如何衡量团队表现：
软件的质量是否有提高？
每个队员的阶段性目标是否达成？
团队的士气如何？
90 天之后，管理者应当能正确评估出所有需要改善的方面。如果他们不能立刻找出问题所在，也应当有想法如何开始着手改善。若两者皆非，可能他们并不是做管理的料。
当然，对于公司最重要的就是产出结果，但是对管理者来说了解如何完成任务和产出结果相比也是同等重要。” 充分了解他们是否达到定期目标背后的事。如果一个团队没能在截止日期前完成任务，是否是你在既定的截止日前布置了太多的工作或者因为团队的技术水平问题？我们错过了那种类型的截止日期以及为何错过。” 重要的不在于你跑了多迈，而在于你引擎的表现如何。“
你能看到你在公司的价值体现吗？
”每一个新的技术管理者都需要承担一部分责任，从减少某些领域的开支到扩大客户群体，来为公司做贡献。“ 作为一个新的管理者，你很有可能需要面临这些情况，在困境中担起更多的责任。
有时候这个切入点可以帮助你迅速在公司中有所建树，有些时候，你也会因此承担更多的压力。无论是哪种情况，九十天之后，你应当能够看到你价值的体现。如果你做了 一些当初上司推荐你到这个职位期望的改变，这可以算作这一阶段性的成功。如果没有，你需要制定一个如何改善现状的计划。
你工作日夜晚和周末工作了多久？
“一个新的技术经理可能在起步期因种种原因加班。他们可能对新的角色，新的学习空间和发展自己的团队充满热情，往往到晚上和周末都没停止工作。” 90天之后，开始问问自己：你花额外这么多时间是纯粹是自身的热情还是因为这是你的新生活？
衡量自己下班之后的工作时间是最直接测试你是否满意并愿持续扮演这个新角色的标注之一。一年之后你如何看待你还会牺牲周末时间来工作？这或许是一个能够帮你决策的因素。
与此同时，不要太早的放弃。每过两个月倾听自己内心的声音。“实际上，我只遇到过一个工程师是在转换角色后立即感到开心的。”从工程师到管理者是一个全新具有挑战性的突然转变。” 所以不要先问你做这项工作是否开心，而要问自己这个工作自己是否能够持续做下去。最开始的时候，与快乐工作相比，更现实的是在处在通往快乐的路径上。
Day 90: 决定前路
在第九十天的时候，一个新的管理者应该有足够的经验能判断自己是要勇往直前还是离开现在的领导职位。如果你没有通过，或者并不感兴趣之前九十天的种种考验，那么现在是时候离开。如果你笃定并乐于继续在这条路上前行,恭喜你~ 你的工作此时刚刚开始！
在日历上圈出第90天
洛夫特尼斯建议在你开始第一天工作的时候就在日程表上标注出第九十天的位置。“对于一个年轻的技术管理者来说，给自己设立一个目标很重要。第九十天要对是否退出做出决定。” 给自己几个小时的时间梳理思绪，静思分析，然后再用一个小时和你的上司谈话。
如果选择离开这个岗位，转换不意味着失败
不想成为一个管理者可能有很多原因，对写代码的兴趣浓厚，缺乏兴趣等。这些都是重要和正确的决定。“不要把这当成一次降职，专注于你的兴趣和优势所在。不要因为离开这个职位而丧失信心。能够及时发现不适合自己的工作，重新回到自己真正热爱的岗位是非常重要的。”
每个组织都应该在管理和技术两方面分别设有进阶的路线。“一个公司里如果管理者相对于技术人员持续处在阶级链上方是十分危险的。有能力的人无论是什么技术还是管理，都应舒适的选择自己热爱的岗位而不因此丢失在公司里的地位。对于公司来说，培养对公司运营了解充分，具有多种能力的员工对公司来说是十分重要的。”
公司应想办法减轻工程师在管理岗位过渡初期的压力。 “从第一天起，就开始创建一个安全，有效的90日技术管理者养成计划。不要把一个工程师到技术经理的过渡当成什么大不了的事。如果一个公司发布全公司的公告，为这个“升迁“祝贺，这会使得工程师陷入很难退却的地位 - 即使这对他个人和公司都是一个正确的决定。”
如果选择坚守这个岗位，还有许多要学习的东西在等着你。
如果你发现管理是适合你的工作，你还处在漫长进阶征程的最开端。下面这些是洛夫特尼斯给出的在90天之后的成长建议：
专注于增强你的优势，而不是修补你的劣势
“对于新的管理者来说，他们很容易把大部分精力花在修补他们的缺点而非增强他们的优点。然而增强优势对管理上的帮助通常要比专注劣势更大。”
区分性情和表现
”当一个新的工程师提出批判性的建议的时候，他们很容易开始批评作他们作为工程师的一些自身的性格特点。“比如说有一部分很爱讲话的大嗓门，如果他们在工作方面各有优势，你可以选择忍耐一下他们爱讲话的特点。所以你的处理方式应该是如何让这些大嗓门做自己的同事不对整个团队产生影响。”
找到能给你谏言的人
在洛夫特尼斯的整个管理盛宴中，他总能在队伍中找到能给他谏言的人。这个人应当不考虑其他因素，直接说出心中所想。“有时这个人会单独的跟你汇报，有时会在小组整体会议中当面提出质疑。你要准备能够应对这些公开的挑战。“
你需要知道随着你的资历越深，你越难听到最基层真实的想法。如果你找到了一个人能够不经筛滤的告诉你最真实的想法，你应当跟他们说”我很开心队里能有你这样的人给我真实的反馈。给你一个独特的任务，我希望能够经常听你将最近发生的事情。”这对那个人会是极大的鼓励。
无论是通过管理数据或者是导师，你都会逐渐发觉，成为一个技术管理者这个决定背后蕴藏着许多看不见的努力和付出。在90天的时间中，需要做的事情有很多。
最重要的一点就是要全心的投入管理，就像你曾经全心的专注写代码一样。参考GaiamTV的项目主管Jesse曾经的一篇博文，“我们不需要更多会写代码的设计师”。不要成为一个功能丰富多样的瑞士军刀。一个红酒行家不会使用一个迷你开瓶器，一个小锯刀也不会帮伐木匠人什么大忙。决定成为一个管理者，就一心一意执行你的计划。”
翻译：Zoey Sun
－－－－－－－－－－－－－－－－－－
欢迎大家报名翻译，转载请注明出处
关注如下我的微信公众号“董老师在硅谷”，关注硅谷趋势，一起学习成长。
继续阅读
阅读原文