去年冬天，朋友托我帮他的创业公司看一份简历。
候选人在东京一家做工业软件的会社待了十四年，履历上写满分布式任务调度、实时数据处理。技术面试聊得挺顺，直到问薪资期望，他沉默了几秒：“按我现在的职级，一年大概三十万人民币。”
我和朋友对看一眼。放在国内，以他的技术深度，这个价码翻两三倍都算保守。
但钱不是他真正的困境。他十四年里，有十三年在做同一件事——执行。
上面定好的方案，他来实现。架构怎么搭，会议室里拍板的人不写代码。他想过反驳，试着提过两次优化建议，第二次之后就没再提。他跟我说了句话，我记到现在：“在这里，提意见的次数，是和你的工龄挂钩的。”
过去几年因为业务关系，我接触过不少从日韩大厂出来的工程师。技术扎实、文档规范、对质量有近乎偏执的坚持。但普遍有一个共同特征：话少，而且习惯了不被问意见。
一、森严的上下级，压住的到底是什么
几套机制叠在一起
日本这边，年功序列制名义上淡化了，论资排辈的影子还在。加上稟議（ringi）制度——一份提案要在组织内层层传阅、逐级盖章，走完流程才能落地。技术方案从提出到执行，中间隔着五六个签章。
韩国那边更直白。前后辈（선배/후배）关系嵌进日常，语言体系本身就带敬语层级。大量男性员工服完兵役进入职场，军队里那套服从逻辑被整套搬进办公室。
这些机制在制造业时代是有价值的：保证质量稳定、避免决策失控。放到软件研发领域，代价就出来了。
代价一：技术判断让位于职级排序
一个在首尔某大厂做了七年后端的工程师告诉我，他们组里评审一个数据库选型方案，会上没人从吞吐量、一致性这些角度吵，吵的是“这个方案是哪一级提出的”。课长提的，哪怕有明显的分片键设计缺陷，也没人当面指出来。
代码缺陷可以修，选型错了要重构半年。但没人愿意用自己的职级去换这半年的工期。
信息传不到能拍板的人耳朵里，拍板的人又不写代码。这是研发效率最大的黑洞。
【金句：在等级森严的组织里，最贵的技术债往往不是代码写错了，而是没人敢说它写错了。】
代价二：信息在传递中被过滤
日本企业的“報・連・相”（报告、联络、商量）文化，本意是让信息流动。执行层面出问题，现实往往是：现场发现的事，逐级上报到高层时已经变形。
一个在东京做金融系统的朋友讲过他亲历的事。团队发现某个批处理任务在高负载下会丢数据，组长第一反应不是拉人排查，是问“这个问题现在报上去，会不会影响本季度的进度评价”。最后先做了个临时补丁压着，三个月后系统上线第一周出了事故。
不是没人发现问题，是发现问题的人，先要评估“说出来的风险”。
【金句：当汇报的代价高于故障的代价，组织就会系统性地选择沉默。】
代价三：评价体系把“熬”当成了能力
年功序列的核心逻辑是：时间和忠诚可以兑换位置。这在稳定增长期成立。放到技术迭代以季度计的行业，结果就是——最能打的人最先走，走不了的人开始“表演忙碌”。
留下来的人里，有两种。一种是真的热爱技术，靠自我驱动在业余时间补课。另一种，把精力放在了让上级满意上。
对创业者来说，这里有个信号值得注意：从日韩体系出来的工程师，履历上的“职级”参考价值有限。 他在原公司的位置，可能反映的是入职年限，和他真实的技术水位关联不大。
二、客观说，这套体系也不是一无是处
不能只讲缺点。
我见过从这类企业出来的工程师，文档写得比国内大多数团队规范得多。接口定义、异常处理、回滚方案，写得清清楚楚。做代码评审时，他们对边界条件的敏感度，常常让人佩服。
日本制造业的“改善”（kaizen）文化，让很多人对质量问题有近乎本能的警觉。韩国的“빨리빨리”（快点快点）文化，又让一部分人对交付速度有极强的执行力。
问题在于，这些优点是在特定的组织约束下长出来的。换个环境，优点能不能延续，取决于新环境给不给空间。
三、给创始人的实操建议：怎么识别、怎么用
如果你在找技术合伙人，或者打算从这类企业招人，下面几条是能直接用的。
1. 面试时，别问“你怎么做”，问“你当时想怎么做”。
日韩体系里待久的人，习惯性回答“我们团队怎么做的”，很少讲“我判断应该怎么做”。你可以直接问：“那个方案，如果让你一个人决定，你会改哪里？”看他的第一反应，是继续端着，还是眼睛亮一下。
2. 给一个没有标准答案的问题。
比如让他设计一个你正在纠结的场景。重点不是答案对不对，是看他会不会主动追问边界条件、会不会明确说出自己不确定的地方。习惯被指令驱动的人，往往卡在“等需求”这一步。
3. 入职前三个月，主动把他的判断“逼”出来。
这类工程师不是没想法，是不习惯在公开场合表达。一对一沟通比群聊有效，书面异步沟通比会议有效。给他一个明确的信号：在这里，提反对意见不加分也不减分，只对错论。
坑一：以为“大厂背景”等于高能力
前面说过，职级和技术的相关性在那套体系里被稀释了。看简历时，把公司名和职级放一边，直接看做过什么系统、扛过多大流量、解决过什么具体问题。
坑二：招进来又复制一套层级
见过最可惜的案例：老板花大价钱挖来一个技术很强的工程师，结果三个月后，对方成了一切听指挥的执行者。原因简单——老板自己开会时习惯打断人、习惯先给结论。人不是被制度压住的，是被日常互动一点点驯化的。
坑三：忽略他们对稳定关系的需求
这类工程师普遍看重长期关系，对频繁换方向、朝令夕改的容忍度低。创业公司天然动荡，你要提前讲清楚：哪些事情会变，哪些底线不变。把不确定性摊开说，比画大饼留人有效。
坑四：用国内节奏去要求他们
不是能力问题，是工作习惯的差异。他们在原环境里被训练成“先想清楚再动手”，你催着他“先上线再说”，他会非常难受，而且容易出低级错误。给一段适应期，让他理解你的迭代逻辑。
四、总结与行动清单
日韩企业森严的上下级关系，压住的不是技术能力，是技术判断的表达权。它把一批本来能主导技术方向的人，训练成了高质量的执行者。
对创业者而言，这是机会，也是风险。机会在于，这批人里有很多被低估的高手。风险在于，你如果只是把他们当成“便宜又好用的执行者”，那他们迟早会用同样的方式对待你。
三条马上能做的练习：
-
翻一遍你手上所有技术候选人的简历，把“公司名+职级”用笔划掉，只看项目描述。 重新评估一遍，你会发现排序变了。
-
在下次技术评审会上，明确说一句：“今天谁的方案被我否了，会后单独找我吵，吵赢了改。” 观察谁真的来了。
-
挑一个你已经定了方案的技术决策，故意问一个工程师：“如果推翻这个方案，你会怎么选？” 看他给的是客套话还是真话。
AI 工具和信息差不解决这个问题，人和人之间的表达空间才解决。
如果你正在组建技术团队，或者曾经从日韩体系里挖过人，评论区聊聊你的经验。觉得有用的话，转发给正在找技术合伙人的朋友。
