老板不放权，FDE还能干什么？

01 FDE，真的在前线

2010年，阿富汗坎大哈附近的一个军事基地，来了两个工程师。位于美国硅谷的总部给他们的全部指令，就一句话：去那儿，赢下来，需要什么打电话。

就这一句。没有很厚的需求文档或者指导手册，没有排期表，验收标准只有一个字：赢。

其中一个人叫马克·夏纳（Mark Scianna）。他在阿富汗待了几个月，白天在保密网络上架服务器，装机、接线、做数据集成；晚上坐直升机去巴基斯坦边境附近的前哨基地。那种地方没有网，他们得自己架一套卫星链路，把通信接回总部。

第一次坎大哈驻场，他就待了三个月，原因很简单：要学的东西太多。

2011年夏天，他一直跟随一支海豹突击队行动。躲了一整周火箭弹之后，同事给他转来一篇博客，标题叫「为什么Palantir让我头疼」。文章里有一句判断，说这帮人不过就是换了个花哨头衔的咨询顾问。要知道，Palantir就是他所在的公司，主要业务就是为美国政府和美军提供技术支持。

现在满世界都在聊的FDE（前线部署工程师），听起来好像是最近半年才火的，但这个岗位在他们公司已经存在将近20年了。马克做了11年FDE，2019年才离开创业。

从阿富汗到伊拉克，再到非洲战乱区，他都驻扎过。我就是从他的博客里看到了非常多的照片和细节。

所以他说，那个非常蔑视地称他为「换了花哨头衔的咨询顾问」的说法，让他觉得很不真实。因为那一周他干的事，是躲火箭弹、接数据、培训军人、调那些烦人的数据库。而就在此前两个月，美军刚刚完成了突袭本·拉登的行动。

我读到这一段的时候，意识到一个问题。现在满世界都在聊FDE，前线部署工程师，聊的几乎全是后面那个词「工程师」：年薪多少，要会点什么，值不值得转行。很少有人去看「前线」那两个字。没想到这个岗位里的前线，一开始是真的硝烟弥漫的前线。

02 总部定目标，前线定打法

那句「去那儿，赢下来」背后，有一套明确的指挥逻辑。我专门去查了一下资料，它还真有个专门的词，Auftragstaktik。

听不懂很正常，因为这是德语，表示的含义是「任务式指挥」。这是从普鲁士军队传下来的：总部只负责把目标说清楚，至于怎么打、用什么打、先打哪儿，几乎全部下放给前线的人。

其实之前华为老说的「让听得见炮声的人做决策」，表达的也是一个意思。

具体放到马克这样的一线工作人员身上，工作就全变了。什么算赢，这是总部定的。剩下的全是他自己定的：先迁哪些数据，先培训谁，从哪个部门往上扩。

他只在两种时候往回打电话：一是真需要总部的技术支援，二是彻底卡死了。

总部定目标，前线定打法。

只是当初估计他也没想到，自己做的事情，会在2026年成为全球最热门的技术岗位之一。

03 老板也在改造范围内

第一道门槛，是买单的这位甲方老板能不能接受：自己也在改造范围之内。

我们先把这个说清楚，因为我见到很多创始人完全低估了AI化对企业的冲击，以为请人来做AI落地，就是买一套东西装上。

实际上工程师一动手，先碰到的就是流程。原来一个单子走五个人、盖五个章，现在发现其中三个环节没必要，那三个人的活儿就得重新安排。

流程一改，岗位关系也跟着动：谁向谁汇报，哪个部门以后不需要那么多人，都会被翻出来。

再往下，碰到的是公司怎么对待错误。原来你们公司出事就要追责，现在前线工程师告诉你，第一版就是可能会错，得让它先跑起来，收集到翻车数据，才能越来越好。

还有，因为可能动了不少人的权力或者利益，所以肯定会有人竭力证明AI干不了自己的活儿。

而且这还不算。你还得容忍一个来了两周的外人，在你的地盘上做出一些你自己绝不会做的决定。他可能压根不请示，因为请示了就来不及，或者这个机会就没了。

我们站在外面看，很容易把这件事归结成传统老板舍不得权、不肯改。可你真站到他那个位置上看，他担的风险是实打实的。

他要把自己公司最要害的数据、最挣钱的流程，交给一个刚认识没多久的外部团队去动。改砸了，客户投诉，季度报表难看，甚至那几个忠心耿耿的中层，跑到他办公室哭。

这些代价全是马上就发生的，而AI化的好处呢，可能要等半年、一年才看得见。当然，还有可能看不到。

更别说流程被理顺之后，很多原来靠上下传达、靠信息差活着的位置就没了。

那些位置上坐着的，往往还是跟着他打了很多年仗的老人。很多企业里，经常有句话，「某某某是某某某的人」，这句话本身就透露出非常多的信息。

所以，AI化改革这件事对很多老板来说确实要命，并且很难。我非常理解这种感觉。

但这道门槛过不去，全球最强的FDE也解决不了你厂子的问题。

因为你不放权，人家没法在现场做决定。能动的就只剩那些不影响任何人的边角料，最后交付出来几个不痛不痒的小工具，比如出个营销短视频文案啥的，非常安全，非常无聊。

这样的合作更接近成熟的技术外包。技术外包也挺好的，能解决一个确定性的问题，只是别指望它带来AI变革那种山呼海啸般量级的改变。

04 FDE得画出真实决策链

第二道门槛，才轮到我们关注的那个工程师。

这道门槛比大家想的高得多。很多人会觉得，是个资深工程师就一定能胜任，其实差得还挺远。到了客户现场，最难的是搞清楚这家公司究竟怎么运转。

谁说了算，谁看着不管事其实有一票否决权，哪个规矩没人写下来但谁都不敢碰。这些东西，没有任何一份文档会告诉你。

一个FDE能不能干成，有个更实在的检验方式：进场两周，他应该能画出这家公司真实的决策链。

对很多公司来说，这个跟协作软件，比如飞书、钉钉里的组织架构完全不一样。这种对一个组织的洞察，其实非常考验人。

所以这句话，老板可以拿去验人，FDE工程师也可以拿去验自己，看自己是不是能做到。

还有一点，这活儿的干法，跟做产品的人的直觉是拧着的。到了现场，第一件事是先趟出一条能走的路。

哪儿泥泞就垫两块石头，哪儿绕不过去就先架个梯子。虽然又土又难看，但它毕竟通了，客户今天就能用上。

Palantir的人管这个叫「先铺碎石路」。等这条路上跑的人多了，痕迹稳定了，再把反复出现的那部分抽出来，修成一条正经公路，做进正式产品里，提供给更多客户。

顺序千万别反，先修公路再找人走，是绝大多数落地项目死掉的地方。所以，千万不要一上来就改造别人的一条核心系统。

说到这里，我想起来，我在硅谷的时候跟一位投资人也聊过这个事。他告诉我，他接触的头部FDE公司会把产品团队里的核心成员派到客户现场，通常派出去的人级别都很高，能独立在现场做决策。

而我见到的不少挂着FDE名头的岗位，实质还是SaaS公司原来那套外包关系。有些项目卡住，往往就是因为他们没办法改任何东西。

05 先铺碎石路

其实到这里，说了这么多FDE的历史和问题，那到底该怎么办，我也没有答案。

我自己也在试。一个试法，是把人直接派进另一个部门，不当外援，就当那个部门的员工待着。

另一个试法，是让一两个同事站在业务同事身后，盯住一个特别细的环节。先看、先观察，然后直接用vibe coding的方式把问题解决掉。

啥意思呢？就是不走排期、不立项，谁看见问题，谁当场写个小东西把它接上。能用就行，先不产品化，也不做成固定功能的插件。

特别是对于很多公司来说，过去搭建了大量复杂的后台系统。我最近也在考虑，怎么在不动这些历史后台的情况下，用更AI、更简单的方式，把原来需要进后台才能完成的功能替代掉。

这就是前面说的先铺碎石路，不着急修公路。因为我自己也还在试，说不上哪个对。等到有一些可以分享的案例，我会再拿出来和你聊。