字面上看，CTO的主要职责是：管理技术部门中的中层管理者，以满足技术部门的管理需求。因此，CTO应该避免几个误区，在公司内部为主，而不是以外包为主开展技术工作，外包是CIO的职责；通过培养中层管理者来满足工作要求，而不是在外部招募高手来解决工作问题，招募是HR的职责；预备适量的冗余人员规避员工的流动风险，而不是在减少员工、压缩成本的同时增加风险，平衡公司的风险与成本是CEO的职责。当CTO不再陷入上述误区时，就会选择通过培养中层管理者来建设技术团队，中层管理者是技术部门的"骨干"，是新员工的"模板"，是以"敏捷"方式工作的主体。本文尝试分析小公司技术部门的工作特点，向小公司的CTO提出一些建设技术中层方面的建议，并分享几位CTO的成功经验。　

有价值的人≠"骨干"

如果说CTO是技术部门的"大脑"，那么中层管理者就是技术部门的"骨干"。CTO的工作离不开"骨干"，因为CTO也常常会误认为有价值的人就是"骨干"。

外聘"高手"不会成为"骨干"。大多数CTO都是先成为技术高手，然后被提拔为CTO，因此，CTO常常会有一个思维惯性，会认为技术部门的价值来源于"高手"，所以在负责技术部门之后，会花费相当的时间和成本在招聘"高手"以及稳定已经到岗的"高手"。然而，在实践过程中会发现这样做效果常常不尽如人意。"高手"的数量相对较少，而且目前仍有大量的IT公司缺乏胜任CTO的人选，因此"挖"来的"高手"会常常被"挖"走。所以CTO对于"高手"应尽量采用临时聘用的方式。

"不稳定"难以培养成为"骨干"。目前IT人才的流动性相对其他行业明显偏高，在中小型公司中，年离职率常常会超过30%，因此IT部门就需要一定数量的冗余人员来避免离职造成的困扰。对于基层组员来说，通过冗余人员能减轻员工离职造成的困扰，而对于组长来说，每个组长都在负责某一方面的工作，互相之间难以直接替代，因此当组长离职后，通常是在该小组的成员中，提拔新的组长，此时，整个小组的工作都会受到严重的影响。因此选拔"不稳定"的组长时，短期上能创造价值，但是在长期上会造成更大的损失。

5年前创办清北DIY俱乐部的清华大学学生叶炜，在创业之初曾力邀清华大学电子系的硬件高手担任技术总监，但时间不久就离职了。之后转变了经营思路，5年后的今天不仅规模达到了30名员工，而且自创的"清北"品牌在北京各大高校科研院所有了相当大的影响力，而与此同时大多数学生创业花费很大的精力和财力邀请专家高手，反而夭折了。

"骨干"从哪里来？

既然有价值的人不一定都会成为"骨干"，那么CTO也就会有这样的困扰："骨干"从哪里来？

按"职业规划"任用"骨干"。在提拔任用组长时，首先需要了解候选人的职业规划。越来越多的人才会给自己设定职业规划，然后寻找相应的工作。因此，在技术部门内部选拔时，也需要了解其职业规划，应当让职位尽量符合候选人的职业规划；当职位和职业规划不一致时，既便能胜任新的职位，也应当充分征求候选人意见。如果职业规划的目标是其不能胜任的职位，则应当延缓任用。

"少年老成"是"骨干"的重要特征。虽然直接任用年长的员工为组长是比较常用的做法，但是从长期上看，年长的员工获得进一步晋升的可能性也更大，如果公司难以满足其职业需求，年长的员工反而会"不稳定"。因此应当寻找"少年老成"的组员作为组长的候选人，他们担任组长的时间将会长得多。创造自由发表意见的渠道是判断"少年老成"的有效方式之一，对于那些能提出独到见解而又能付诸实施的组员，则可以作为组长的人选。

从开源社区中寻找适合的"骨干"。虽然不必外聘"高手"，但是CTO还应多参与开源社区，目前的软件开发过程中越来越多的使用开源软件，因此CTO参与开源社区不仅能获取所有技术的前沿进展，还可以通过观察发现开源社区中的活跃用户，寻找自己所需要的人才，例如在XOOPS开源社区中，就经常有活跃用户被采用XOOPS技术的公司招聘，入职后很快就成为技术骨干。

"骨干"不是"大脑"

在任用"骨干"之后，CTO就会面临另一个问题："骨干"该做些什么？

将"不可能完成的任务"留给CTO自己。技术部门的工作有着较为严格的时间约束，同时在工作中还常常有很多不可预知的情况，如果将所有任务直接分配给组长，那么CTO就只有在进度延误时才会知道组长无法完成某项任务，如果碰巧是关键任务，将严重影响整体进度。因此CTO在每件任务面前，都需要考虑这样一件事：这是属于"大脑"的任务，还是属于"骨干"的任务。而且对于已分配的任务，CTO还要和组长逐项核对是否有把握完成，对于组长没有把握的任务，CTO应采取重新分配、外包或者亲自处理。

将"成就感"留给"骨干"。职业规划、物质财富和成就感是员工跳槽的几个重要原因，职业规划和物质财富受到技术部门实际情况的制约，难以满足每个员工的需求，因此成就感就成为避免组长跳槽的重要手段。CTO在各种场合中，都应尽量把决定权留给组长，一方面组长是小组的直接负责人，他的判断代表了小组的判断，另一方面，参与决定的过程还会让组长产生责任感，进而通过完成任务而获得成就感。

协助"骨干"实现职业规划。在"成就感"之外，CTO应协助组长实现职业规划，积极讨论职业规划有助于让CTO了解组长适合的工作内容。在实践中，一方面由于CTO的工作繁忙，另一方面直接的上下级关系难以了解真实的想法，此时可以考虑外聘专家负责这项工作。例如，某资深技术培训顾问长期协助中小IT公司CTO进行这项工作，不仅减轻了CTO的工作压力，而且为减少了公司对组长的直接物质激励支出，提高了成本竞争力。

和"模板"创建"文档"一样培养新员工

IT行业的人员流动性大，因此培养新组员迅速胜任岗位就是技术部门的主要职责之一。通过组长树立表率来带动新组员就像用"模板"创建"文档"一样，制作一个模板不会直接创建文档，但是会大大加快未来创建文档的速度

CTO通过组长培养新组员时，首先要从招聘开始，让组长自己负责招聘新组员，和应聘者联系，安排面试等等，对组长充分放权。在招聘后，对于培养新组员的所有任务，都尽量由组长亲自执行，CTO应发挥自己的管理经验优势协助组长完成培养工作，而不是技术优势。既要相信组长通过自身的努力能够覆盖新组员所需要学习的技术，也要随时发现组长在培养新组员时遇到的各种问题，协助组长完成培养工作。

"敏捷"的组长

敏捷软件开发是20世纪90年代逐渐引起广泛关注的一些新型软件开发方法的总称。由于机构组织形式的千差万别，技术部门要按照所属机构的特点进行组织，所以常常不能采用敏捷软件开发的工作方式，但是在技术中层的建设上，却可以充分借鉴敏捷的原则，既使技术部门在整体上采用其他的工作方式，敏捷的原则仍有助于改进组长间的工作配合。

在实践中，清华大学Web与软件研究中心CTO王津先生通过借鉴"敏捷"的原则，把全职和学生松散结合的团队打造成了"紧凑而自我组织型的团队"，把自己从日常的工作中解放出来。

文/胡争辉

( 来自：《程序员》杂志 http://www.programmer.com.cn/)