遇到不懂业务的领导，不用急着生气。很多时候不是他不愿意弄懂业务，而是岗位属性决定，不需要掌握和你同等深度的专业细节。他的核心工作是统筹资源、把控项目进度、管理人，同时向上汇报；而你负责落地具体执行。你们看待同一件事，只是站在不同角度。硬要让他吃透技术细节，相当于让他替你写代码，既不现实，也没有必要。向上管理的核心，不是把领导培养成业务专家，而是让他在不精通业务的前提下，做出对你有利的决策。
和这类领导沟通，第一件事就是把专业术语转换成他能理解的语言。他关心的重点无非是成本、工期、风险、人员，还有上级对项目的评价。你和他聊系统架构、算法选型、技术债，他很难听懂，不是理解能力不足，只是这些内容不在他的决策考量范围内。需要换一套表述。举个例子，计划做系统重构，不要讲微服务拆分，换成这样表述：现在不调整，三个月之后每次版本发布都会多消耗两天工时，客户投诉量会上升，团队持续加班扛不住，到最后要么增加人手，要么流失客户。这样一说，他就能明白这件事和他的KPI直接挂钩。信息翻译得越具体，越容易获得他的支持。
汇报的时候不要抛出开放式问题。如果你问领导这件事该怎么处理，他不熟悉业务，只能凭感觉拍板。要准备好选择题。A方案对应的成本、周期、潜在风险；B方案成本更低但周期更长；C方案上线快，但会遗留隐患。每个方案附上你的推荐意见，但是把最终决定权交给他。由他敲定方案，会拥有参与感和掌控感，后续项目出状况，也不会全部归咎到你身上。提供的信息越清晰，他做出决策的偏差就越小。
预期管理也是关键一环。不懂业务的领导很容易拍脑袋定下交付时间。单纯解释任务无法按时完成，他很难理解，只会觉得你在推脱工作。要用他听得懂的方式提前提示风险。比如这个需求评估下来最少需要四周，如果压缩到两周，只能砍掉测试环节，上线之后故障概率会提升，后续救火依旧占用这批人手，还会影响下个季度交付。把潜在后果摆出来，交由他权衡取舍。如果他依旧坚持压缩工期，把风险整理成邮件，抄送相关人员。这不是告状，只是留存记录。
建立信任，比任何沟通技巧都重要。他不懂业务，但能分辨谁靠谱。你每次承诺的事情都按时落地，分阶段交付成果，让他有内容向上汇报，他就会慢慢信任你。这份信任是向上管理里很重要的筹码。但不要让他感觉你在架空他。重要事项同步给他，对外汇报由他主讲，功劳分给他一部分。这不算是讨好，而是给他安全感。有安全感的领导，才不会处处防备你。
沟通场合也要挑选。领导业务不熟，当众直接反驳，会让他下不来台，之后你的所有意见，他都会先带着防备。私下找他沟通，用请教的语气，先说有个事情想和您核对，或许是我理解有误，再把事实讲清楚。他接纳观点之后，会议上的决策自然会调整。公开场合维护他的面子，私下落实实际问题，这个顺序不能颠倒。
他虽然不懂业务，但会掌握别的信息。清楚哪位高层需要重视，哪些部门不能得罪，预算从哪里申请，这些信息往往是你获取不到的。把领导当成资源，而不是阻碍。可以询问推进这件事，高层会不会有异议，他给出的信息很多时候是你无法自行打探到的。不用在他不擅长的业务领域和他争辩，学会在他熟悉的方面借力。
另外一点，不要替他包揽全部决策。一旦你全权代做决定，后续出问题，他很容易甩锅，风险全部由你承担。需要他确认的事项，让他签字或者口头确认，就算他不懂业务。你需要的是流程层面的授权，不是他的专业判断。邮件、会议纪要做好留痕，不是防备领导，而是保护双方。如果他给出不合理的指挥，可以先执行，同时设置检查节点。完成一部分之后，带上数据反馈给他，告知按照这个方案推进，当前情况如何，继续执行会出现什么结果，询问是否调整。让实际结果来说话，远比反复争辩更有效。
你没办法让不懂业务的领导变成业务专家。能做到的，是让他站在自己的岗位，做出对你有利的选择。这件事需要耐心，也讲究方法。不要把精力浪费在抱怨上，重点做好信息转换。翻译得越到位，你的工作阻力越小，他管理起来越省心，你获得的自主空间也会更多。
