小公司如何建设技术中层

字面上看,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王津先生通过借鉴"敏捷"的原则,把全职和学生松散结合的团队打造成了"紧凑而自我组织型的团队",把自己从日常的工作中解放出来。

文/胡争辉

Contributors: FHL