ServiceNow DevOps: Roles, Responsibilities and RACI

Platform Engineer and Pipeline Ownership

A Platform Engineer owns the DevOps system and pipeline: the continuous integration framework, deployment automation, monitoring, and feedback loops. They are responsible (R) for the platform itself and accountable (A) for performance and reliability. When a deployment fails, the platform engineer is accountable for understanding why and fixing the root cause.

The platform engineer works with development teams to understand their deployment needs. They configure the pipeline to support the team’s development workflow. They set standards: all code must pass linting, all code must have test coverage above a threshold, all deployments must include a health check. These standards are non-negotiable; they protect production stability.

Code Owner and Change Approval

A Code Owner is responsible for a specific codebase or service. When code is ready to deploy, the code owner reviews the change: does it follow standards, does it have tests, does it include documentation? The code owner approves the deployment or requests changes. Code owners are consulted (C) on platform changes that affect their code (new build tool, new testing requirement).

Code owners are also accountable for incidents related to their code. If a deployment introduces a bug, the code owner is accountable for investigating and fixing it. This accountability creates ownership of quality.

Operations and Incident Response

Operations team manages production systems. They monitor deployments, watch for errors, and respond to incidents. When a deployment fails or causes problems, operations notifies the platform engineer and code owner. Operations is consulted (C) on deployment timing and communication. Operations is responsible (R) for rollback decisions if a deployment is seriously broken.

Operations provides feedback to platform engineers about deployment reliability: how many deployments fail, what is the average time to recover from failure, how many manual interventions are needed. This feedback drives platform improvements.

Security and Compliance Review

Security reviews code and deployment practices to identify risks: hardcoded secrets, unencrypted data in transit, missing input validation, use of deprecated libraries. Security is consulted (C) on all deployments and is responsible (R) for approving security-sensitive changes (authentication changes, access control changes, encryption changes).

Security also sets standards: all code must be scanned for vulnerabilities, all containers must be scanned before deployment, all infrastructure must be encrypted. Security gates in the pipeline enforce these standards: a deployment cannot proceed if a security scan fails.

Development Team and Continuous Deployment

Development teams commit code to a repository. The pipeline automatically builds the code, runs tests, and (if tests pass) may deploy to a staging or production environment. Development teams are responsible (R) for code quality and for fixing issues found in pipeline. Developers are informed (I) of deployment timing and incidents.

Developers do not have direct production access; they cannot deploy without going through the pipeline. This separation ensures that all deployments are consistent and follow the established process. In an incident, a developer can request an expedited deployment, but approval authority remains with the code owner or platform engineer.

Release Management and Deployment Scheduling

Release Management coordinates multi-service deployments. When multiple teams have changes ready, release management decides whether to deploy them together or separately. Release management is responsible (R) for communication: notifying affected teams and users about deployment timing, handling deployment conflicts (Team A’s change depends on Team B’s change), and scheduling blackout windows (no deployments during critical business periods).

DevOps RACI Matrix

For “Approve a production deployment,” the code owner is responsible and accountable, security is consulted (if applicable), operations is informed. For “Rollback a failed deployment,” operations is responsible and accountable, the code owner and platform engineer are informed. For “Change the deployment pipeline,” the platform engineer is responsible and accountable, all teams are consulted. A clear RACI matrix prevents confusion and ensures timely decisions.

Escalation and Governance

Define escalation paths. If a code owner and a platform engineer disagree about deployment timing, who decides? If security and development disagree about risk, who decides? Usually an engineering leadership team (VP Engineering, Chief Architect) makes these decisions. A governance meeting (weekly or bi-weekly) reviews deployments, discusses incidents, and resolves escalated issues.

Why a RACI for pipelines differs from a RACI for projects

A standard project RACI assigns roles to deliverables that finish. Pipeline work does not finish. A deployment path is exercised every few days, failures arrive at night, and the same decision (for example, whether to promote a build that passed tests but has one known defect) recurs in a different form each time. The matrix therefore has to describe recurring events, not one-off tasks. Build it around the decisions the pipeline forces a person to make, and the roles fall out of those decisions.

Building the matrix around recurring pipeline decisions

Start with five or six decisions that actually occur. The table below uses decisions that most delivery teams meet within a single release cycle. The letters follow the usual convention: R for the person who does the work, A for the one person who answers for the outcome, C for those whose input is needed before the decision, and I for anyone who needs to hear the outcome afterwards.

Read the matrix for its gaps before its contents. A decision with two A entries has no owner in practice. A decision with no R entry will be done by whoever notices it first. A decision where the code owner is C but never I is a sign that the code owner is consulted yet never told how the outcome landed, which can cause friction.

Writing the accountable role so it can be held to account

The accountable role should be a job title that exists on the organization chart and has authority to stop a deployment. A title such as “delivery leadership” fails this test because nobody knows who is on call for it. Where a decision is taken out of hours, name the role and the deputy, and make sure the deputy has the same permission in the pipeline tool rather than a shared login.

Procedure for validating the matrix before it is published

1. Walk each decision through a real recent event, such as the last rollback or the last emergency fix, and check that the matrix predicts who acted.
2. Mark every decision that has no R, has two As, or has no I, and resolve each one with the named people.
3. Check the escalation path separately, because the matrix describes normal work and escalation covers the cases where the normal path has failed.
4. Publish the matrix in the place engineers actually look during an incident, and retire any older copy that still circulates.

Escalation paths that do not depend on one person

Escalation is where pipeline RACI documents often break. A common design sends every blocked deployment to the release manager, who is then unavailable during a major incident because they are on the bridge call. A more durable design routes routine blockers to the code owner, routes production-impacting blockers to the service owner, and reserves the release manager for coordination. Test the design by asking who decides when the release manager is also the person affected. The same question comes up in an emergency change review, where the decision has to be recorded after the fact.

Where ownership goes wrong in practice

• Pipeline ownership sits with a platform team that has no authority over the release calendar, so it can build gates but cannot decide when they apply.
• Security is consulted on every change, which can turn a review into a queue and encourage teams to route around it.
• The code owner approves their own change because the approval role was copied from a template without checking segregation.
• Nobody is responsible for pipeline failures that occur between releases, so they accumulate until the next deployment exposes them.

Who should be the release manager in a team with no formal release role?

Choose the person who already runs the production calendar, even if the title is different. Creating a formal role on paper does not change who gets the call at night, and the matrix should describe the people who do the job now.

Should every engineer be able to promote to production?

Only if the control design accepts that risk. Many organizations allow promotion by a small group and require every other engineer to request it. The reasoning should be written in the matrix, not left as an unstated habit.

What should trigger a review of the matrix?

Review it after any incident that involved an escalation, and after any change in team structure. A routine review on a fixed calendar is useful too, but the trigger events matter more because they reveal the gaps that were not visible during normal operation.

Can a single person hold several roles in the matrix?

Yes, in a small team, but the matrix should avoid one person being both the A and the approver for the same decision, since that removes the separation the matrix was built to show.