「技术本身没有价值！」担任今年台湾开发者大会MWC 2023主题讲者的Zalando前工程经理Andrew Howden，当著满屋子技术人的面前，再三强调，「除非技术帮助人们完成任务，才能从任务做到多好，看出技术的价值。」
Andrew Howden在Zalando这家欧洲电商巨头SRE团队待了四年，一路见证了Zalando最近四年的技术转型历程。他也是Zalando设立嵌入SRE团队的主管，负责解决结帐流程中的特殊难题。
不单看技术，而是从人获得的结果，来看技术的价值，这是他认为，自己在Zalando四年学到的第一件事，也是最根本的一个教训。
所有的技术必须对准企业的商业需求，但是企业需求又会受到许多因素和限制的影响。所以，技术人员必须深入了解业务面的各种权衡，和采取不同改变背后的考量，有时得快速对症下药，有时则得安静低调的默默改变。
想要打造杰出的开发者旅程，不能少了与业务团队的合作，也必须考虑打造这些服务背后，那一些与业务无关的工程产出，才能确保技术团队能够符合业务需求，又可以让业务团队发挥技术团队的新能力。如果技术团队没有做好自己的工作，对业务团队来说，就是一种不可靠的供应商，业务团队会另外设法找到出路。
从Zalando的故事，可以看到他们如何因应不同的企业发展需求、限制，来做出不同的技术选择和配套的组织变革。
想要从Zalando技术变革的演化经验中取经，关键不是看Zalando选择了什么技术，而是要看Zalando在「什么时间」选择了什么技术。Zalando在不同发展阶段，各有不同业务面和工程面的考量。
成立初期，技术全力支援业务，甚至技术团队将业务可靠性视为必要需求，这个高度追求稳定的技术选择，反而让技术成了业务创新的绊脚石。
后来，Zalando转而拥抱激进敏捷作法，也改采用了激进的全新所有权模式（指定专责所有权人的角色），这个所有权模式赋予了工程师高度的自主性，技术团队可以有时不用对齐到业务需求，例如可以尝试一下一个看起来很酷，但可能不太业务正确的新技术。
Zalando做得最好的一点是，从技术和业务面提出了一个清楚的愿景：打造出可以长久经营的全球性时尚平台。所有员工都对齐这个愿景，来做到最好。
决策之前，必须先了解这项决策所身处的脉络，像Zalando所做的每一项独特的技术决策，对其他企业而言，可能是好的参考范例，但也可能是作为不良范例的负面参考教材。
Andrew Howden建议，好好思考Zalando技术决策背后的考量，例如想一想，同一时期，这项技术决定有没有替代选择？产业常见做法是什么？Zalando又是如何善用这个技术决定的能力，来发挥竞争优势？
要选择最适合自己的技术，而不是最理想的技术，不要拿到CNCF技术蓝图，就开始挑技术，而是要回头思考自家企业需要什么。
一个典型的例子是，不能因为Zalando现在大力拥抱Kubernetes，就理所当然的想说，我也直接可以采用Kubernetes。
Zalando早在选择Kubernetes之前，在AWS提供容器管理平台选择之前，自己也打造了一套Docker管理平台，后来发现这么做的成效不彰。若是在今天，Kubernetes发展成熟的情况下，Zalando遇到同样的抉择，不见得会想要自己从头开发一套。
将Zalando经验套用到自家企业时，不要问这是不是一个最理想的作法？而要问自己，这是不是「对企业来说是最理想」的选择？考虑技术采用时，得选择业务需要的技术，而不是看起来很酷的技术。
Zalando很幸运地拥有一群资深、在业界待了很久的技术老手，当决定拥抱激进敏捷模式和对应技术时，可以透过部落格、社群媒体、工作坊等各种管道的曝光，吸引到大量优秀的技术人才。这也是让Zalando可以在那个当下做出那样决定的背景因素之一。
Zalando平台演变的故事听起来很厉害，用了不少看起来很酷的技术，关键是得了解这个故事的背后，Zalando这些技术策略是为了回应这项业务面目标：商业需要快速创新。想要实现这一点，技术团队的规模必须倍增再倍增，这又需要将技术能力平台化，以及对应架构的配套。
你的企业若想要复制Zalando的经验，必须清楚知道自家企业处于Zalando的哪一个发展阶段。如果不匹配，就得回头聚焦自己的工程团队，将他们视为自家平台的顾客来思考。思考工程团队的能力，而非他们的期望，以及对他们未来发展的期望，最后再决定，如何为自家工程团队来打造平台，不要只为了有一套「现代软体开发」流程而打造平台。