1、缘起：

因自己所从事职业的缘故，对IT行业的技术人员是如何思考的、以及技术管理者们是如何行使管理行为的，需要保持充分好奇，并且最好能详实真切的感同身受

本书旨在帮助那些有意愿从IC岗位转型管理岗位的IT技术人员，在公司中逐步发挥出领导作用，能通过技术管理的手段推动公司走向卓越。书籍的内容非常实在，作者把自己的亲身经历和思考几乎一五一十的做了呈现，虽然难免有阴差阳错的个体偏差，但整体而言覆盖了如何在基层做好员工、如何作为技术小组长培养新人、如何作为技术经理引领团队、以及如何作为技术高层管理者（CTO或工程副总裁）辅助公司制定技术战略、搭建高效团队和培育工程师文化等诸多场景。作为技术管理的扫盲书籍，足够了

2、内容精述：

（1）公开发表正面反馈是一个众所周知的优秀管理手段：这样可以让全体团队成员及时地认可某个成员的工作，同时也有助于让团队成员明确优秀工作的标准是什么。团队经理应该向你解释你的个人工作与更广阔的团队和公司目标之间的联系，以帮助团队成员在日常工作中体验到成就感和自身工作的价值、意义

（2）做好导师，这里最重要的技能是倾听、沟通、设定目标，根据实习生的情况因地制宜、灵活调整。无论是直接管理，还是间接管理，人都是不善于精准表达自己想法的。如果你发现人们在明知道你的技术能力很强，却不愿意来寻求你的帮助的时候，就应该及时反省自己了

（3）作为一个技术小组长，你需要同时承担软件工程师、系统架构师、业务分析师的职责，以及一个知道什么时候自己去完成任务、什么时候该委派其他人完成任务的团队领导。技术小组长不仅仅需要继续交付高质量的代码，还需要承担起作为技术代表与管理层合作的职责；不仅要参与项目交付进度表的制定，还要承担一定程度的项目管理职责。技术小组长是一个管理岗位，需要承担一个技术研发团队的管理工作，同时需要至少花30%的时间与团队一起交付代码。这恰恰就是这个职位不应该默认由团队内最资深、技术能力最强的工程师来担任的原因

（4）优秀技术小组长的秘诀：如果你想要对自己的工作项目有更强的掌控能力，或者想让自己的工作更灵活，就必须学会管理和分配时间。更重要的是，这意味着你常常需要限制自己在那些熟知并且喜爱的事情（比如，编写代码）上面花费时间，而要去做那些自己感觉无从下手的工作。技术小组长核心要做的事儿：理解系统架构、维持团队关系、主导技术决策过程、对内沟通和对外沟通

（5）在管理岗位上做久了，那些“技术能力不够强”的人是很难继续在管理岗位上寻求晋升的

（6）关于一对一会议：同理心很强的领导，有时难于与下属保持合理的距离。而其与下属过于亲密往往是不健康的。当你发现自己将过多的精力用于倾听下属的吐槽和“卖惨”时，往往可能说明你正在让事态恶化。再追加一条建议：在共享文档里保存记录，而且管理者要亲自做会议记录。为自己的每一个管理对象维护一个动态的共享文档，里面有一对一会议产生的现场记录、灵感启发和待办事项

（7）事必躬亲的管理者是难以维系一个好团队的。当自身的自主性被剥夺时，有创造力、有才华的员工会很快丧失前进的动力。任何事情都不能自己拿主意，芝麻大的小事都要被上司一而再再而三地督查，是其在工作中最糟糕的感觉了。

（8）如果你预期中颇有潜力的人最终并没有成功，难免让人失望；但越早从失望中走出来，就能越早把注意力转移到团队中真正有希望的未来之星身上，并充分开发他们的潜能。

（9）很多公司都要求员工先要做出更好的表现，满足下一职级的标准后才能升职。这种做法明显是为了避免出现“彼得原理”（不断被升职的员工最终总会被升到一个自己不再胜任的职位）现象而设的。

（10）不管沟通渠道如何改变，信息的流动并没有减少。对个人来说，聊天工具里的一条条滚动消息会使你更容易分心。

（11）一个需要管理多个团队的管理者，如果能在团队内部构建一种高效的会议文化，就会节省很多时间。管理者应该利用合理的办法来保障与会者提前做好准备。管理者参与这些会议的一大部分目标就是关注团队内部的士气和沟通流程。一个健康的团队富有活力，且团队成员会积极参与会议。一个不开心或失去目标的团队则会让人感觉无聊或疲惫。

（12）管理者的主要工作之一，就是为团队成员创造一个高效工作的环境，并能支持下属取得工作成绩。作为一个管理者，你应该尝试多利用“好的，这样的话……”的句式与上级领导和同级同事进行沟通。相信你很快就能发现，这种句式可以将双方的分歧转化为对项目优先级的讨论。

（13）现在这个时代，能否定期发布代码是衡量研发团队健康度的一个最明显指标。

（14）团队领导一定要对本团队针对公司内部其他部门的排外现象防微杜渐。即使是一个问题团队，你也一定要切记，公司能够成长到这个阶段必定有这个团队的贡献。在按照自己的想法大幅调整团队之前，一定要学习、了解公司内部的文化与特点，思考如何构建一个与公司文化相符而非相左的团队文化。最好的做法往往不是修正有问题的部分，而是识别团队的优势，并且继续鼓励团队在这方面发展。

（15）管理者要专注于以下两点：识别有价值的工作，以及按时回家。这就是“懒惰”与“不耐烦”原则。只要聚焦在重要的工作上，就一定可以按时回家，所以我们鼓励大家按时回家，这样就可以鼓励大家随时聚焦于自己的工作。这就是一个优秀团队扩大自己工作成效的办法。作为工程师，我们将自己的工作自动化的目的就是为了能聚焦在更有意思的事情上——有意思的工作就是那些需要大量思考的工作，并不是那些可以长年累月、日日重复的工作。作为一个团队管理者，你在遇到低效率的事情时就应该提出疑问：为什么这件事处理起来这么低效？做这件事到底能产生什么价值？是否有达到这个目的的更快方法？是否可以将这件事简化，以便提高处理速度？强迫自己脱离工作，是维持良好的精神状态的关键。

（16）安迪格鲁夫将管理工作划分为以下四大类：信息收集和共享、督促、决策、做好表率

（17）CTO一职必须关注和理解公司业务，需要能从技术的角度来影响和指引公司业务的发展。CTO可以在公司产品战略之中，识别出可以通过应用技术为公司创造或扩展业务线的机会。即使不这样做，CTO也可以确保公司的技术不断发展，以便能够应对未来的业务和产品路线图。不管怎样，CTO必须能够理解公司目前最大的技术机遇和技术挑战，并且抓住这些稍纵即逝的机会。

（18）作为管理者，自己需要重复说明一件事多次，或者需要以多种不同的方式说同一件事，才能让大家理解。在一个大型组织中，沟通是最大的问题。基于我的亲身经验，一件事至少要说三次，听众才会把这件事记住

（19）团队成员彼此缺乏信任，是团队协作问题的根源

（20）有时也许有跟手下某个与自己关系特别好的人发泄一下工作难处的冲动，但这是非常不合适的

（21）如果你希望自己的团队敢于承担风险，甚至直面失败，那么一个核心前提就是，团队成员需要感觉到归属感与安全感。如果你肯花一点时间探寻其背后的原因，往往最后会发现，反对往往只是不理解的一种表达方式

（22）一个复杂但有效的系统往往是从一个有效的简单系统演化而来的。一个从头设计的复杂系统是不可能正常运行的，再怎么修补也无济于事。必须从一个可以运行的简单系统开始。失败发生的地方，正是对组织架构变革应该从哪里入手进行调查和识别的最佳位置。

（23）具有讽刺意味的是，虽然运气在成功和失败中扮演着相同的角色，但人们往往会将失败的原因归结为坏运气，而将成功的原因归结为自己的行动。

（24）友谊不应该是选择工作伙伴的重要参考因素。我曾经和不会在工作之外闲聊几小时的人保持着很好的工作关系，而和愿意被一起困在机场的人的工作关系却很糟糕

（25）最后一个建议，要始终尝试从其他人的视角想问题：他们这样做的目的是什么？他们最看重什么？他们想要什么，又真的需要什么？这些建议，往往都可以归结为“保持好奇心”

3、自我评估工具表：

关于管理基础的自我评估：

你曾经共事过的直属经理中有过“好”经理吗？

他们做的哪些事对你有帮助？

你和直属经理的一对一会议多久举行一次？

在一对一会议中你是否提出了自己的议题？

如果你的会议内容是汇报工作，那么是否可以尝试用其他方式来汇报工作？

你可以和自己的直属经理分享自己生活的重要进展吗？

你的直属经理是否和你有良好的私人关系？

你的直属经理有没有向你提供工作方面的反馈？这些反馈有效吗？还是他从来没有向你提供过什么反馈？

你的直属经理是否帮助你设定了今年工作的目标？

关于技术辅导的自我评估：

公司是否有实习生项目？如果有，你是否可以主动报名，成为实习生导师？

公司对新人入职的关注程度如何？

是否给新人指派了导师？

如果没有，你是否可以向自己的经理自荐来承担一定的辅导工作？

你是否有一个优秀的导师？

这个人的哪些做法让你觉得可圈可点？

这个导师是如何帮助你学习的？

他教会了你哪些东西？

你是否体验过那些效果不好的培训？

那些培训为什么没能很好地帮助你？

未来如何做可以避免这种问题重现？

作为技术小组长的自我评估：

你的组织内部是否有技术小组长一职？如果有，是否有明确的职务定义？如果有，内容是什么？如果没有的话，你会怎么定义这个职位？其他人怎么去定义？

如果考虑担任技术小组长一职，你做好挑战自我的准备了吗？你是否愿意在写代码之外，花时间做非技术类工作？你是否对系统代码足够了解，能否从技术上领导其他人？

你是否和上级领导沟通过，他对技术小组长一职的期待是什么？

你合作过的最优秀的技术小组长是谁？他的优势在哪里？

在你的职业生涯中，最难合作的技术小组长是谁？与他合作难在哪里？

管理员工的自我评估：

是否安排了与下属定期的一对一会议？

上次和下属讨论其职业目标是什么时候？如果距现在已超过三个月，你能保证在下次一对一会议上不漏掉这项内容吗？

上周是否给过下属反馈？上次当众表扬团队成员是什么时候？

上次有人做出需要纠正的失当行为是什么时候？提供纠正性反馈，你用了多长时间？这种反馈，你是私下提供的，还是公开提供的？

回忆一下，你自己有没有收到过完全没用的绩效考核报告？是缺失了什么，让它价值降低的呢？

你接受过的最有用的绩效考核是哪次？评价结果是如何传达给你的？

你知道公司的员工升职流程如何运转吗？如果不知道，能找个人给你从头讲解一遍吗？

作为团队经理的自我评估：

成为团队经理之后的新职责有哪些？承担这些新职责的同时，你将哪些旧的职责交给了其他人去承担？

作为团队经理，你是否了解在团队的日常工作中，书写代码、发布软件，以及运维现有系统的流程和难点？

你的团队是否能够持续地成功交付业务需求？

作为团队经理，你上一次亲自交付业务需求是什么时候？你上一次处理系统运维问题是什么时候？你上一次和某个团队成员一起结伴处理难点问题是什么时候？

是否团队中的大部分问题均是由一两个团队成员引起的？你准备如何解决此类问题？

团队成员之间的沟通是否顺畅？在团队召开会议时，大家是否都面带笑容？团队聊天频道中能不能看到大家互相开玩笑？团队成员是否会一起吃午饭，或者喝咖啡？上一次大家坐在一起闲聊而不谈工作是什么时候？

你的团队是如何做决策的？团队中是否建立起了一个决策流程和对应的职责定义？哪些决定是由团队经理来亲自负责的？

针对已交付的需求，是否有一个检验是否达到项目目标的复盘评审流程？上一次你亲自参与的复盘工作是什么时候？

团队成员是否明白业务需求的来源，以及自己承担这些业务需求的原因？

上一次你亲自参与的业务需求裁剪是什么时候？决定是否裁剪业务需求时，你参照了哪些信息？

管理多个团队的自我评估：

上一次审查自己的日程表，识别低价值工作是什么时候？回顾之前几周，再展望未来几周。自己有哪些成就，以及接下来准备做成什么事情。

如果你仍然参与代码开发，那么在自己的日程表中是否留有时间？是否要加班？加班的目的是什么？

上一次委派给团队成员的任务是什么？是简单任务，还是复杂任务？团队成员处理得如何？

团队中有领导潜力的人是谁？你是否有辅导他们接受更多管理职责的计划？什么样的任务可以委派给他们，以培养其领导技能？

团队中的编码工作、发布工作、运维工作是否进展顺利？上次服务出现故障是什么时候？团队处理故障的过程如何？现有流程是否能够应对这些意外情况？

上一次推动团队裁剪项目需求是什么时候？在裁剪项目需求时，牺牲的是功能需求，还是代码质量，抑或两者均有所牺牲？该决策是如何做出的？

你上一次在工作日的晚上8点之后或周末发邮件是什么时候？收件人是否回复了该邮件？这个及时回复是否有必要？

管理中层经理的自我评估：

隔级沟通（隔级会议）多久进行一次？是采取一对一会议的形式，还是团体会议的形式？你是如何主动和团队沟通的？你上次主动获取信息，而不仅仅被动接收信息是什么时候？你上次参加团队会议是什么时候？

在不看现有文档的情况下，写出目前你期待手下研发经理完成的工作职责有哪些。——其工作职责有哪些？——你多久评估一次其工作成果？——在你看来，其哪些方面的工作是最重要的？

现在，看看目前公司招聘中层管理者所使用的职位介绍，你写的几条内容与此是否有出入？根据现在的职位介绍，哪些部分在你对这些经理进行招聘考查时被忽视了？

最后，你可以在脑海中快速过一下目前自己下属的绩效。其哪些方面需要辅导和培养？确保自己在下次的一对一会议时讨论这些话题。

如果你需要管理一个在自己技术能力之外的团队，那么你上一次审查这个团队是否工作正常是什么时候？你是否花时间从该下属处了解了该工作成功的要素有哪些？在过去的三个月内，你学到了哪些新东西，以便更好地理解该团队的工作？

如果你自己的某个团队明显比其他团队工作得好，那么在团队内部流程上二者有什么区别？对外沟通方面又如何？是不是该团队经理与其他人的工作方式不同？团队与该经理如何协作，以及该经理与你之间如何协作？

目前中层经理的招聘流程如何？在招聘过程中，你是否和候选人沟通过他们的个人价值观及其信奉的管理哲学？团队成员是参与了他们未来经理的招聘流程，还是完全不参与该招聘流程？你是否花时间对候选人进行了背景调查？

本季度的组织架构目标是什么？本年度的目标是什么？你目前是如何将产品目标（如果有的话）和技术目标相结合的？在你自己的组织中，是否有上级安排的目标，团队是否了解这个目标？

职业经理人的自我评估：

在当前这个管理阶段，你所能接受的辅导与培训很大程度上来自公司之外的人。你将不再有其他上级了，只有一个老板。你是否有职业教练，不管是公司提供的，还是自己付费聘请的？即使公司不提供，这也是一个很好的投资。这种教练可以为你提供指导和直接反馈。和你的朋友不同，这些人都是以听你诉说为生的。

在职业教练之外，你是否有公司之外的交际圈？是否认识自己领域外的其他资深经理？维持一个交际圈，可以帮助你了解其他公司内部同样职位的情况。这也是一个可以帮助大家共享经验、寻求建议的好去处。

你是否有自己特别敬佩的资深技术经理？你对他们的哪些方面最敬佩？如果有的话，你可以在哪些方面向他们学习？

回想一下你需要改变团队工作的优先级的时候（不论是部分改变，还是全部改变的时候）。进展如何？哪部分进行得好，而哪部分进行得不好？你是如何和团队成员沟通这些变化的，团队成员的反应如何？如果需要再做一次，哪一件事情你可以做得更好？

你对自己所处业务未来的发展方向的了解程度如何？你是否了解技术发展如何助力业务发展？在团队需要关注的领域中，比如在交付速度、系统性能、技术创新、招聘中，最关键的是哪些？随着公司的发展，又需要如何演变？在技术推动业务发展的过程中，瓶颈和机遇是什么？

你与公司其他高层团队成员的关系如何？和哪些人关系很好，而和哪些人关系不好？你如何改善与其他人的关系？你是否理解这些同事的工作优先级，这些同事是否理解你的工作优先级？

如果有人问你的团队成员，你与公司里其他高层谁的关系好、与谁的关系不好，团队成员是否能够不假思考地回答？当CEO或高层管理团队做出决定时，你是否能够摒弃自己的观点，从公司整体的角度支持这些决定？

你是否起到了团队榜样的作用？如果有人模仿你的行为，你是否会感到高兴？如果你参加团队会议，你是自己掌控整个对话过程，还是更倾向于倾听和观察？

上次你与一个平时不闲聊的人聊工作之外的事是什么时候？上次有人向你请病假的时候，你是否抽出了一点时间来对其表示了应有的关心？

你最希望手下的资深工程师在评估工作和做决策时遵守的基本理念是什么？如果你的关注中心在组织架构建设上而不在技术研发上时，你最希望自己手下的经理遵循的管理原则是什么？

培育团队文化的自我评估

当前有哪些政策？有哪些实践？落实成文字了吗？上次修订这些文字是什么时候？

有公司价值观吗？是什么？你是如何在团队中认可这些价值观的？

有职级文档吗？它能准确反映团队现状吗？它能反映你期望的团队未来吗？如果不能，可以改善吗？

团队最担心的风险是什么？公司最担心的又是什么？在不给团队带来非必要的流程和官僚主义之类负担的情况下，如何减轻这些风险？