Teams Cannot Change Their Own Pipeline Without Another Team
3 minute read
What you are seeing
A developer needs to add a security scan to the pipeline. They open the pipeline configuration and find it lives in a repository they do not have write access to, managed by the platform team. They file a ticket describing the change. The platform team reviews it, asks clarifying questions, schedules it for next sprint. The change ships two weeks later.
The same pattern repeats for every pipeline modification. Examples include adding a new test stage, updating a deployment timeout, rotating a secret, or enabling a feature flag in the pipeline. Each change is a ticket, a queue, a wait. Teams learn to live with suboptimal pipeline configurations rather than pay the cost of requesting every improvement. The pipeline calcifies because changing it is expensive, so problems accumulate and teams work around them rather than fix them.
Common causes
Separate ops/release team
When a dedicated team owns the pipeline infrastructure, delivery teams have no path to change it themselves. The platform team controls who can modify pipeline definitions, which environments are available, and how deployments are structured. Organizations often create this separation for consistency or security reasons. As a result, the teams doing the work cannot improve the process supporting that work. Every pipeline improvement requires cross-team coordination, which means most improvements never happen.
Read more: Separate Ops/Release Team
Pipeline definitions not in version control
Some pipeline configurations are managed through a GUI, a proprietary tool, or some other mechanism outside version control. Delivery teams cannot own those configurations the way they own their application code. There is no pull request process for pipeline changes and no way to review or roll back. The delivery team has no natural path to make changes. The configuration lives in a system controlled by whoever administers the pipeline tool, which is typically not the delivery team.
Read more: Pipeline Definitions Not in Version Control
No infrastructure as code
When infrastructure is configured manually rather than defined as code, changes require access to systems and knowledge that delivery teams typically do not have. A delivery team cannot self-service a new environment or update a deployment target without someone who has access to the infrastructure tooling. Infrastructure as code puts the configuration in files the delivery team can read, propose changes to, and own. The delivery team no longer depends on the platform team for every modification.
Read more: No Infrastructure as Code
How to narrow it down
- Do delivery teams have write access to their own pipeline configuration? If the pipeline lives in a repository or system the team cannot modify, they cannot own their delivery process. Start with Separate Ops/Release Team.
- Is the pipeline defined in version-controlled files? If pipeline configuration lives in a GUI or proprietary system rather than code, there is no natural path for team ownership. Start with Pipeline Definitions Not in Version Control.
- Is infrastructure defined as code that the delivery team can read and propose changes to? If infrastructure is managed manually by another team, self-service is not possible. Start with No Infrastructure as Code.
Ready to fix this? The most common cause is Separate Ops/Release Team. Start with its How to Fix It section for week-by-week steps.
Related content
- Waiting on Platform Team - Broader pattern of infrastructure blocked by a separate team
- Change Management Overhead - Approval processes that slow pipeline changes further
- Separate Ops/Release Team - Structural separation that prevents pipeline ownership
- Pipeline Definitions Not in Version Control - Pipeline config outside team control
- No Infrastructure as Code - Manual infrastructure that requires another team’s involvement