Standard : Teams have autonomy to shape their development environments
Purpose and Strategic Importance
This standard ensures teams have autonomy to shape and optimise their development environments to suit their needs, improving productivity, satisfaction, and delivery flow. It supports faster onboarding, focused development, and a stronger sense of ownership.
Aligned to our "Developer Experience Matters" and "Empower Teams to Self-Serve" policies, this standard reduces engineering friction and enables secure, scalable customisation. Without it, engineers face rigid tooling, inconsistent environments, and low engagement.
Strategic Impact
- Faster onboarding and improved productivity
- Reduced friction and context switching in daily workflows
- Higher satisfaction and retention of engineering talent
- Stronger autonomy and alignment with platform teams
Risks of Not Having This Standard
- Slower delivery and increased time-to-value
- Reliance on brittle workarounds or default environments
- Reduced team satisfaction and higher onboarding friction
- Accumulated tech debt through unmanaged divergence
- Increased support overhead and tooling inconsistency
CMMI Maturity Model
Level 1 – Initial
| Category |
Description |
| People & Culture |
Engineers rely on default setups or unsupported workarounds. |
| Process & Governance |
No standard process exists for environment configuration. |
| Technology & Tools |
Tooling is rigid, with minimal support for developer preferences. |
| Measurement & Metrics |
No visibility into onboarding time or dev environment friction. |
Level 2 – Managed
| Category |
Description |
| People & Culture |
Some engineers adapt environments, but inconsistently or without support. |
| Process & Governance |
Teams share environment tips informally, but no central guidance exists. |
| Technology & Tools |
Limited customisation is possible through manual changes. |
| Measurement & Metrics |
Basic onboarding time is captured informally. |
Level 3 – Defined
| Category |
Description |
| People & Culture |
Teams are encouraged to shape environments and share improvements. |
| Process & Governance |
Standardised onboarding processes and setup guidelines exist. |
| Technology & Tools |
Tooling supports safe configuration and baseline customisation. |
| Measurement & Metrics |
Onboarding time and developer sentiment are reviewed regularly. |
Level 4 – Quantitatively Managed
| Category |
Description |
| People & Culture |
DevEx is prioritised in retrospectives and performance reviews. |
| Process & Governance |
Changes to environments are tracked and reviewed for alignment and impact. |
| Technology & Tools |
Environments are versioned, provisioned via code, and supported by platforms. |
| Measurement & Metrics |
Metrics on time-to-first-commit, onboarding, and tooling satisfaction guide decisions. |
Level 5 – Optimising
| Category |
Description |
| People & Culture |
Developers proactively improve and shape environments through feedback. |
| Process & Governance |
DevEx data and learning loops drive continuous environment refinement. |
| Technology & Tools |
Platform teams enable self-service, secure customisation at scale. |
| Measurement & Metrics |
DevEx metrics are benchmarked and drive strategic investment. |
Key Measures
- Time-to-first-commit and onboarding friction scores
- Developer satisfaction with tooling and environment flexibility
- Frequency of environment-related support requests
- % of teams with self-defined, version-controlled setups
- Alignment between platform capabilities and team autonomy