技术管理者如何避免被裁掉（1）

这个题目没有绝对可行的解法。原因是裁员与否、谁在名单上并不取决于题目中人，既然没有绝对的控制链路，那就没有绝对的结果。

实际上我们要讨论的是技术管理者的成长如何跟得上公司的发展需要，做大个人价值，一方面在如果有一个名单的情况下，尽量让自己不在名单内；另一方面，即便不得已被裁掉了，新工作也不难找。所以核心还是个人能力成长的问题。

而与技术管理者的成长最相关的是技术管理者对这个岗位本身的理解有多深。可能你现在还不是一个技术管理者，但这并不妨碍提前了解下这个方向下个阶段的重要内容。以下是芃篙的个人观点，给大家参考。

在技术团队中，技术专家转技术管理的情况尤为普遍，也尤为容易陷入迷惑。而技术团队的位置比较靠后，项目上大事小情资源调度，别人有求于你的居多，又容易让人衍生出一种团队管理不过如此的错觉。久而久之，管理上未得到其中三味，技术上又没有之前敏锐了，怎么办？技术 TL 需要搞清楚自己所在位置的核心价值是什么，仅仅是接需求-分配给对应的人-管理项目风险-保证项目吞吐率吗？当然不是。

01.理解组织

今天聊一聊第一部分，理解组织。芃篙认为每个人都需要理解自己所在公司的组织结构，自己所在团队的职能，以及自己的位置。

从技术管理者的角度则需要做到更多，首要的是视野上跳出本团队的局限，不能光盯着自己这一亩三分地。大的方面理解公司的组织架构以及组织架构背后的含义；小的方面再回头思考自己团队的位置和价值，组合起来就是团队存在的必要性和发展方向。

02.大层级的组织架构和三不管地带

组织结构背后有啥含义？芃篙现在也没有研究的很清楚，但是至少有三个方面可以去探索。其一是公司的业务重心在哪里，可能直接关系到人员在不同方向上的配比；其二是协同流的角度，业务是如何一步步到你这边团队的，需求来源有几个，不同方向链路上团队的职能是什么、目标是什么，这些决定了日常工作的合作模式。也是协同上发生问题对症下药的良方；其三是技术上的，康威定律的影响，业务团队的结构跟技术团队的结构存在关联关系，而技术团队的结构会直接影响软件的落地方式。这在某种程度上决定了一个项目是否可以按照预期落地、技术架构的发展方向等等。

而组织结构无论怎么划分，在实际运行过程中，总会出现“三不管”地带。芃篙认为这是管理者需要去重点解决的地方，组织结构代表了公司在组织层面“法”的因素，它规定了每个组织的职能；而各个层级的管理者，代表了组织中“人”的因素，他们需要去弥补“法”的不足。这样组织才能更好地运行起来。当然，这些地方在“KPI 大法”中可能属于吃力不讨好的位置，人性也是趋利避害、不愿意承担风险的，但是管理者存在的意义在某种程度上就是要“反人性”、反康威定律，才能促进组织发展。这也取决于技术管理者的再上一级怎么看待这类事情，大家的价值观在一个维度上，那么放手去干；如果不在，那么谨慎保守一些也无可厚非。

03.深耕自己的一亩三分地

在理解大的组织背景之后，再去看自己的一亩三分地，感觉是不一样的。之前可能就是接任务、分任务、完成任务这样的循环，之后可能就需要考虑任务都从哪里来，这些任务的价值是什么、任务链路上利益方都是谁、谁可以帮助我们解决问题提高效率、任务是否可以被更好的管理起来、这么多任务在宏观上对技术演进的要求是什么、团队的技术储备是否支持这样的演进、团队成员中谁更适合打哪个方向这样既提升任务消化效率又能带来这位同事的技术成长、如何调整团队成员的任务分配可以降低离职带来的团队运作风险……

举几个例子。

比如简单一点的，忽然接到一个从来没有接触过的诸如业务软件需要做到符合最新的某个区域的法规标准的任务，理解大的组织背景，你就会第一时间想到要去找法务合规部门了解这个法规是什么，从而再去细化哪些技术团队可能需要参与改造，再进一步确认都会有哪些子任务；

比如复杂一点的，团队成员总是反馈任务排得非常满，再加上突如其来的客户问题，会造成不少不可预知的延期。这个时候就可以从大的组织协同背景下，去梳理需求链路和售后问题的维护链路的各个协同方到底有哪些，他们的目标和优先级都是如何定义的，再进一步根据团队情况，定义标准的需求和问题的解决流程，跟各方约定好，把需求和问题管理起来才有进一步优化的可能性。诚然假如管理流程会降低某个小节点的效率，但是在大盘上会获得更大的收益。有了基本的数据支持，就会有更合适的调度方法，各方也更容易接受；

比如更加复杂一点的，比如从年度的任务大盘看，业务上更加要求软件交互层级的灵活多变，不同客户的个性化诉求越来越强烈，但是从人员配置上看客户端的研发资源并没有多余的空间。那么，如何才能用同样的人员消化更多的业务？方向可能有很多，但是可行性则需要对组织的理解。

引入跨端技术是否可行？跨端之后一个即使不能干两个人的活，干一点五个人的活儿是没问题的。但是前端团队是否认可，合作模式可能会发生变化，怎么配置团队更加合适？

更加开放，通过 SDK 方式给到外部开发者去做个性化业务是否可行？技术上可行，但是否会因为影响销售团队的业绩而被抵制？开放到什么程度是否需要更高管理者授权？是不是每个客户都有自研团队，客户是否会信赖外部团队？

引入外包机制，有限的开放源码给到受控外包，通过消化更多的业务负担成本是否可行？技术上定义开放层次、做好管控和编译部署方案依旧可行，但是项目经理团队是否会因为外包的能力问题会增加协同成本而消极配合？法务上这种模式是否符合合同要求？外包人员是否需要驻场，需要哪个团队出人来管理外包人员？

例子中都是提问没有答案，因为不同的公司、不同的阶段、不同的场景下各自有不同的答案。但是这都跟技术管理者如何理解组织相关。

所以说，技术管理者的对岗位的理解和成长方向的第一个因素就是需要加强对整个组织的理解。

好了，今天的分享就到这里，希望对你有帮助。本文在 2023 年 10 月 27 日 首发于同名公众号：技术管理者如何避免被裁掉（1），欢迎关注。