小欧有话说：
为了加深EGO会员之间的相互了解，同时也为更多的技术人提供相互学习交流的机会，EGO开展了每周四21:00的线上分享活动。本文根据第22期嘉宾——王宗义
8月11日线上分享内容整理而成。作为新晋会员，看看王宗义在过去的16年里技术管理及创业路上踩过的坑。
开源技术爱好者、数码控、喜欢买书读书，1999年毕业，2000年持续创业至今，历经从互联网门户、政务系统软件及服务、互联网社区（游戏、艺术品、台球）、网页游戏研运、手机游戏研运几次变迁，目前是光辉互动的联合创始人及技术高级副总裁。
大家好！很高兴能够参与EGO线上分享。先简要介绍一下经历：我99年毕业，在1家A股上市公司下的互联网公司工作1年。从2000年就开始了不间断创业经历，到目前总共是4个企业，大概的角色情况是2000-2004 A公司（创始员工、部门经理）、2004-2008 B公司（联合创始人、CTO）、2008-2011 C公司（联合创始人、CTO）、2011-至今 D公司（联合创始人，SVP）。因为今天分享的议题，就不说公司名字了。因从工作第二年至今，都在未中断的创业中度过，因此整个经验大部分自己摸索为主，希望对在创业路上或者准备上路的朋友有所参考和帮助。
一、先分享一下我的团队管理及成长经历
A）Team Leader管理阶段：创始员工，部门经理
面临挑战：过早步入管理没经验
我很早就走上管理岗位。99年毕业时候很幸运我遇上不错的CTO（也是业界牛人），在国企我毕业才3个月他就让我就任技术部经理（EGO Wood）助理，从此开始了管理不归路。1年后A公司（CTO和Wood创立，我成为第一名员工，后成为股东，也算是一起创业）就让我直接管理20多个技术人员的产品部。产品是互联网产品，但是走的是2B的思路，客户都是政府部门，为他们做互联网门户以及相关公网业务服务系统。这个阶段管理是什么都不懂，公司对我放心，也没人教，全靠自己摸索。零散小项目不少，还好团队自控力较强，而自己也算是技术思维多一些，所以都是把控几个关键阶段：技术架构、部署实施、运营支持。管理架构上分成4个小组，有4个项目经理，然后他们帮我管理各个小组。管理风格就是吃喝玩乐，3天一大吃2天一小吃，每周有空到处游玩。团队里面很多人，现在都是行业大牛了。现在来看，作为Leader，当时的管理能力太弱，并没有较好的发挥好他们的作用。
围绕着当时的情况，个人技术、产品及管理来自几个方面：技术关注力方面除了工作主要是读书和写小程序，还有担当一些技术论坛版主（LinuxForum）和参与一些论坛讨论（SHLUG、JavaEye）。也和同事一起翻译了一本书《网站重构》，书名是我起的，结果开心的是，很多公司直接有网站重构师的招聘岗位了，国内各大网站也终于第一次认识到遵循网页标准的重要性，并很快进行大改版，算是把国内前端工程师的概念雏形竖立起来了。产品部经理的客户服务期间，我也累计了不少服务2B客户的经验和感触，政府客户满意度很高，因为帮他们搞了几个国家奖项以及总理嘉奖导致非A公司外不敢签服务，也因此A公司还存活到现在。某个系统10年后才被国内互联网公司拿出来当良心品搞浏览器大战用。管理方面跟随公司搞RUP（现在搞SCRUM的同学可能不理解当时RUP的热门程度），跟几个同事在北京成立了一家叫网站项目管理协会的组织，围绕一个网站的项目管理所需的技术、工程和管理展开了几次会议，可惜后来荒废掉了，网站还忘记续费被搞成色情网站:-)。不过成立或者参与一些兴趣小组来聚集相同爱好的人，确实是最好提升自己相关能力的好方式，当然如EGO这样就更好了。这些自我学习对于我后一家公司初入CTO和作为合伙人做了很好的铺垫。
从CTO角度回头看，一个公司里面的Team Leader承担着承上启下的重要作用，公司里面大部分的产品工作量都应该会由一个个Team Leader来负责带队完成。发掘和培养好的Team Leader是一个CTO最核心的工作。我认为一个好的技术Team Leader，覆盖本团队的技术方方面面是容易，并且能够深入产品和客户服务中去，这个就能够做好自己team的业务工作。在该部门的业务线上他的技术应该是最深和最广且应该受到最高尊重。当然从发展角度来讲还不够，还需要能够对相关的其他领域的知识和技术有深度和广度的涉猎，以及很强的学习能力，能力矩阵应该是技术、产品、服务加管理。而大多数承担Team Leader的员工，一般都是技术远强于管理，初入管理偏多，大部分人会对这个阶段产生畏惧，管理方法也大多松散管理。这方面CTO需要根据团队是否成熟等具体情况做引导和帮扶，帮助他们良好落位。
在毕业及A公司初步确立了自己的管理体系，我当时的CTO和技术经理（EGO Wood）给我了很大的影响，主要是对人的信任。包括在国企能给我那么大的信任，在A公司第一天就把代码库的建设和管理权都给我，让我独立管理一个业务部门，正是他们的一个决定让我的职业生涯完全不一样。感同身受，因此我认为一个好的CTO必须具备这种能者上、高度信任和放权的思维和心态。
B）初创企业阶段：联合创始人和CTO
B公司是互联网游戏社区公司，本着先做用户后赚钱的理念，直接面对用户做产品和服务。
面临挑战：从部门经理到CTO的提升，开发、运维、产品、管理全方位的冲击；2B到2C的转变；
那时候web2.0概念刚兴起，团队也经历了0到几千万量级用户的演化经验积累，当然现在来看非常阳春，当时公司内技术人员不是特别多，所有的细节都过问和关注。公司为了生存，也对外承接了一些行业互联网平台的外包开发工作。原本在A公司因为比较安逸一些，有点感觉自己都闲得快废掉了，出来后更换行业创业也就突然更多挑战了。
首先是研发挑战，原本公司虽然也是互联网产品并运营网站系统，但是2B业务，并未直接接触一线用户，技术栈的大部分是商用软件系统，因为政府客户那时候对待开源还是敬畏如虎。到了自己创业，首先从资金能力来看，就没有多大的能力支付商用软件的费用。因此肯定是要做调整，技术栈从商用软件为主转向开源为主。从小型机和windows到linux，从CVS切换到Subversion，从Oracle切换到Mysql，Apache切换到Lighttpd，核心架构直接从EJB/Servlet切换成当时才刚出现的SpringFramework 0.x（Veloctiy / iBatis)，团队内部也用Trac建立了基本的管理和文档系统替代之前用过的Test Track。刚开始技术人员也不多，连我3个人，另外2个人是我从A公司只选了两个默契度最高的，不过草台班子就算起来了，迈出了第一步。当时选用Spring也算比较激进的，搞了1星期后，大家认为完全可以把控，于是就大胆切换。
其次是产品方向挑战，因为是联合创始人，也需要考虑做什么产品。当时出来就定位于互联网2C服务，讨论商业模式的时候，我平常关注互联网较多因此提议要找个垂直行业做，大家也认可，因为有2个合伙人都是游戏迷，于是就选择了游戏社区作为方向，核心选择主要围绕游戏公会来做，针对游戏用户的特点做了很多的工具和服务平台，增长的过程也很有意思，一分广告费未投。第一年（刚开张）就只有10万用户，第二整年100万，第三年就爆发了，第四年离开的时候已经有6000多万用户了，DAU接近200万。当然围绕这个增长，网站的大架构调整了3次，第4次没调就离开了，有的是主动调整有的是被动调整。最开始只有3台服务器，还是自己攒的，后面就慢慢变成好几个满机柜了，最后还有现在还在运营的国际独立版本。
当时围绕如何增长也是耗费了很多心思，人穷志短没办法投广告和做PR，只好考虑现在流行的Growth Hacker了。SEO是避免不了的，之前在A公司的时候其实也是帮客户针对SEO做了很多的产品优化，因此之前的积累倒是用上了，我们有大量的用户来自于百度和谷歌（当时还能访问），我们有好多核心关键词都位于2个搜索引擎的第一位。当然仅限于此还不够，最主要还是从产品本身的特性，我们最大化发掘平台的游戏社交化，让用户人拉人。另外还通过游戏用户最需要的辅助工具刚需，游戏数据库刚需等等各种技术及手段去拉升用户。我们最早创造了游戏公会平台，很多山寨者就来了，其中就有某后来在纳斯达克上市的公司。被山寨其实是好事情，至少说明这个模式可行，用户量很大也稳定持续盈利但是事情最后没做成，是其他问题，后面的创业教训会讲到。
2C相对2B对技术、服务、运维的也有不同要求，用户会直接找上来。我们当时有一个系统升级，做的过于复杂（为用户考虑过多，典型技术思维害死人），上线后大部分用户说还是简单一些，我们于是马上修改，因为架构问题只能停机升级，当时持续加班4天3夜没合眼，期间用户电话接了300多个，有几个是凌晨打的，用户惊讶我们居然还在，结果系统改完上架，用户很满意，用户每日新增也上一个新台阶。当然技术上的好处是，大家更深刻理解任何时候系统架构是必须考虑到不停机更新，以及升降级，还有灰度发布，A/B Test等，对于用户和业务的好处是非常非常有价值和帮助的。当然创业时候，有时候很难搞这么完善，也有很多历史原因。运维也是挑战，由于用户快速增长和数据膨胀，而当时并未具备很好的工具和经验方法，也出了一些事情。一次做照片库升级的时候，丢失了几千张用户照片，还遇到过阵列损坏等情况，由此也是对于团队的运维和架构能力有了较深刻的推动作用。
经历这个过程，我感觉初创企业CTO和非CTO最大区别就是CTO你就必须搞定所有的东西，尤其是初创公司内资源有限，公司内所有任何技术类东西都需要搞定，必须要通盘考虑且能深入细节，这个对于技术的全面性、敏锐性以及定位问题能力要求比较高，从产品立项、研发、运维、公司内部系统、增长（SEO等技术和非技术的手段）、团队管理都需要有能够把控的能力。对技术的理解也会更加的深刻，会从更高的层次来思考技术的作用，甚至可以用技术去影响产品和运营规划。创业过程中理所当然会遇到很多问题，其实这个很正常，做好数据安全是最关键的了，其他出点错一般就还好解决，当然这个是底线了。当时因为用户增长并没有短期内突发几十倍的情况，虽然事情非常多，但是还是有足够的时间来解决，但是这个阶段也是个人能力成长最快的阶段。
在初创公司CTO阶段，有些技术人员出来创业之前并未承担过类似的管理角色，我认为在初创公司的CTO，需具备至少之前带领过一个技术Team的能力，并需要有较广的技术能力（万金油），团队初创的时候也需要选择最精华合适的人员，如果没经验进入这个角色之前需要有心理准备。作为合伙人，还应该具备更多的能力和承担更多责任。
C）成长型企业阶段：联合创始人和CTO
C公司是个网页游戏公司，团队经历了快速扩大的过程。
面临挑战：高节奏、强压力、快速增长下各种管理问题挑战；人员规模和产品项目规模迅速扩大，更多的企业运营和发展挑战，不局限于技术及产品领域。团队的成长挑战，互联网社区转网页游戏研发，摸着石头过河。
这个阶段疲于奔命，一方面团队并未准备好，突然间游戏就火了，然后大量的服务器就开了。团队一方面需要线上维护游戏升级，一方面还要准备新的服务器上线，还时时刻刻面临各种各样的以前根本遇不到的异常问题，最夸张是随时可能响起来的催命电话。服务器一下子短短2-3个月就到了300-400百组，上千台服务器，还涉及中日韩港澳台等等不同机房，团队是手忙脚乱，还好是B公司有过了很多经验，这么多服务器居然没有出过丢数据的重大事故，但是也是累的不行，逼着后面逐步自动化了才缓解。那时候耳朵一直幻听，总感觉电话在响，几个核心同事也是一样，业务繁忙和各种异常整个充斥了24小时。2C中游戏和电商比较像，不能数据错，游戏业务逻辑理论上比电商还复杂，用户会因为一点点问题而跳脚，B公司楼下有个端游公司，就遇到过几起用户上门打砸的事件，每天客服搞不定的问题不管玩家是否造假都需要排查，这个耗费了大量的精力，团队第一次做游戏，很多系统没办法非常完善考虑。那时候也是python用的最多的时候，写了很多的脚本处理和分析问题。
后来一件项目对我压力改善帮助很大。公司有一个产品，日本的合作伙伴需要我们40天完成flash改造，40天要完成一个复杂网络游戏的前端及交互：美术外包、ui制作、flash开发、后端改造，公司内没有一个对flash比较熟悉的，我和产品团队认为是不可能完成的事情，外部找一些公司也没人认为能完成，评估大体是要3个月。但是大家决定还是要做，任务负责人安排在我身上。技术上明知肯定完不成，但是业务上必须完成，那是我人生压力最大的时候，大到早上真的是起不了床，身上真实感觉受到压着一块沉甸甸的大石头，但是虽压力大，还好并没有绝望。最终这个项目却在35天左右提前完成，后面一统计，光前后api接口就有400多个，每个api面对的都是前端一个或者多个复杂的UI界面和UE表现，简直不可思议。这个项目给了我一个启示：我们经常高估自己能力，但又经常低估自己强大的潜力，这个项目以后创业过程中的各种压力好像也没有掉了。这个项目也给我一个对项目管理效率的认知：需求稳定准确、技术框架稳定、任务目标明确、任务分解合理，一个项目完全可以有高效率的可能性，也可以避免持续恶性加班，这个也是我后面接手一些问题项目组治病思路的核心要点。
人员规模大幅扩张，短短几个月内就到了150人，同时7个网游开发。而一方面公司内短期难以有很多合适的人成长起来，一方面很多非游戏行业的技术人员迅速涌入，他们对于游戏和非游戏产品的技术区别和管控不是很有经验。这对于管理的压力也是骤然提升，到处漏水，简直耗尽了一切体力和精力。状况当然不能持续，必须让自己只把控最应该把控的事情，从亲力亲为解脱出来。经过不短的调整，更多关注每个项目组团队的成型及走上正轨，而在几个重要技术、测试、发行阶段才会亲自参与。个人实际游戏方面的开发是比较少了，培养了一个总架构师替代自己的具体技术线工作，让他和各个项目组主程序去解决问题。当然技术有时候也会做一些，当时和平台部门小伙伴一起开发了公司的游戏数据分析平台，也是国内比较早用mongodb的公司。这个时候公司就有酒文化了，技术部门聚餐，不管男女喝不喝酒，一人先干一瓶；而每次产品上线，全公司的人也都会大喝一顿。酒这个东西，是挺有意思的，一杯下去，那些平时不说话的技术宅，全成演说家了。
成长型阶段CTO跟初创型阶段CTO区别是业务压力和管理压力量级完全不一样，业务及团队快速增长、客户满意度和团队的支撑能力以及资源会有短期矛盾，而我所处的游戏行业更是加深这点，既要支持好现有核心产品，又需要开辟更多的战线，但是可能发现暂时团队的能力未能及时跟上，外边找的人也不知道什么时候能到位或者能管用。这个阶段，没得办法，一旦遇上首先是好事情，其次作为CTO必须带领团队先扛下来，然后迅速分解分步搞定。当然，也要量力而行，有时候还是要做做减法，不能让团队承担不能承担的角色。
D）复合型增长阶段：联合创始人及技术SVP
D公司是手游为主的公司，到异地孵化了新的研发团队，中途也临时接替CEO一年，也临时接管运营中心几个月。
面临挑战：技术思维和个性对于承担研发外的不同角色的牵制，面对各种挑战，对自我的批判和激励是这个阶段是最核心的任务。老团队和新团队的碰撞，CTO到SVP。
在这个公司的前半段从C公司分出，人数也不多，30人左右，我负责整体技术及产品。因为北京这个是老团队，已经可以独立工作，也有另外一个合伙人负责。为了能够不重蹈C公司覆辙，在业务高速发展的时候后续跟不上，于是去南京成立第二个研发中心。老团队创业时间很长了，大部分人年纪也上来了，企业肯定要不断进步因此逐步开始产生了很多问题。于是在南京团队用了新的管理方法，希望新团队的活力、业绩及模式能让北京团队重新焕发青春，后来南京团队起来了。本意是想各自促进，但是结果并不是特别理想，不过从公司业务角度来看，至少多了条腿。到一定阶段老团队总是要革命的，就看是团队自己主动还是被动了。现在如果来做，我会更多的是新老结合来做，这样效果可能会更好一些。
游戏的产品特殊性，负责产品就必须去研究游戏是设计、体系架构、成长、数值等等，这是一个专业领域，游戏行业的人也比较固执且年轻，而手游中任何游戏类型都有成功例子，谈论起策划案来每个人都有自己心目中的游戏世界，但是大多数情况下都很难达成共识。要管理这么多有主见但是可能工作经验和管理能力极弱的团队，就需要走入产品中去。近几年资本市场的对手游的热捧，催生了大量浮躁的情绪，不过对于我来讲，创业多年早就看破其中，这样团队也不容易浮躁。老团队靠默契工作和多年的经验明显不能复制，因此对新团队从最基本的策划抓起，建立了完整的从调研、demo、立项、研发、测试、上线、迭代的游戏研发运营体系，这个过程也让我整体对研发和运营一体的管控做了一个好的梳理。针对最容易产生问题的策划环节，我们也确定了几个原则：放进策划案的必须做；不放进策划案的必须不能做；策划案不是不能改，改需要有流程；任何人的意见都应该被充分尊重，都需要书面回复；公司没有某总、某人的策划案，都是公司策划案。当然这些原则对于非游戏的产品我也觉得是一样管用的。
中途有一次角色大变迁。因为原先的CEO因为生小孩，我临时担当了1年CEO，当然还有合伙人帮我承担一些其他角色。担当这个角色的时候，深有感触，说CTO压力大，CEO才是更大，公司内外事无巨细，到处是问题，除了你没人能解决。而且这个时候，你会发现你最擅长的技术、产品、运营的经验，好像完全顶不上用了。经常要挑战很多的个性上的东西，是很难受的，有时候表现的兴高采烈和员工谈完，员工走后，我才能表现出疲乏和软弱来。很多时候，没得说苦，你会发现好像很多人都成为矛盾体了。我一个合作伙伴，是个美籍华人，也是技术出身，企业还是在硅谷的企业，后被思科收并，当时因为不得已必须接任CEO，他说简直是炼狱般的折磨，真是说到心坎上了。因此一个技术高手要去创业的时候，如果是承担CEO角色，建议要思考清楚，因为可能80%的时间都要用来做非技术以外的工作，也就是用不擅长的能力去做没做过的事情。
后半段因为行业的变化，在这个公司的阶段也发生了一些平台提升，变成公众企业，CEO也由团队中资本经验很丰富的合伙人接任，开始用复合式增长方式。公司需要有更多的年轻人、强人进来，也收并了一些公司和团队，有一些游戏外的项目进行，公司在硅谷也设立了小工作室，和政府一起做了孵化器和众创空间。企业不同的阶段，需要不同的人来做不同的事情，我主动把我的角色变成服务角色，把位置让给他们，给他们创造更好的环境和平台。更多的实际工作帮助各分管的VP到位和落位，帮助各个事业部设立自己的CTO。公众企业的监管要求，对于企业的研发管理也提出了比较高的要求，因此针对公司的情况，开始设立OKR和KPI的绩效管理，研发中的采用OKR，上线运营的采用KPI。各种各样的管理方法被固化成模板、表格、流程，当然也避免不了有的刚开始僵化后期需要不断优化的过程。业务和技术发展需求，也对管理和风控提出了更高要求，也不太适合我一个人做决策，于是就设立了产品委员会和技术委员会，分别对产品和技术进行把控和引导。公司内部更注重集体学习，每周有很多的分享和交流，也开始做大量的培训。
创始员工在早期进入，并承担公司的重大成长贡献，但是随着企业的发展需要，跟得上的就跟上，跟不上的就需要调整，有的人甚至会主动或者被动掉队，这个没有办法。从技术Leader来讲，我认为，企业到一定程度，一定需要做好心理准备，主动提升或者更换角色，在企业中发挥更大或者更合适的作用。也需要注意做好老团队成员的工作，一方面给他们新的位置，另外一方面给他们确立新的目标，尽量让他们发挥新的作用并获得更大价值。从管理和发展角度，需要持续带领团队成长，每个阶段都需要有良性有效的刺激和鼓励，让他们能够跟着公司一起成长。
E）几年下来一个小总结
纵观我自己几个阶段的技术及管理过程，狭义的技术能力（技术专业能力及研发能力）大概几年就会有一个阶梯型的曲线提升，大部分人到一定程度受限于年纪和精力各方面因素到一定阶梯后则很缓慢增长；而广义的技术能力（技术领导力、经验及企业管理能力等综合能力）是线性或者指数提升的，两个曲线交叉的时间点也就意味着要角色转型。当然有一些大牛是永远不会有交叉的，他们也无需转型，只需越做越专，越做越广。我在C公司就差不多完成转型变化，更多参与的是企业治理，最近几年下来实际的开发渐离，更多的是保持技术关注度和个人一些兴趣。成长的几个阶段也是从点开始到线最终到面的串联，我感觉整个技术管理和成长过程就跟做学问的几个境界一样：昨夜西风凋碧树，独上高楼，望尽天涯路（这是初创企业阶段）；衣带渐宽终不悔，为伊消得人憔悴（这是高速成长阶段）；众里寻他千百度，蓦然回首，那人却在灯火阑珊处（正在努力追求的阶段）。我也是按照这几个阶段针对不同的团队和Leader做成长引导。
其他分享一些小心得
有好Leader才可能有好团队，他代表着一个团队的战斗力，所以Leader一定要对
项目需要资源准备充分再上，在可控范围内，让团队能够犯错促使进步
体力活一定能转变成脑力活，脑力活则固化成工具，工具不断优化，最后成系统
观念不对，能力越强，破坏力越大，越不能用
给一个貌似他完不成的任务帮助他独立完成，认识到自己的潜力会增强他们的信心
要帮助员工成长，规划他们的职业成长路线，帮助他们解决困惑
越严格要求下属，他们就越能够获得能力成长
真心爱每位共事的同事，因为他们和你的时间超过他和家人的时间
要身先士卒，领导者的气质和精神才能感染到团队
解决不同层次企业问题的能力代表一个人的不同价值
未完待续，敬请期待下篇内容：聊聊16年的技术管理及创业路上我踩过的坑（下篇）
联系客服
