「技术人生」专题第1篇：什么是技术一号位？

前言

 

什么是技术一号位、有哪些关注点、怎么做技术一号位？

 

做了研发团队的技术 leader 以后，要处理的事情非常多，如果对自己扮演的角色没有一个清晰的认知，就会出现该做的事情没有做，不该做的事情投入了过多的精力，造成实际行动和结果既不匹配上级的要求，又不匹配下级的期望。特别是对于刚开始带领研发团队的新人 leader 而言，角色的转换和适应的过程，增加了认清自己的角色本质的难度。今天我们抛开纯技术团队的同学不谈（其实本质一样），只讨论业务研发团队的同学，如何以技术一号位的角色来做事。

 

如何识别自己是不是技术一号位

 

在开始谈如何做事之前，首要任务是判断自己是不是技术一号位，而要判断之前，首先要明确判断标准，跳出思维误区。这里我们列出一些常见的思维误区。

 

以下是常见认知误区：

1. 带人的是技术一号位，不带人的不是技术一号位。
2. 级别高的是技术一号位，级别低的不是技术一号位。

 

以上的认知误区，错误地把是否带团队、技术等级的高低和是否为技术一号位关联起来。虽然事实上带团队的业务研发同学成为技术一号位的概率更大，但是本身这两者不是划等号的关系。

 

那么什么是区分是否为技术一号位的决定性因素呢？很简单：对一个具体的业务而言，你作为该业务的直接技术参与者，是否处在技术领域责任链的最顶端。这句话翻译过来就是，对一个明确的具体的业务而言，多种角色的同学一起合作的时候，你是否是技术序列的最终责任人，即：谁承担对应的责任，谁就应该扮演对应的角色。

 

当产品经理、运营、研发共同做一个业务的时候，某个研发同学独自或者带领其他几个研发同学，或者带领跨 BU 的研发团队，共同支撑 PD 的业务需求。那么这个研发同学就是这个业务的技术一号位，不论他是否带不带人，也不论他带的人在行政上是否从属于他。一般来说，负责单一业务的研发团队 leader 一般就是这个业务的技术一号位；负责多业务线的研发团队的 leader 的下属，是每个业务线的技术一号位，而研发 leader 本身是更高层面业务的技术一号位。

 

所以，做业务开发的技术同学，不论是什么层级，带不带人，都可能是某个具体业务的技术一号位的。这一点非常重要，只有认清这个事情以后，业务研发同学才能在做业务的时候，明确下来自己除了需要写代码以外还需要做什么，关注什么；这些关注点需要做到什么程度，才能对上满足期望，对下不让团队走弯路、不和下属抢功。

 

当你经过以上判断以后，确定自己是技术一号位时，恭喜你，你已经不再是一个仅仅需要写代码的研发同学了。很多研发同学眼中还是只有写代码这一件事情，如果以这种方式做业务，那么就会发现业务过程会有各种没有做到位的事情，会在做业务的过程中“交很多学费”，甚至会因为自己的能力不够而拖慢业务发展。

 

虽然成熟的研发团队可以通过完备的研发过程管理，来避免个人能力不够而对业务产生太多负面影响，但是本质上强制的规定和“上级要求”只是在依靠行政管理手段在强制一个人做这些事情，并没有唤醒他的创造力和责任心，反而会被认为是“工作琐事”。

 

这些“工作琐事”本质上是需要他扮演的角色来负责的，但是由于他没有意识到自己实际上已经是这样的角色了，而仅仅把自己停留在“研发”的定位上，把“写代码”当做核心任务，这样一来，会让研发同学对那些看起来 “和写代码无关但是是技术一号位必须做的事情” 非常抵触。这种抵触情绪发生的时候，leader 再强调 Ownership 也都没有太多效果，因为不是他不负责任，而是他没有意识到，这是他应该负责的事情。当他的心态和认知转变以后，一些原来看起来不怎么负责的人会变得负责（不排除有人本身就是不负责的人，那么这样的人不是良好的技术一号位的候选人，主管要有识别能力）。

 

作为业务开发同学，一定要仔细认清辨别自己实质上是不是一个业务的技术一号位，而不用考虑自己的层级，不用管自己是不是业务其他参与者的 leader。当你意识到自己是这个业务的技术一号位的时候，就要迅速切换角色，从原来自己给自己的定位 “写代码的、搞技