许多平台团队都困在同一个死循环里：工程师埋头开发了大量功能，技术架构无可挑剔，但内部开发人员就是不买账。Lucas Hornung 和 Christian Matthaei 的团队也曾深陷这种困境。在 KubeCon & CloudNativeCon 欧洲大会的主题演讲中，他们分享了如何打破僵局——方法不是写出更优雅的代码，而是学会把技术愿景翻译成业务部门听得懂、开发人员愿意用的人话。
Matthaei 回忆起一个转折点。他的上司打电话告诉他准备离职，团队能否继续运转突然充满变数。他被要求提高曝光度，向管理层做一个简短汇报，介绍自己是谁以及一个重要技术话题。他引用了 Simon Sinek 的观点：想让没有技术背景的人理解你在做什么，就要从“为什么”开始；想让人们按照你的建议行动，就必须让自己被看见。
你不能指望别人凭空发现你的方案有多出色。Matthaei 说得直白：你得走出去跟人聊，真正去听他们遇到的问题。他们开始主动约利益相关者开会，把对方的问题摆在桌面上，征求建议，然后认真倾听。听起来简单，却是大多数工程师从未系统学过的事。
光是聊天还不够。Hornung 发现，在商业语境里，价值必须被量化，否则就像没有锚点的船。他们引入 DORA 指标并在公司内部公开展示，效果立竿见影。他提到一个关键细节：当他们首次公布 DORA 数据时，管理层纷纷抬头点头认可，随即追问实际数据是多少。团队当时还没有精确数据，于是先跑了一个试点项目，测出部署速度提升 77%，赢得各方支持。但后来发现测量有误，未能捕捉到整个部署链中隐藏的异步处理过程。他们公开承认了失误，并从中悟出一个道理：数据能打开门，但不是全部的真相。真正的转变发生在他们转向叙事化方式之后。
这个转向的核心，是把冰冷的技术参数替换成让人感同身受的场景。Hornung 没有用“GitOps 在技术上更优”来论证方案价值，而是抛出一个问题：当 Hans-Peter 在周五下午进行手动部署，电话值班的 Olaf 凌晨两点被叫醒，到底发生了什么？然后自己给出答案：“GitOps 意味着我能一觉睡到天亮。”这句话比任何架构图都管用。
Matthaei 补充说，起初他们试图用试点结果和技术论据说服开发人员，收效甚微。真正的突破出现在他们开始用角色化故事来呈现那些隐藏的运维痛点：“初级开发者 Hans-Peter”、“电话值班员 Olaf”、“功能优先的 Fiona”——这些虚构但真实的角色让问题变得可见又具体。一旦开发人员在故事里看到了自己的影子，参与度和采用率就出现了显著提升。
Hornung 和 Matthaei 从实践中总结出五条经验：提高可见度、与人沟通、让价值可量化、构建叙事，以及让人们感受到隐藏的痛点。听起来不复杂，但他们强调这些领悟来自艰辛的试错，做起来并不容易。两人这样概括这场实践：如果你想将技术愿景转化为业务方理解且开发者想要的东西，别再向人们展示乐谱了，直接演奏音乐。
InfoQ 在演讲后采访了他们，请他们进一步拆解方法论。关于 DORA 指标的应用挑战，Hornung 坦言，数据帮助他们迈出了第一步，但数据本身不是真理。Matthaei 则认为 DORA 让技术团队有机会进入决策层，把纯粹的技术讨论切换成业务语言。两人都承认，工程师几乎从未接受过“如何让别人愿意用自己做的产品”这类训练，而平台推广在本质上是一个说服问题，不是技术问题。
Hornung 说得更直接：技术采用完全可以由工程师自己推动。他们没有产品经理，也没有高层授权，全靠从零构建方法论——借鉴了 Sinek、Carnegie、Knaflic 和 Collins 的理论，在实践中反复打磨。Matthaei 补充说，对他个人而言，真正的转折是走出工程师舒适区，学习那些从未接受过培训的沟通方式。“虽然不自然，但确实奏效了。”