资深 CTO：关于技术团队打造与管理的 10 问 10 答

在打造和管理一支强大的工程技术团队方面，Adil Ajmal有着绝对丰富的经验。他曾在7家公司负责过技术团队的组建与管理工作。他曾在TenMarks担任过VP和CTO，这家公司后来被Amazon收购。他也在Posterous担任过技术负责人，这家公司后来被Twitter收购。此外，他还曾在Homestead和Intuit担任过技术主管。如今，他是LendingHome的CTO，公司的技术、产品、设计和数据科学等工作全部是他在负责。

在这篇文章中，他回答了有关技术团队打造与管理中10个最常见的问题：

（一）你如何衡量软件工程师个人的工作表现？如何衡量整个工程师团队的工作表现？

虽然工程师的工作可能和设计、市场、产品等部门人员的工作有所不同，但是绩效管理的基本原理是类似的。尽管有很多绩效管理框架，但我认为所有这些东西都可以归结为两个基本的点：

（1）这个员工做的工作是不是他同意做的或者应该做的？（What）

（2）他们是如何完成自己的工作的？（How）

任何绩效管理的最重要的前提就是针对这个人的合理期望达成共识，这里既包括显性期望和隐性期望。显性期望是指，要求对方在满足特定要求的情况下在规定时间内完成一个特定项目的交付。隐性期望是指，不管他们做什么项目，你对他们的表现所拥有的期待。举个例子，对于一个工程师而言，这个隐性期待是写出高质量的、经过良好测试的代码。你可能对这个项目有很多细节上的要求，但是你不需要提醒他们说，他们应该写出高质量的代码。这个就是彼此都心知肚明的隐性期待。当某个员工开始一项工作时，当某个员工的工作发生变化时，以及在绩效评估期间，你应该清楚地和对方说清楚，并针对显性期待和隐性期待达成共识。

你对员工的期待需要是合理的，这一点很关键。举个例子，你不能对两个具有显著不同经验水平的人在工作上有相同的期待。你可以期望一位经验丰富的工程师能够领导一个大型项目，独立设计并构建一个复杂的、可伸缩的系统等等。然而，你不应该期望一个初级工程师能够领导同样类型的大型或复杂项目。

因此，如果一个经验丰富的工程师在一个大型的复杂项目上做得不好，那么你可以认为他的表现没能达到你的预期。另一方面，如果一名初级工程师能够出色地完成本应该是高级工程师才能完成的工作，那么他们的表现就是超出预期的。我发现很多人都忘了这一点，并且错过了帮助他们的员工成长的机会。当双方已经对一个明确的期望达成共识时，这时衡量他们在“What”和”How“中的表现将会容易得多。

如果员工在负责开发一个功能，那么这里的“What”应该包括以下几个方面的内容：

（1）这个功能在产品中是否表现良好？

（2）这个功能是不是按照规范开发出来的？

（3）这个功能有没有按时发布？

（4）这个功能是否能满足日后规模化扩张的需求？

这里的“How”应该包括以下几个方面：

（1）他们是否与团队中的其他成员进行了很好地合作？

（2）他们有没有因为走捷径而开发了一个很难维护的系统？

（3）他们是否遵循了所有正确的步骤并开发了可扩展的耐用产品？

（4）他们是否在工作过程中破坏了其他人的系统？

（5）他们在做自己的工作时有没有指导别人?

（6）他们在这个过程中是否学到了一些新的东西？

（7）他们是否具有创新意识，并能以一种创新的方式解决问题？

（8）他们是否强制将之前的解决方案应用于新的、完全不同的问题上？

很多管理者在评估员工绩效时只关注其中的“What”而忽视了“How”的部分，其实“How”这部分是同样重要的。

你可以使用类似的方法来评估整个团队的表现。在评估团队的表现时，你可以问下面这两个问题：

（1）这支团队是否交付了他们应该交付的工作成果？

（2）你今后是否愿意再让他们今后以相同的工作方式完成类似的工作？

（二）你的工程团队成员的角色和职责分工是怎样的？你有指定专门的软件架构师或技术主管吗？

我首先需要说明的是，我不喜欢在团队中拥有指定的架构师角色或明确的架构师头衔。我认为，设计一个系统是所有工程师的责任，所有工程师都必须负责开发和维护这个系统，而不是让某一个个人或团队来专门负责并让他们在那光指挥别人做事而不自己亲自开发这个系统。

我知道这么说可能会得罪很多架构师领域的朋友，但是我还是要说。我之前在大公司里有过亲身体会。举个例子，Intuit拥有一个非常强大的架构师团队，也拥有非常成熟的架构师职业发展通道，我知道这群人中有一些非常出色的人才，包括Intuit现在的首席架构师。然而，Amazon是没有架构师这个职位头衔的，作为一个工程师，你可以走IC这个职业发展通道，或者技术管理的职业发展通道，不管你选择哪一种，你都需要能够负责设计非常庞大和复杂的系统。

我打造和运营的每一家公司和每一个团队采用的都是第二种方式。当然，任何时候都需要有人来负责架构方面的责任，但我希望这个人是工程团队的一名能自己亲自写代码的成员。

现在再说说技术主管。在我看来，“技术主管”应该是人们所应承担的一个职责，而不应该是一个具体的职位等级。

对于我自己而言，技术主管意味着需要在一个项目上领导其他工程师（而不是单纯的人员管理工作），既要在技术决策上发挥领导作用，也要在不同成员之间的分工协作上发挥领导作用。

我不认为必须要达到一定的职位级别才能成为一个项目的技术主管。例如，只要有能力，即使是一名只有一年工作经验的工程师也可以领导一个由一个或多个工程师/实习生参与的项目。我的团队中也有一些经验非常丰富的优秀工程师，他们是思想领袖和专业领域的专家，但是却不喜欢去领导其他人。因此，尽管技术主管中更多的是那些更资深的人员，但技术主管本身并不是一个职位等级。

在LendingHome，我们在公司内确定了不同的职位级别，并定义了每个级别所要承担的角色和职责。在这方面，我们一直努力与行业的通常做法保持一致，这样我们公司的职位级别和头衔也能适用于其它优秀的科技公司。我们公司提供了两条职业发展路径：一种是IC职业发展通道，另一种是技术管理职业发展通道。这样你可以在不用做管理人员的情况下也能继续在公司得到成长和晋升。

如果走技术路线，我们公司的工程师等级分为工程师、资深工程师、高级工程师、首席工程师、高级首席工程师、杰出工程师、高级杰出工程师。在级别上，他们与经理、高级经理、总监、副总裁和高级副总裁是平行的。你在任何一个级别上都可以扮演一个首席架构师或技术主管的角色。实际上，我希望每一个技术主管都能负责他们手里项目的架构工作。

（三）你用来确定产品优先级的流程是怎样的？

每一年，我们在公司层面只设定少数几个关键目标。然后根据公司的宏观目标，每个业务线为自己制定未来6个月的阶段性目标。然后，我们再制定符合半年目标的季度目标路线图。这些路线图就是我们定期冲刺的参照标准。就这样，公司整年的宏观目标被分解成一个个短期的目标。

制定路线图总是从每个产品经理开始，产品经理负责制定一个需要与跨职能合作伙伴一起协作完成的优先任务清单。我们将所有这些优先任务清单整合到一起，并创建一个我们希望在下个季度完成的整体优先任务清单。这个任务清单列表也包括我们上个季度延续下来的任务。

一旦我们就这些优先任务清单达成一致之后，产品经理与工程技术部门合作，对各个项目做大概的评估。工程技术部门也需要提供一个本季度的明确的工作目标。利用这种方法，团队可以进行有效的权衡，并制定该季度最终的产品工作优先级清单。这不是一个项目计划，而是一个我们想要完成的任务清单。

我们就从这个优先任务列表中选择任务分别进行冲刺，并在整个季度持续执行。我们努力在这里做足前期调研工作，这样我们就不需要在季度中途改变这个优先任务清单。但是，如果出现了需要修改的东西，那么我们就强迫自己对优先任务列表中的任务进行权衡取舍，而不是直接在列表中添加更多的任务条目。这说起来容易做起来难，但却是至关重要的。

（四）如何让设计师完美地适应产品开发流程？如果能在项目早期就让设计师参与其中、同时又不会浪费设计师的时间？

在理想状态下，在公司业务的各项不同的产品工作中都应该有设计主管或指定的设计人员参与其中。这个设计主管应该在项目早期阶段就参与其中，这样他们就可以在整个项目进行的过程中从设计团队中为该项目获取所需的其它资源。

我们过去遇到的挑战是我们的设计团队中没有足够多的人员来肩负起这样的角色。我们的目标是建立起这样一种架构，让设计团队能尽早参与到所有项目中去。但是这也要看项目的性质，例如，我们不希望让设计师参与到一些专注于纯粹的后端服务和基础设施的项目中。但是另一方面，对于那些直接面向客户的项目，尤其是那些与品牌、营销和应用流程直接相关的项目，我们应该在项目刚开始的时候就让设计师参与其中，而且通常情况下都会有多个设计人员同时参与其中。

如果你已经将项目人员数量降到了最低，你就不应该担心浪费设计师的时间。

这里需要着重强调的一点是，我不认为设计是纯粹的外观和视觉设计。如果是纯粹的外观和视觉设计，完全可以等到项目后期阶段、在所有其它重要工作都完成之后再做设计方面的工作。对我而言，设计是一项非常宏观的工作，它涉及到几个方面的工作：交互、调研、视觉等等。要想不浪费设计师的时间，最好的方式就是在每一个阶段让合适的人员加入进来，而不是在每一个阶段让所有人都参与进来。例如，当需求还没有确定的时候，我是不会让视觉设计师参与进来的。但是，我会尽早地让交互设计师参与进来，因为他们可以在早期定义需求和解决方案的时候发挥很大的作用。

（五）在打造工程技术团队的过程中，有哪些常见的错误想法？

常见的错误想法有很多，我这里主要强调以下三个常见的错误想法：

（1）招聘最聪明的人，把他们放在一起，你就能组建一支高效的团队。

你应该始终努力招聘比你自己更聪明的人加入团队。但是，把一群聪明人放在一起不一定就能组成一支高效牛逼的团队。要想打造一支真正高效的团队，你需要一群真的愿意在一个团队中共事合作的聪明人，而且这些人需要关心团队的成功胜过自己的成功。

解决后面这个问题比招到聪明人要困难得多，而这也是决定你的团队能否成功的关键因素。因此光招聘一群聪明人是不够的。为了确保加入团队中的人都是具有团队合作意识的人，你可以在面试中使用STAR法则（Situation-情形、Task-任务、Action-行动、Result-结果），因为你可以通过根据应聘者过去的行为表现来预测他未来的表现。如果一个应聘者在之前的工作中并没有表现出能够和团队成员很好协作的一面，或者没有表现出团队的利益和成功是高于个人的利益和成功的，这时，如果你招他进来，他在未来的工作中很有可能会有类似的表现。

（2）只招聘那些与你自己或团队中其他人员很像的人员。

我曾经非常希望能够多克隆几个我团队中的一些非常出色的人员。幸运的是，对于我来说这个选项是不存在的。

因为，如果我真的克隆了很多团队中最出色的人，让团队中的所有人都差不多，这只会让团队丧失想法的多样性，最终丧失了所有的创新能力。经验和思想的多样性是激发新的、创造性的解决方案的源动力。从长远来看，一个多元化的团队将会变成一个更好、更强大的团队。

（3）将一群聪明人放在一起，他们就能解决任何问题。

很抱歉又强调了一遍这个问题，但是在某种程度上，这确实是事实。聪明的人喜欢解决富有挑战性的问题，他们往往会能够想出一个非常不错的解决方案。但这并不是打造一个强大团队的基础。其中的关键不仅仅在于找到一群聪明的人，同时要确保这些人是真正有激情去解决你要解决的问题的。如果这些人对要做的工作缺乏真正的兴趣和热情，你可能在早期阶段还能将工作完成的不错，但是从长远来看，你最终面对的将是一个个无法全身心投入工作的员工和一个表现不佳的团队。

（六）你面试工程师的流程步骤是怎样的？你为什么认为这样的流程步骤很重要？

我们在LendingHome采用的工程师面试流程是非常直接的。第一步，面试官可能会对候选人人做一次电话面试。是否进行电话面试取决于：是我们在积极挖一个比较被动的候选人，还是候选人在积极地申请应聘我们的岗位？如果是前面这种情况，我们就不会进行电话面试了。如果是后面这种情况，我们可能要做一轮电话面试。

最开始要进行一轮电话面试筛选，主要有两个目的：

（1）为候选人提供有关我们公司和相应招聘岗位的相关信息。

（2）评估候选人的解决问题能力和编码能力。

通过电话面试的候选人将会被邀请参加最后的现场面试。现场面试有有几轮，要持续一整天时间，需要和6个面试官面试——3个工程师、2个技术经理（我们会从总监、经理、VP、我自己和首席技术官中选取两个人）和1个产品经理。我希望每一个工程师招聘小组里都能有一个非工程师人员，这样我们在招聘中就能获得一个完全不同的看待候选人的视角。

在现场面试中，我们要考察的内容包括专业能力、领导能力和行为技能。专业能力考察内容包括架构、系统设计、解决问题的能力和编码能力。我自己非常喜欢使用STAR法则来评估候选人的非技术方面的能力。

每一位面试官在面试结束后都需要在面试追踪系统Greenhouse中填写对应聘者的详细评价和反馈。采用的是匿名评价的方式，这意味着你在评价之前是看不到其他面试官对应聘者的评价的。然后，我们会在应聘者现场面试结束后的当天，对每一位候选人进行30分钟的总结评估，并决定是否给该候选人发Offer。如果决定给Offer，我们就会尽快给候选人发出Offer。

（七）什么时候招聘产品VP合适？招聘什么样的产品VP合适？

这个问题主要看公司的发展阶段，以及你想通过招聘一个产品VP来解决什么样的问题。根据公司和技术团队规模的不同，产品VP的职责也会有所不同：

（1）在一家大公司，产品VP可能只负责一个特定业务线的产品工作。

（2）在一家小公司，产品VP可能会负责整个公司的产品工作。

要问答上面这个问题，需要根据各个公司的不同情况。对于那些想招聘一个产品VP来负责公司的所有产品工作的公司而言，下面是我的建议。在公司发展初期，CEO自己通常是公司的首位产品经理。随着公司规模的发展壮大，其他一些人开始以兼职的形式分担部分产品工作。在创业公司，首先发展壮大的通常是工程师团队，ceo会与工程师团队紧密协作。如果公司里没有一个技术联合创始人的话，这时公司首先招聘的通常是一个技术VP。招到技术VP后，CEO可能会招聘一个全职的产品经理来做一些产品战术方面的工作，比如制定产品说明书、与工程师协调等等，产品路线图和产品愿景还是由CEO亲自把控。在这个过程中可能会陆续加入几个产品经理，进而组成一个松散的产品团队，这个团队需要直接向CEO汇报。

这时，CEO应该认识到，除了产品工作外，自己身上还要肩负起很多其他职责，这时他们必须认识到必须要招聘一个产品VP了。通常情况下，很多CEO都是被迫做出这个决定的，因为他们通常认为自己是会一直负责产品方面的工作的。

如果你是公司CEO，面对需要招聘产品VP的情况时，你必须回答这样一个关键问题：新招聘的产品VP是只需负责执行CEO的指示、管理产品功能和产品经理团队？还是需要让他来整体负责产品愿景的把控和产品路线图的制定工作？

这是一个很难回答的问题，你对于这个问题的答案将决定需要招聘什么样的产品VP。作为CEO，你不应该自己独自做这个决策，你需要向你的董事会、投资者、团队中你信任的成员征求意见。让大家群策群力，看看究竟是什么样的产品VP才是真正满足公司的整体发展需要的。

（八）你用来管理技术债的框架是什么？

在很长一段时间里，公司增长得非常快，也开始受到很多资源方面限制，因此，我们积累了大量的技术债务。所以我们已经重构了系统的几个部分。是否要对系统进行重构，从而偿还技术债，主要要看以下几个方面：

（1）在系统不断规模化扩展的过程中出现的问题数量。

（2）维护这个系统的复杂性。

（3）需要将这个系统分解成独立的、更易于管理的服务或系统。

（4）由于系统中存在太多的相互依赖的地方，因此无法快速开发系统中的某个部分。

（5）现有系统无法满足日益增加的业务复杂性。

然而你还需要问自己下面这几个问题：

（1）如何平衡好“为了使业务向前发展而需要开发新的功能” 与 ”对可能不会立刻带来明显效益的系统进行重构“这两者的关系？

（2）你在这两个方面投入的资源占比分别是多少？

（3）你是会在不影响系统正常工作的情况下对其进行循序渐进地改进，还是会重写系统并彻底替换原有系统？

随着时间的推移，我们越来越擅长评估这些问题，但并不是总是有一种可行的方法。举个例子，我们现在正在重写一个项目，我想让团队并行地构建一个新系统去彻底替换旧的系统。因为如果对原有的系统进行循序渐进地改进，会花费太长时间，而且整个过程会让人感到非常痛苦。于此同时，我们还有一些正在进行的技术改进项目，循序渐进地改进一些现有的系统。

（九）你是否曾在面试过程中使用过编码测试？如果有，具体是怎么测试的，为什么使用这种方法？

我们确实在面试过程中使用了编码测试。我们对编程语言没有限制，候选人可以选择任何语言编写代码。我们想要评估的是：

（1）他们是否能写良好可行的代码？

（2）他们是否能正确地解决手里的问题？

（3）他们是否能进行良好的测试？

（4）如果代码中有问题，他们是否会接受反馈？

进行编码测试的时候，需要设置一个场景问题，这样我们就可以评估应聘者是否能有效地解决问题。

（十）公司内的技术部门如何与其它运营部门合作？

在公司里，我会让技术部门和其他不同的职能部门形成密切的合作关系，包括运营部门，比如说贷款运营、销售、资本市场等等。我们首先会安排一个产品经理，让他负责同每个部门进行合作并且针对该职能部门设定产品路线规划图。举个例子，我们会单独安排产品经理专注于顾客获取、贷款管理、服务、投资管理等等。这些产品经理会和团队密切合作、跟着他们学习技能、认真了解他们的需求和痛点，然后利用这一切来明确合适的产品功能和优先级顺序。

我们每周还会和公司内不同职能部门进行会面交流，参会人包括产品经理、工程经理和总监、跨职能部门的合作伙伴，有时候还包括业务线的经理。会议是要了解产品开发的最新情况、上线的功能等等，主要目的还是要明确职能部门的需求、确定解决方案和项目的优先级顺序。在有些情况下，当我们推出大量内部工具时，产品团队就会为公司的运营团队成员提供专门的培训。我们还会采用一个正式的流程来接收运营人员的运行支持需求。如果最终发现问题是技术方面的，那么负责此问题的工程师就会和有疑问的运营团队成员直接联系，解决他们的问题。

当我们在开发新功能时，产品经理和工程师正与运营团队成员合作确定合适的解决方案，这时也会出现相同的情况。对于小型团队来说，工程师、产品经理以及其它团队成员会在SLack上进行沟通。通过Slack沟通在一段时间内是有效的，但是当你发展成为大规模团队时，Slack协作工具是无法扩展的（比如说我们的贷款运营和销售团队）。最终，我们需要推出一个更加正式的沟通协作流程。

尽管说了这么多，但实际上技术团队和运营团队之间的合作关系并非一直都这么好，有些时候情况也会基于不同的非技术型团队发生改变。这很大程度上取决于非技术型团队是否会认为技术团队是为他们服务的部门，他们可以直接下达指令，抑或是他们是否认为自己是技术团队的合作伙伴，双方可以共同解决问题。我们的目标通常是后者，现阶段我们已经很接近这种状态了。人们曾尝试过前者，结果通常不太顺利，且成本花费非常高。

（十一）在一个技术经理招聘比他自己更有经验的人的时候，你有什么建议？

理想情况下，你雇佣的每一个人都应该在某些方面比你做得更好。这也适用于招聘比你经验更丰富的人。在招聘比你经验更丰富的人时，你需要考虑的主要问题是你如何为他们增加价值，以及你将如何从他们的经验中受益。

了解这个人在哪方面能够为你带来价值，以及他能从你这里得到什么帮助。例如，他们可能是在技术上比你更好的工程师，在设计和构建复杂系统时不需要你提供任何帮助。但是，他们可能没有你了解公司业务的相关背景、公司的客户等。你可以通过帮他们更快地熟悉所有这些东西来增加他们的价值，这样他们就能更好地完成工作。类似地，你也可以帮助他更好地了解公司的组织架构，从而更快地改善他们与其他团队的协作。

所有这些点在面试过程中就应该提到，而不是在他们接受了这份工作之后才告诉他们。当他们的这些需求和利益得到承认和满足时，说服他们加入就会更容易。

雇佣比你更有经验的人的最重要的方面在于你可以从他们那里学到东西。一定要保持一个开放的心态，并对能从他们身上学到知识表示感谢。相信我，当你向他们学习的时候，你仍然会给他们增加价值，所以不要担心这点。在我职业生涯中的很多时候，我总是不得不雇佣比我更有经验的人。我非常喜欢从他们那里学习，如果没有他们教给我的所有东西，就不会有今天的我。

原文链接：http://firstround.com/review/veteran-cto-with-20-years-experience-answers-your-top-startup-building-questions/

编译组出品。编辑：郝鹏程。