Voluntary
各个功能可能存在，以提供常见或关键功能的常见基础。 这些功能是出于必要性而建立和维护的，而不是有计划、有意识地资助的。
这些功能由临时或自愿分配的人员构建和维护;没有中央资金或人员配备被故意分配给他们。 他们依赖于其用户的当前战术要求。 决策基于不完整或无关的数据，导致优先级被误导。
领导主要对危机做出反应，而不是主动推动变革，导致整个团队的分片协作和效率低下。 重点是提高对战略对齐和数据驱动决策需求的认识。
分配预算和人员以维护常见功能：单个开发人员或团队负责解决紧急技术要求和功能。 这并不总是成本 - 开发人员在当前职责的基础上承担这项工作。
管理范围：工程师专注于解决特定上下文或范围内的需求，需求很少与更广泛的上下文共享解决方案。
展示投资回报：根据个人或团队解决具体问题的方式和对核心项目工作的影响来衡量。
临时贡献
随着组织的增长，部署管道中不一致的基础结构预配、分散的安全做法和瓶颈等反复出现的技术挑战变得更加明显。 这些挑战通常会导致延迟、缩短停机时间和效率低下，从而阻碍软件交付的整体速度和可靠性。 作为回应，组织开始组建专门负责系统地解决这些问题的团队。 然而，这些努力仍然基本上是反应性的，侧重于修补即时问题，而不是主动防止这些问题。
这些团队的工作范围通常仅限于特定问题，例如改进特定部署过程或标准化一部分安全协议，而无需全面改进平台。
领导层开始通过促进基本协作和引入指标来解决效率低下的问题，但努力仍然反应和孤立，整个组织的能力有限。
分配预算和人员以维护常见功能：团队旨在解决关键交叉问题，通常是被动的。
管理范围：范围仅限于特定关注。
展示投资回报：衡量关键交叉削减关注点的改进 - 积压工作的规模。
使用专用团队操作
预算和人员用于持久人员和资源支持。 分配的人员的任务是提供一组常用功能来加快软件交付速度。 这些团队通常专注于满足反应性技术要求。 它们可能称为 DevOps、工程启用、开发人员体验（DevEx 或 DevX）、共享工具、卓越中心甚至平台。 他们集中资助，并被视为成本中心。
平台团队现在被公认为对组织的成功至关重要，并努力衡量和证明其贡献的合理性。 然而，焦点可能仍然是立即回报，而不是长期增长。
领导层积极促进跨职能团队合作和初始 DevOps 实践，但难以衡量平台团队的价值，使解决方案与用户需求保持一致，从而在合理投资和维护效率方面面临挑战。
分配预算和人员以维护常见功能：中央团队根据现有技术要求的知识资助，以加快软件交付速度。
管理范围：范围很宽浅。 该团队创建解决方案，试图解决所有团队中最大的共同分母问题。 中心团队侧重于了解所有团队的常见需求，并且不寻求配置或调整这些需求的解决方案的方法。
展示投资回报：衡量交付速度的提高。
可缩放为产品
对内部平台及其功能的投资类似于对企业出站产品和价值流的投资：根据预期向客户提供的价值。 明确考虑并投资产品管理和用户体验。 退款系统可用于反映平台对其客户自己的直接价值流和产品的影响。 企业使用数据驱动的绩效指标和反馈循环，向适当的计划分配资金和员工。 平台团队最终可以优化业务本身，并有助于提高盈利能力。
在此级别，我们观察了组织内部的重大文化转变，开发人员被认可并被视为有价值的客户。 领导强调同理心和成长的文化，推动产品主导的方法，鼓励持续改进，但必须确保这些价值观深深嵌入到组织中，以实现持久的影响。
分配预算和人员以维护常见功能：中心平台团队与其他产品团队一样配备和管理。 角色包括开发、产品管理、设计、研究和内容。 团队基于路线图提供资金。
管理范围：团队生成产品路线图来描述其计划和对组织的预期影响。 平台团队与工程团队合作，收集要求、识别新机会等。工程师专注于满足组织内所有开发团队的需求。
展示投资回报：衡量和报告开发人员满意度的改进。
使用已启用的生态系统进行优化
平台团队在基本功能之外找到了提高组织范围的效率和有效性的方法。 核心平台维护人员有意努力优化新产品的上市时间，降低成本，为新服务实现高效的治理和合规性，快速轻松地缩放工作负载和其他交叉要求。 这些核心维护人员专注于使功能专家能够无缝地将其要求和产品/服务集成到现有和新的平台部分。 此外，组织将来自专家领域的人员和资源（例如安全性、性能、质量）集中在提供的平台框架上，以引入高级功能，使产品团队无需依赖于集中式团队积压，就能加速他们遵守公司目标。
领导在平衡治理的同时鼓励创新，促进团队自主权和问责，重点是在快速变化的环境中保持平台相关性和有效性。
分配预算和人员以维护常见功能：中心平台团队与其他产品团队一样拥有和管理人员，但提供了更多资金，以便在整个组织中提供捐款。 工程和非工程团队有明确的资金，能够为平台做出贡献。
管理范围：工程师专注于启用平台贡献，以允许整个组织快速共享知识。
展示投资回报：衡量开发人员满意度的改进。