The pipeline is green.
QA signed off.
The deployment window is open.
Someone asks:
“Are we good to release?”
And then something interesting happens.
Everyone looks at someone else.
The developer knows the code.
QA knows what was tested.
DevOps knows whether the deployment can run.
Security knows about the findings.
The product owner understands the business impact.
But who actually owns the final decision?
In many teams, the answer is surprisingly unclear.
And I think that ambiguity is becoming a bigger problem as software delivery gets more automated.
Release ownership is often implicit
Most teams have a release process.
Far fewer have a clearly defined release decision process.
There is usually some combination of:
- CI checks
- automated tests
- QA approval
- pull request reviews
- security scans
- deployment jobs
- Slack conversations
- change tickets
- someone saying “looks good to me”
Eventually, the release happens.
But if you ask:
Why was this release considered safe enough to ship?
the answer is often reconstructed afterwards.
Maybe the pipeline was green.
Maybe QA approved it.
Maybe an engineering lead gave a thumbs up.
Maybe nobody saw a reason to stop it.
That last one is more common than we probably like to admit.
“Nobody stopped it” is not a release decision
There is an important difference between:
Nothing blocked the release.
and:
We evaluated the available evidence and decided the release risk was acceptable.
The first is passive.
The second is a decision.
Many delivery systems are designed around the first model.
A release moves forward unless something fails.
Build PASS
Tests PASS
Security PASS
Approval PASS
↓
DEPLOY
That works well when the important risks can be represented as binary checks.
But releases are rarely that simple.
Imagine this:
Tests PASS
Security scan PASS
Build PASS
Database migration YES
Authentication change YES
Rollback confidence MEDIUM
Observability coverage PARTIAL
Deployment timing PEAK HOURS
Nothing necessarily failed.
But someone still needs to decide whether those signals add up to an acceptable release.
That is not execution.
That is judgment.
Different people own different pieces of the truth
One reason release ownership becomes fuzzy is that no single person has all the information.
A developer might know:
“The implementation is small and well understood.”
QA might know:
“The regression suite passed, but this integration wasn’t fully covered.”
Security might know:
“There is a finding, but it is low severity and unrelated to this change.”
Operations might know:
“Rollback is technically possible, but it hasn’t been tested recently.”
The product team might know:
“This release needs to go out today because it fixes an important customer issue.”
Each perspective is valid.
None of them alone represents the whole release.
That means the problem isn’t simply finding the right person to press the button.
The real problem is bringing the evidence together before that decision is made.
Approval and decision are not the same thing
We often treat approvals as if they solve this problem.
They help, but an approval is only useful if we understand what is being approved.
Consider a typical approval step:
Production deployment waiting for approval.
Approve / Reject
What exactly does “Approve” mean?
Did the approver review the test results?
Did they see the security findings?
Do they know that the release contains a database migration?
Did they check rollback readiness?
Do they know whether the change affects authentication or payments?
Or are they simply approving because the previous pipeline stages are green?
An approval button does not automatically create a meaningful decision process.
Sometimes it just moves responsibility from automation to a human without giving that human better information.
Humans should make decisions, not collect evidence manually
This becomes especially important when teams introduce human approval gates.
The common pattern is:
Automation runs
↓
Human approval
↓
Deployment
But the human often has to investigate everything manually.
Open the CI pipeline.
Check the test report.
Look at the pull request.
Check security.
Search Slack.
Ask whether staging was tested.
Find the deployment notes.
Then make a decision.
At that point the human is not really acting as a decision-maker.
They are acting as an evidence aggregator.
And that is exactly the part automation should help with.
A better model might look like this:
CI / QA / Security / Change / Operations
↓
Evidence layer
↓
Risk context
↓
Human decision
↓
Release
Automation gathers and structures the evidence.
Humans apply judgment where judgment is actually needed.
Not every release needs the same level of control
Another problem with traditional release gates is that they are often static.
Every release follows the same workflow.
But risk is not static.
Compare these two changes.
Release A
Copy change
No dependency updates
No database changes
Full regression passed
Easy rollback
Release B
Authentication refactor
Database migration
New external dependency
Partial regression
Rollback requires data restoration
Should they really require exactly the same release process?
Probably not.
The first may need very little additional review.
The second probably deserves significantly more evidence and possibly explicit approval.
This is why I think release processes should become more risk-aware rather than simply adding more mandatory gates.
The question shouldn’t be:
Did this release complete all 12 steps?
It should be:
Given the risk of this particular change, do we have enough evidence to release it?
A release decision should be explainable
There is another useful test.
After a release, could someone explain why it was approved?
Not:
“Because the pipeline was green.”
But something closer to:
Decision: GO
Why:
- regression suite passed
- no critical security findings
- affected service has healthy staging metrics
- rollback artifact is available
- database migration validated
- required approval received
Or perhaps:
Decision: CONDITIONAL GO
Why:
- automated checks passed
- minor observability gap remains
- release approved with enhanced monitoring
- rollback owner assigned
And sometimes:
Decision: NO GO
Why:
- critical workflow not covered
- rollback path unverified
- production dependency currently unstable
That creates something extremely valuable:
decision history.
Not just what happened.
But why.
Release history usually tells us what happened
Most engineering systems are already very good at recording events.
We can usually find:
- which commit was deployed
- which pipeline ran
- which tests passed
- who merged the pull request
- when the deployment started
- whether the deployment succeeded
That is useful.
But during an incident, audit, or retrospective, another question quickly appears:
Why did we believe this release was safe enough to ship?
That answer is often much harder to reconstruct.
The evidence may still exist, but it is scattered across multiple systems.
A CI run.
A test report.
A security scanner.
A ticket.
A Slack message.
Someone’s memory.
The release happened because all of those signals somehow formed a decision.
But the decision itself was never captured.
That feels like an important gap.
This matters even more with AI-assisted development
Software creation is accelerating.
AI can generate code.
AI can generate tests.
AI can review pull requests.
AI can fix pipeline failures.
AI agents are increasingly capable of performing parts of the delivery workflow themselves.
Eventually, much of the mechanical software delivery process may become highly automated.
That makes one question increasingly important:
What should remain a decision?
The answer probably isn’t:
Everything must be manually approved.
That would destroy much of the value of automation.
But the answer also shouldn’t be:
The pipeline passed, therefore release.
As automation increases, teams will need to become much more explicit about the boundary between:
execution
and
authority.
Machines are excellent at collecting signals, evaluating rules, and enforcing policy.
Humans are still valuable when context, uncertainty, trade-offs, and business risk matter.
The interesting challenge is designing the boundary between the two.
The decision should depend on risk
I don’t think every release needs a human standing in front of a giant approval button.
That would simply create another bottleneck.
Low-risk releases should be able to move quickly.
If the evidence is strong, the change is small, rollback is easy, and the affected systems are well understood, automation may be perfectly capable of approving the release automatically.
But as risk increases, the decision process can change.
For example:
LOW RISK
↓
Evidence sufficient
↓
Automatic GO
A more complex release might look like:
MEDIUM RISK
↓
Evidence sufficient
↓
Conditional approval
↓
Human review
↓
GO
And a high-risk release might produce:
HIGH RISK
↓
Missing critical evidence
↓
NO GO
The important part is that the decision is based on the release context.
Not simply on whether a static checklist turned green.
Maybe nobody should “own” the release alone
This leads to a slightly different way of thinking about release ownership.
Perhaps the release decision should not belong entirely to one person or one tool.
Instead:
Engineering provides change evidence
QA provides quality evidence
Security provides security evidence
Operations provides deployment evidence
Automation evaluates policy
Humans resolve uncertainty
And the final release decision becomes the result of that system.
Not one person’s intuition.
Not one green pipeline.
Not one approval button.
A decision backed by evidence.
We have become very good at automating deployment.
Running containers, updating infrastructure, promoting artifacts, and rolling out applications can now happen in seconds.
Modern delivery systems are extremely good at answering:
How do we deploy this?
The harder question comes immediately before that:
Should we deploy this?
And if the answer is yes:
Why are we confident enough to do it?
That is a very different problem.
It combines engineering signals, quality evidence, operational context, security information, policy, and sometimes human judgment.
I think that question is going to become one of the most important parts of modern software delivery.
Especially as everything around it becomes increasingly automated.
So maybe the real question isn’t:
Who owns the release button?
It is:
Who — or what — owns the release decision?
And more importantly:
Can that decision be explained afterwards?
How does your team handle this today?
Who actually owns the decision that a release is ready to go?
