文章来源：微信公众号【CODING】 作者：Eduards Sizovs 编辑：陶家龙、孙淑娟
金三银四招聘季，公司的管理者都在思考：在现在的市场环境下，到底应该为自己的公司注入怎样的新鲜血液来维持发展。工程师们同样也在思考如何获得更多成长和晋升的途径。
Eduards Sizovs 是 DevHub 的创始人，立志于为软件工程师群体提供专业的职业咨询服务，同时也是一位欧洲知名的技术布道师。
今天 Eduards Sizovs 基于行业经历，介绍现在工程师市场中稀缺的 “T” 型人才（既拥有丰富的技术背景，同时对业务也有一定的理解能力），以及这类人才在组织中发挥的重要作用，为工程师群体描绘了一条新的职业发展道路，帮助个人和公司得到更长远的发展。
今天，我的前同事 Alex 给我打了个电话，讨论了一下他现在所在的新兴互联网公司的一些境遇。
Me：最近怎么样呀？
Alex：还行吧，最近公司在招一个首席工程师（Principle Developer）。
Me：那挺好的，你没去争取一下么？
Alex：我去了，但是被老板拒了，聊了一下他觉得我不太合适。
Me：你觉得自己能胜任么？
Alex：废话，我有 7 年的大型项目经验，精通各种架构，能持续产出简洁高效的代码并能主动去解决各类历史遗留问题，流转到我这里的工单都能最快速地处理。
我应该是全组代码水平最好，研发效能最高的工程师了，不提我提谁？
Me：那你想过没有，或许就是这个原因导致你没有被选上？
随后我们聊了些其他的事就挂了电话，虽然 Alex 不太高兴，但是我感觉还挺好的，因为找到了问题的关键。
于是，我给 Alex 公司的老板 Andrey 打了个电话。
Me：好久不见，听说你们最近在招首席工程师，为什么不直接从现有团队里面提拔一个呢？
Andrey：比如 Alex ？
Me：比如 Alex。
Andrey：公司现有的技术团队的确拥有很多很厉害的工程师，但是我认为他们都不太具备一个首席工程师所必需的素质。
Me：能展开说说么？
Andrey：这个事情的逻辑是这样的：一个首席工程师跟一般工程师的主要区别并不在于他是否是团队中最聪明的那个，而在于他是否有团队驱动力，是否能持续推动团队的改善和进步，能帮助团队中的新人快速地进阶。
虽然不一定要像精神领袖那么厉害，但必须具备相应的领导力，这种领导力不仅需要体现在研发团队中，还要能影响产品、运营、市场等部门的同事，甚至也要能在管理层拥有一定的决策权。
所以我认为一个首席工程师需要能在公司内更好更快地组织资源，推动组织整体向前，并带来正向的企业文化。
Me：所以你认为首席工程师在帮助工程师的同时也要去了解非技术人员的问题？
Andrey：没错，经常听到工程师们抱怨“业务方面”的同事完全不懂技术，沟通效率也非常低，但光是抱怨解决不了任何问题，必须要有人在中间搭桥，解决这些问题。
首席工程师的定位就相当于公司内部的外交官：
- 他必须有足够的沟通能力，能跟不同的人打交道。
- 能游走在不同的部门，打通上下层沟通渠道。
- 要敢于提出那些隐藏在公司内部却很少有人敢于提及的问题，并具备足够的领导力来赢得大家的支持。
Me：从你的描述来看，这个人既要有丰富的技术背景也需要有一定的对业务的理解能力。
Andrey：这个职位需要的是 “T” 型人才，不仅仅深耕于技术领域，对很多原理型的东西有深厚的积累，同时还要能延展出去，跟运维、品控、安全、产品、人力、市场等领域的人共同协作，帮助公司进步。
Me：感觉是一个一半工程师一半业务人员的感觉。
Andrey：理应如此，现在大部分研发团队都仅仅把功能上线的数量当作考评的唯一指标，这种方式其实已经过时了。
对于任何以盈利为目的的公司来说，赚钱都是公司最重要的目标之一。现在很多功能都是为了上线而上线，产品、技术、运营、市场等团队之间缺乏有效沟通，上线了一堆功能却没有办法给公司带来任何增长点。
我们需要更多 “业务型” 工程师，他们能从全局出发，理解整个产品从最初的设计到部署再到如何才能打动客户给公司带来更多的效益，能够找到公司现有的不足并承担起相应的责任来解决问题。
这些工作可能是解决研发流程问题，或者是建立新的跨部门沟通机制，甚至是解决招聘问题。
借助键盘来实现商业价值的机会其实远比工程师们想象的要少，如果你手中只有锤子，那你看所有的问题都觉得像钉子。
对于我的公司来说，越多 “业务型”工程师越好，而一个好的首席工程师能给其他工程师树立一个学习的榜样。所以我觉得找一个首席工程师的意义不亚于一个创业合伙人。
Me：但是按照你的标准，基本上已经筛掉了市面上包括 Alex 在内的 99% 的工程师了。
Andrey： 一个首席工程师是一个能给公司内不同组织都带来影响的人，这样的人正如你所说的，市面上 99% 的工程师都不能满足我的需求，但是为了公司的发展，也只能继续寻找了。
总的来说，我觉得我们这个行业需要：
- 不是“仅以上线为目的工程师” ，而是业务型工程师。
- 不是 “码农”，而是 T 型人才。
- 不是仅有 “抱怨”，而是跨组织沟通技巧。
