国庆过后，最终还是做出了决定，告别兄弟们，离开这家呆了两年多的创业公司。作为最早期的核心人员，我经历了公司项目从零搭建，上线，迭代，最终作为某国家级考试指定平台的整个历程。不过老实说，公司过的并不好，几轮融资的失败，原始股东信心的逐渐下降，资金始终是最头大的问题。作为技术，融资不是我们所能左右的，但是回顾过去，还是想记录一些学习到的知识，主要是对技术经理这个职位的介绍，以及我的经历和感想，希望和大家交流。

技术经理、技术总监、CTO

首先可能还是有人不清楚技术经理、技术总监、CTO三者分别是什么，大致描述下。

当程序员入行4/5年，变得更秃更强，开始迈向高级程序员乃至架构师之后，或多或少会接触一些管理。此时的你可能深受boss的信任，拥有自主招人、辞人、绩效考核等等核心权力，同时也负责着项目内的任务分派、质量管理等工作，负责了一个team内的各种具体事情了，此刻你的角色就是技术/研发经理(下统称技术经理)。技术经理我认为带的团队最多也不要超过10人，一般的产品线负责大概7、8个人左右（根据具体情况）。

随着公司的日渐发展，当研发团队壮大到20+或存在多条产品线时，可能带队的技术总监就已经有多名，此刻可以设置一名技术总监，向下对整个研发部门负责，向上对接leader，中间对平行部门进行业务协调。

CTO需要有强大的前瞻性思维，他决定了整个团队/公司的前进方向，这个方向并不体现在某个team业务中的技术选型、架构判断，而是领域的选择，某种程度上，他决定的是公司的业务发展方向（特别是技术型公司），他需要对新技术有着超前的敏感，并以此驱动整个企业新的产品战略和商业战略，搞不好影响的是整个行业更有甚者可能直接创造出一个行业。

对于广大程序员来说，迈向管理岗的第一步就是技术经理了。

公司铁三角：产品 技术 业务

产品 、技术、业务是一个公司最基本最主要的三部分，以我的个人经历看，在一般的小公司/创业公司，业务为第一导向：初创老板本身自带领域资本，这个资本可能是钱，是某项技术，或者是某个领域的关系，而这些衍生出来的业务实际上几乎决定了这家公司未来的一切。

产品是业务的翻译：产品经理是boss本身，又或者额外有产品经理，实际职能只是boss需求分析者 or boss需求翻译器，在这种情况下，技术是更加没有存在感的。

理想型的情况应当是产品、技术、业务互补协同。但实际上这种情况在小公司并不存在，只有在稍大型的互联网公司，产品乃至技术才拥有一定的话语权。

技术经理的职责

做好事情，带好队伍，搞好文化

如果此时此刻，公司决定让你去成为team的技术经理，你首先得明确，有关这个团队的一切，多少都开始与你有关了。

首先，做事是第一位：从一线开发或者某个高级程序员转为技术经理后，首先要确保的仍然是开发需求的完成。

其次，团队负责人是你，你需要带好队伍，这包含很多因素，比如团队的绩效制度，职责体系的确立，晋升体系的确立等等。

然后是队伍文化，并不是大公司才会谈所谓的文化，往低了说，一些共同信仰，基本共识和整体性格，是无论什么团队都具备的。

首先作为技术经理，你需要做的事情有哪些:

自我职责确认

分派开发任务；提升代码质量；项目管理；团队管理（招人绩效等方面）；这些事情都需要你来着手做。

思维的改变

技术经理更注重于架构决策和保持技术敏感，技术经理比小弟少了很多一线code time（只是少不是无），一线的工作交出去，做架构决策，架构升级，对比和引用新技术。

我见过把自己累的要死的技术经理，小弟遇到的问题你可以去引导，去提供思路，但是绝对不要亲手帮他完成这个模块自己写。

无可厚非的是，作为技术经理，你的技术水平才是决定小弟是否信服的标准，小弟只看你技术。但是此刻你需要侧重的是架构决策，并培养技术敏感度。对于小弟的问题，确保给出方向正确的思路，引导他完成任务。其实对于高级程序员来说，哪怕你侧重后端or前端，只要明确了问题的正确解决思路+百度or谷歌，哪怕是不同方向的问题，依然可以比较容易的解决。这涉及到一些基本功，能解决问题，哪怕是能用好搜索引擎，也是一种能力，我见过连搜索的key words都提炼不好的。

不断的学习

技术经理其实需要的能力有很多。技术经理在我看来另一个角色可能是低配版的产品，因此基本的产品经理的思维是要具备的，需要对业务具备洞察力（一定的产品思维）。小公司没有项目管理DMO，你就是项目管理者，分派任务，估算工时，风险评估你得来（基础的项目管理能力）。小公司没有数据分析师，你得具备数据思维，去通过业务数据的异常变化分析问题和预测（基础的数据分析思维）。向上管理即和boss打交道，同级别跨部门的协作，需要你的人情世故。说到底，产品需要赚钱，铁三角中的产品甚至业务也需要你的建议并参与决策（商业思维）。

带队即带人：招人、培养人、淘汰人。

队伍的前提得先招人，当然，很多IT届破怕滚动多少年的老手来说，本身就有一定的圈子可以“呼朋引伴”直接拉起一支熟悉又有战斗力的队伍。技术经理一般配合公司hr做好这件事情，但这个过程是非常漫长痛苦的，招一个不合适的人，人产生的问题，需要更多的成本去解决这个问题甚至这个人，然后开始循环；

招聘的时候技术经理得根据业务算好配比，比如粗略举个例子 产品：前端：后端：测试 1：2：4：1 这种比例。

在招人的时候往往容易忽略层次配比，这和上面的业务结构配比不一样。比如你手头队伍有7、8个人（纯技术方向），你得确保能核心技术骨干2名（大概阿里P6级？），其次也能扛起某块业务的，能比较不错完成任务的成员3、4名（P5？），剩下几个可能是基础的CRUD类型的（P4？）。这种结构健康在个别成员的替换性不会影响整个team的健康性，且整个team内部技术仍然具有很大的提升空间。

从招人、确定他的职责，引领他融入team的文化或者往小了说，team氛围中后，其实整个团队就可以开始运转了，一般的小公司也确实是这样做的。但作为技术经理，无论是为了个人以后的发展还是公司以后的发展，心中得预留一份职责体系的存在，并在发展到适当规模时引入。

职责体系的确立往往在技术团队壮大到50人以上的规模。下图是阿里的P技术岗和M管理岗的级别划分。

职责体系的确立，从员工层面，为其提供了上升通道，其实也是一种激励措施，毕竟晋升意味着加工资。但晋升考核的原则依然需要技术经理参与评定，评定标准比如：所创造的企业价值、个人的成长、态度上的积极主动、原则上如没有触碰公司红线等等。其次一般大公司晋升也需要进行一次答辩来具体评判。

职责体系的确立也为招人提供了明确的对比参照。我的经历中，一些小公司的招聘，面试官特别是初级的面试官，尽管水平达到了该岗位的要求甚至超出，但是并没有丰富到足以弹性地改变自己来有效测量出不同水平不同层次应聘者的真实能力的，具体体现在一组面试题，不管谁来面试都是问这些。在有了职责体系后，不同级别的划分显得清晰，可以直接根据需要确定招聘岗位的级别，并考察对应级别内的应试者能力。

职责体系也包含了责任体系，其中最重要的肯定是重大事故的惩罚制度的确立。这一点具体制度方面我不是很熟悉，但最终还是看你给公司造成了多少钱的损失来评估事故等级。

没开过人的技术经理不是好技术经理。

当然从个人情感上，肯定是不想开除任何一个人的，但是由于公司或者团队又或者个人能力上的各种因素，技术经理这个职责需要你承担这个角色。好好说就行了，人情世故。

企业文化不谈，从一个技术经理出发，你应该需要建立或者影响这个team的团队文化。我不是想说很虚的东西，举几个例子：

学习文化：团队内部是否有持续有频率的分享；

帮带文化：团队内部老人带新人的风气；

做事原则：对自我的要求，比如代码风格上，比如你的责任心原则心上…

从前我也以为很多的所谓“文化”是扯淡，也确实很多人形式上在“扯淡”，这种文化的形成是内部顺其自然顺水推舟的，而不是强迫性命令性的从上层开始形成的。

其次这种文化的潜在作用可能非常容易被轻视：通过一些分享，team可以保持对前沿技术的关注；分享不一定需要你对最新最难的技术有了不起的认知，也可以是同事彼此的作业，比如你是后端，我是前端，彼此做一些不同方向的分享，这对保持了技术深度探究的程序员来说，也是一个广度扩展的良机，team应该提供这种机会和氛围，让成员成长。这种类型的分享还有一个好处就是，team成员能快速了解彼此手头在做的事情，在有了不同擅长领域的沟通后，增强了团队内工作内容的可交叉和人员的可替换性，分享看似浪费时间，反过来确可以兜底团队文化甚至团队水平；再比如check list，这也是一种良好文化的体现，往小了说其实就是一些日常的习惯或者细节。

我个人非常喜欢分享这种形式，但是作为一个技术经理，你可能需要考虑更多分享前的规划：确认找的人是有责任心、愿意思考复盘、且有分享欲望，分享的内容是什么，给分享者的激励…

我作为早期的核心参与者，经历了两家创业公司，也许是成功来之不易，所以只能多从失败中去多思考。

一个产品的失败有很多因素，作为技术或者技术团队管理者，在创业团队早期承受的压力是比较大的，很多时候，不仅是产品经理或者boss，自己技术团队内的任何一个人都可以依据自己的理解来指出产品上技术实现上的某点不足，技术经常背锅是常态。“用户体验”是产品的核心，可以被任何一个人挂在嘴边，来指责你所实现的产品的话题，因为人人都是用户。这点正确嘛？正确。这是产品存活的关键嘛？我认为不是！

市面上（专指国内），其实我很难找到某项app所实现的功能是完全无法复刻的，换言之，技术无法实现的产品很少很少（当然暂不讨论一些AI大数据类的专技术指向型公司）。在我看来，国内大部分公司，包括最小也是最广大的创业型公司，技术其实永远不是短板，一个产品或者业务体系中，技术基本是处于领先地位的。

从技术人的角度去看，技术可以不断进步，产品也可以不断优化，用户体验我也可以一点一点地哪怕花80%的精力去提升5%点地方的细节来优化用户体验，但是以我的经历，产品或者业务的失败与技术关系真不大。

很多赚钱的业务，可能没什么技术。

你的商业模型中真的需要一款重型的app？公众号、小程序、乃至抖音快手b站，哪个都可以作为渠道去嗅探市场。一个真正切合市场的业务，其实不需要多么高深的技术。以风口猪理论为例，在风口下，只要你做出来的东西能跑，你就能赚钱，这时候技术人喜欢的类似于性能优化需要嘛？需要，也重要！但这并不能让产品或者公司活下去。

模式是运营出来的，不是技术开发出来的。

产品的商业模式，是运营出来的。我不知道在哪里看到的这句话，不过在经历过一些事后，这句话深深地印在我脑海中。在我看来，任何一家非技术型的公司，运营的投入都是要远大于技术的。

创业公司，在基本盘业务上，不运营用户，不做商业数据分析，不采集用户的问题和建议，仅仅是领导层作为用户觉得某个方向可以深挖，并且自恰出一套逻辑。这套逻辑或许可行，但是没有经过严格预案和深入的调研（往往这一步也并不被重视），交于了产品，产品此刻也只是boss需求的翻译器，开始根据老板的需要，设计原型 开始 -> 开发 -> 测试 -> 上线…。上线之后由于没有配套的运营方案，大部分也只能根据自有的稀少的自然流量，去产生这个新功能（或者这项新业务）的体验用户，转换量极低。整个团队一个月的工作可能最终只服务到极小部分用户，且不产生创收，此刻领导层可能觉得效果并不理想，并已经酝酿出了另一个自恰的逻辑…这是死亡循环的开始…

CTO职责铁三角：商业、技术、团队