Why Do Some Ops Teams Face Value Challenges? Insights for CTOs

Who Should Answer This Question

Ordinary operations engineers do not need to answer it; the CTO, as the leader of the operations department, must have a clear reason for building an ops team. If the CTO cannot answer, they are not competent.

Regular ops staff can still try to think about the issue from a higher perspective to prepare for future advancement.

Operations directors should also clarify this question because many decisions are co‑created with the CTO, influencing hiring and direction.

Who Asks This Question

The most typical askers are business developers. They see operations as an extra communication cost and may not fully recognize the results, so they raise the question.

Key points:

Developers may have a skewed or incomplete view of operations work; if they do not see the full picture, their premise is wrong.

If developers see the full picture yet still think ops adds no value, they may try to replace ops, essentially doing ops work themselves.

Even so, the question remains valuable because it forces us to rethink the role’s value and direction.

If you spend every day doing work that is not recognized, it is painful; therefore we must clarify which values are more likely to be recognized.

When the Question Is Challenged

The "value of operations" is a broad question, but only a

big problem + partial facts

attracts attention. We examine two typical positions:

Business operations staff in an internet company that builds its own products.

Operations staff for a brokerage’s trading system that is outsourced.

Position 1 is more likely to be challenged; position 2 rarely is, because there is no dedicated development team to question it.

Typical characteristics of a challenged scenario:

The core IT system is self‑built, with both development and operations teams (common in internet companies).

Developers need operations’ approval for certain ideas, leading to frustration.

Developers believe they can automate or improve the work, reducing the perceived need for operations staff.

The core issue is feeling constrained and believing they can do the job better themselves.

Developers Feel Constrained

From a CTO’s perspective, this is a key value of operations: without rules, developers would choose arbitrary tools and processes, resulting in inconsistent outcomes. High‑level dev teams can manage well; low‑level teams create chaos, so the CTO establishes operations to raise the baseline.

One of operations’ core values is to enforce company‑wide requirements and standards—stability, change management, technology selection—acting as the CTO’s (or technical committee’s) hand.

If developers challenge operations because they feel constrained, the challenge can be ignored.

Many companies scatter operations staff across development teams, which hampers global coordination and assessment, because operations and development require different skill sets.

Developers Believe They Can Do It Better

This is not that operations lack value, but that developers think operations are not performing well enough.

Generally, developers have:

Stronger coding ability, deeper business understanding, and clearer system architecture.

Weaker system‑management skills, less reverence for production environments, and fewer real‑world scenarios.

Thus they may think they can improve in areas such as:

Tooling and platformizing change management.

Faster incident response and On‑Call handling.

Better capacity planning and handling traffic spikes.

Other operational details.

The article does not dive into each detail, but some principles can help define the dev‑ops boundary.

How to Define the Operations‑Development Boundary

Some tasks are better suited for development; operations should focus on higher‑value work, which can be summarized as:

Build Company‑Wide Unified Operations Platforms

Development’s main job is building business features, not operations platforms. Suitable platforms include:

Unified asset‑management platform

Unified change‑release platform

Unified container‑management platform

Unified feature‑flag platform

Unified traffic‑shaping platform

Unified machine‑permission control platform

Unified monitoring/observability system

Unified incident‑drill system

Unified run‑book management

Unified SLO management

Unified knowledge‑base for post‑mortems

…and many more

Establish Company‑Wide Unified Operations Processes and Production Standards

For example, a previous employer defined five “rules of engagement” for production changes:

Advance notice is required.

Change steps must be complete.

Tiered release must be followed.

Peak windows should be avoided.

Service checks must be executed.

Even if the specifics vary per company, consciously creating and enforcing such rules improves production stability.

Other areas—instrumentation, deployment, backup, rate‑limiting, rollback, alerting, troubleshooting, post‑mortem—can also have best‑practice guidelines or hard rules.

Technical “Poverty Alleviation”

If a business team is strong and can handle On‑Call themselves, let them do it; only involve SRE when they request help or need additional headcount. This mirrors Google’s SRE staffing model.

In technology selection and architecture design, many business teams want early SRE involvement to spot design flaws and share the SRE investment.

Some teams try to “build their own wheels,” but this is discouraged because SRE follows company‑wide standards; unsanctioned choices can lead to gaps.

Large companies sometimes allow teams to use their own solutions (e.g., Netflix’s Chaos Monkey) but still require passing company‑wide validation.

This approach can be described as “technical poverty alleviation”: operations staff dive into business to help with tasks that the business cannot or does not want to handle alone.

When deep involvement isn’t needed, operations can act as a “BP” (business partner), providing coaching, training, or consulting, allowing a single ops person to serve multiple teams.

Conclusion

Starting from the question “What is the value of operations?” we identified where ops should focus and how to protect its role. Hopefully this provides useful guidance.