决定职业上限的不是能力，是你解决的问题类型
同一个小组里，两个人写的代码量差不多，五年后一个还在做需求，另一个开始定技术方向。差距往往不在勤奋程度，而在他们每天处理的问题根本不属于同一类。
有位技术负责人分享过一组对比：同样是被同事反复咨询某个环境报错，有人问一次答一次，有人把排查步骤整理成文档，有人做成自助排查的小工具，还有人顺着根因找到架构上的不合理并推动改造。
四种做法的工作时长可能差不多，但它们沉淀下来的东西完全不同：前两种消耗时间，后两种在改变系统的形态。三年之后，能做的事自然分岔。
问题大致分四层
- 执行层：把已经定义清楚的事做完，边界明确，答案唯一。
- 优化层：在既有做法里找更省资源的路，需要比较方案。
- 定义层：现象模糊、目标不清，要先判断这究竟是不是值得解决的问题。
- 方向层：要决定未来半年组织把资源压在哪里，答案无人可问。
薪酬和话语权基本跟着层级走，而不是跟着工作量走。执行层的优秀可以让你拿到好评，但很少让你拿到定价权，因为能被清晰描述的任务，也容易被外包、被自动化、被更年轻的人接手。
一个技术骨干的转型样本
某电商公司的一位后端工程师，前三年把订单系统维护得非常稳，故障率很低，绩效一直是小组前列。到第四年他发现自己陷入了奇怪的处境：岗位重要，但可替代性也在上升，因为系统已经稳定到不需要他救火。
他做了一件事：把「订单一致性」这个反复出现的问题从故障处理升级为议题。他整理了过去一年的十二次相关事故，归出三类根因，写出量化影响，然后带着方案去找主管，申请一个季度的资源做链路改造。
方案最终只批了三分之一人手，但这件事让他的角色变了：从维护者变成提出议题的人。第二年他带团队，靠的不是技术更强，而是他证明了自己能定义问题。
几个似是而非的说法
第一个误区是把熟练当能力。熟练处理的是「同类的旧问题」，能力体现在「没见过的复杂问题」上的迁移速度。在一个岗位上待久了，效率上升，但问题类型的复杂度可能反而下降。
第二个误区是用工时换成长。加班能提高产出数量，但如果你解决的问题类型没有变化，经验曲线会很快平掉。判断标准很简单：把今年和去年解决的问题列出来，如果只是重复，就要主动找变量。
第三个误区是把方法论当解药。学会几个模型不等于拥有判断力，方法论的真正价值在于帮你把模糊的现象拆开，而拆解的对象必须是真实的业务问题，否则就只是话术升级。
判断自己是否正在向定义层迁移，还有一个观察角度：你的产出能不能被移植到别人身上。一件事只有你在场才能推进，那更接近执行；如果它能沉淀成流程、文档或工具被别人接着用，说明你已经触碰到了结构层。
这周可以做的校准
花四十分钟，把最近一个月你做过的十件事写下来，逐条标注属于执行、优化、定义还是方向。多数人的结果是执行层占了七八成，这个比例本身不是问题，问题是它一年年没有变化。
接下来挑一件最小的定义层任务开始试。可以是把某个反复被问的问题整理成一份说明，也可以是给一次重复发生的事故写根因分析。定义一个问题的门槛远比想象中低，难的是持续做下去。