这可能是我职业生涯中的又一个重大决策点。虽然当下看似不那么重要，但事情的发展需要时间去验证，而这次的预感大概率是真实有效的。

现状

从 2018 年进入公司开始，目前已经是第七个年头了。从工作体验上来说，我已经以“自由人“的身份工作了很长时间。这里的“自由人“是指：并不特定归属于任何小队，有需要时穿插工作，同时手上有几个一直作为 leader 维护的项目。有些项目直接面向产品，跨团队协商方案、协调联通性的事情也经常发生。与真正 leader 的区别仅在于：并未参与人员分配、并未真正管理团队，大部分任务仍由我本人完成。

从实际意义上来说，我已经走到了职业生涯的关键节点，面临重要抉择：是扩大自己的影响力、增强话语权、提升协调沟通能力，从而成为能承担更多责任的对象；还是继续深耕技术路线，拓展技术视野和能力，专注于技术实现。这是一个非常关键的决策问题。并非说二者不能兼容，而是需要有所侧重——人的时间和精力毕竟有限，侧重取舍必然导致资源分配的偏移，这是无法回避的现实问题。

不确定性

编程初期，绝大部分内容是完全确定性的，只有对与错。这非常好，提升速度和信心迅猛增长，任何方案只要逻辑正确，都可以实现。

到了一定水平后，面对的就不再只是非黑即白的世界。你会发现，可能有多种技术路线都能达到目标效果，每条路线都可能隐藏着只有深入实践才能发现的问题，而且并非所有问题都能完美解决。这时就需要面对方案选择时的不确定性和风险管控，需要基于自身对技术的理解和路线的认知，找到适合当前团队状态的方案。如果在实现过程中还能培养出更好的能力，那无疑是锦上添花。

走过上面两个阶段后，日常业务和工程实现能力应该已经相对成熟。接下来面临的是更大的挑战：前方是完全不确定的现实环境和混沌的前景。即使按照论文和技术规范做出的实现，如何评判其正确性和有效性也成为难题。软件层面能做的事已经尽力而为，但真正的有效性需要通过较长时间的持续观察，才能形成一个相对清晰的认知。

近一两年，我已经做了几个这类项目：有的是完全验证性质的demo，后续整合由他人接手；有的需要上线展示并持续观察；还有些会因用户环境差异而产生不同效果，无法完全模拟，只能基于RFC描述，在硬件正常运作的前提下，确保功能正常。

这些项目已经突破了技术层面的非黑即白区，面临着硬件、用户等更多非标准化的不确定因素。它们走向了真实世界，而不仅仅局限于自己的小圈子。

更大的不确定性来自于人以及人所构成的社会环境。我们需要明白，技术上的最优解不等于市场上最受欢迎的解决方案，也不意味着它一定会被广泛认可并使用。这是三个不同的维度，而非同一件事。许多产品方案从技术角度看似乎很“愚蠢“，但却成为了行业标准且无可替代，因为标准的形成往往不是基于技术的最优或最美，而是恰好符合特定时机的需求。比如最近的 MCP 协议，本质上是个基于 stdin/stdout 或 SSE 的协议（HTTP1.1 + stream + JSON body），从技术角度看并不优雅。

leader 的想法

任何 Boss 都期望团队中的 leader 能够全面覆盖其负责的事务，包括方案和时间规划、团队协调、人员管理等各方面。他们希望交付的任务能够有完整的过程和产出，不需要自己再次插手。能做到这些的人才是真正的骨干 leader 或项目组负责人——将事情交给他们，上级会感到放心，且最终产出符合预期。

而我的问题在于：虽然处于项目“自由人“的角色，但并未完全履行所有职能。我产出的代码是符合预期的合格品（自认为），但在协调工作以及项目后续监管方面做得不够到位。

最近发生了两件事：

• 项目线上数据出现异常，虽然最终由我解决，但发现问题的是 boss；
• 做的功能在代码和自测方面没有问题，但因个人原因，没能积极协调同事进行联调测试和反馈。

作为单纯的技术人员，这两件事或许不算大问题——协调和后续监控本可以由团队 leader 与其他成员沟通并安排。但若要担任 leader 角色，这就意味着工作没做全或没做好。真正的 leader 不是通过任命产生的，而是在长期承担 leader 职责后自然而成的。这有点像编程中的“鸭子类型“——如果你表现得像个 leader，时间长了，你就成为了 leader。（这里不考虑办公室政治因素，纯以技术职场而言）

我在这两件事上的缺失原因很简单：

• 项目上线后，由于缺乏评判数据正确性的准确标准，加上已有基本数据，我对异常情况不够敏感；
• 坦诚地说，协调人员并非轻松之事。我原本的想法很简单：如果事情紧急且影响重大，我会立即设计方案并通知相关人员，必要时协调紧急会议；但若非紧急事项，只是在工作群发条消息，期待但不主动跟进验证。

这本质上是对自身定位和职责认知的问题。

决策与未来

有人点醒我是件好事，这确实是职业生涯中的关键决策点。经过多年的编程实践，我在软件行业从底层到上层都有过接触，但我并非各领域的绝对顶尖人才。

有些人以数学为基础进行编程，有些人则以逻辑思维为基础。我可以肯定地说，我不是那种以数学为基础的顶尖选手，我的强项在于逻辑思维。而以逻辑思维为主的人在某些领域会有明显薄弱点，比如面向用户的美学设计和面向硬件的数电基础等方面。仅凭单一思维模式难以达到所谓的最高境界，必然存在局限性，每个专业分支都需要相应的学科基础。

向人的方向多靠一靠，尝试管理和协调的角色，未尝不是一种合适的选择。多尝试，总不会错。

结语

站在这个职业十字路口，技术与管理的选择并非非此即彼，而是寻找适合自己的平衡点。无论最终选择哪条路线，清晰认识自己的优势与短板，有意识地弥补不足，都是不断成长的关键。或许，正如软件开发中常见的迭代思想，职业发展也是一个持续调整和优化的过程。唯有不断实践和反思，才能找到最适合自己的方向。

请登录后评论