Helio Group's Post-Merger Deployment Ownership

Diagnosis: two inherited models created overlapping authority and no accountability. Helio's deployment manager owned end-to-end execution; Cortez's release managers coordinated deployment while also owning release. After the merger, release managers retained informal control of scheduling while the deployment manager retained the title, and neither owned post-deployment verification in 14 of 22 failures. The new deployment coordinator adds a third claim without decision rights. Proposed RACI for production deployment:

• Deployment manager: accountable for the deployment plan, schedule, execution coordination, verification and closure. One person, one plan.
• Release manager: accountable for release content, readiness and the release decision (what becomes available to users, and when); consulted on scheduling.
• Change enablement: accountable for change authorisation and the change schedule; approves standard and emergency changes; does not execute deployments.
• Application teams: responsible for build artefacts, deployment scripts, technical verification and post-deployment checks in their domain.
• Service desk and operations: consulted on windows and known errors; responsible for accepting handover and providing first-line support. Consolidation: in a 300-application estate, keep the release role where business release decisions are complex, but do not let it double as deployment coordination. Either retire the new coordinator title or give it explicit delegated authority inside the deployment manager's team. Emergency deployment uses the same roles compressed, not bypassed.

Structure options:

• Centralised deployment team: one team executes all production deployments. Strong consistency and easier control, but it becomes a bottleneck for 300 applications, distances teams from their own changes, and concentrates scarce skills in four people nearing retirement.
• Federated: each application team deploys its own changes under a central standard. It scales and builds skills, but risks inconsistent practice and weak verification - exactly the current failure pattern.
• Hybrid (recommended): a small central deployment practice owns standards, pipeline, scheduling model and assurance; embedded deployment practitioners in application teams execute within it. The central team handles high-risk and cross-team deployments. There is one accountable deployment manager per deployment, not per organisation. Competencies: deployment planning and scheduling, environment and configuration management, automation and pipeline engineering, verification and rollback testing, risk assessment, stakeholder communication, and knowledge of the applications being deployed. Contractors need onboarding against the same standards and access controls. Development actions: pair retiring staff with successors on the next three deployments; document runbooks and decision rules; train release managers and coordinators on the RACI; certify practitioners on the pipeline; use post-deployment reviews as the learning mechanism. Retain contractor knowledge through written procedures and joint exercises rather than relying on individuals.

Reduce emergency changes by making the standard path viable. Emergency deployments usually signal that normal windows are too slow, too rigid or untrusted.

• Analyse the emergency changes: true emergencies, late defect fixes, or requests that simply missed the window? The pattern determines the fix.
• Pre-approve low-risk, repeatable deployments as standard changes with automated verification, so teams do not queue for CAB.
• Publish a change calendar and cut-off rules, and provide a fast but controlled path for genuine emergencies with post-hoc review.
• Improve release readiness: entry criteria, testing evidence and a no-surprise rule for application teams. Improve deployment success: use the 22 failures as a blameless dataset, classified by cause - verification gap, scheduling, script, environment, knowledge. Fix the top two causes visibly. Introduce a deployment checklist and a go/no-go decision with a named accountable person. Require verification evidence before closure, and have the service desk confirm handover. Roles: the deployment manager owns execution and verification; release managers ensure readiness and release decisions; change enablement owns authorisation and the calendar; application teams own technical checks; the service desk confirms support readiness. Continual improvement: monthly review of failure causes, emergency-change proportion and deployment lead time, tracking whether actions close. Success is fewer failed and emergency deployments, not more process.