A decision model for marketing and technical teams
Most companies treat production access as a permissions question. Who has an Editor account? Who has Administrator access? Who knows the hosting login?
Those details matter, but they come too late in the conversation.
The business question is simpler: who is allowed to release a particular change, and who owns the outcome if that change affects more than expected?
The same Publish or Update button can send a corrected sentence live, change a form used by every campaign, load a new tracking script, or alter a global template. WordPress makes these actions look similar. Operationally, they are not.
That distinction matters most in established businesses. Marketing cannot wait for a developer to approve every headline. Technical owners cannot reasonably accept unreviewed changes to integrations, consent logic, or shared components. Both teams need room to do their jobs.
The answer is not to pick one team and lock out the other. It is to separate publishing access from release authority.
Capability is not authority
A WordPress role defines what a user can do inside the software. It does not decide what that person should release in a given business context.
An experienced marketing manager may be the right owner for a campaign page built with approved components. The same person may be the wrong owner for installing a plugin that changes how the page sends data to the CRM.
An agency developer may understand the code but not know that a change is scheduled during the company’s largest campaign of the quarter.
Release authority has to follow the change, not the job title.
Two questions are enough to classify most changes:
First axis: consequence
The visible size of a change is a poor guide to its operational impact.
A short script pasted into a settings field can affect consent, analytics, page speed, or every visitor on the site. A long rewrite of an isolated article may affect only that article.
Useful consequence questions include:
This is not about imagining every possible disaster. It is about knowing whether the effect is local or systemic.
Second axis: reversibility
Teams often describe a change as reversible because a backup exists. That is only part of the answer.
Reliable reversal means the previous state is known, someone can restore it within a useful time, and doing so will not erase orders, enquiries, form entries, or edits created in the meantime.
Restoring an earlier page revision is usually straightforward. Rolling back a database after customers have placed orders is a different decision entirely.
Reversibility also depends on ownership. If nobody knows who can perform the restore, a theoretically recoverable change is not operationally reversible.
Four release classes
Combining consequence and reversibility gives teams four practical release classes. These classes sit above WordPress permissions. They explain when those permissions may be used.
Routine publishing
The impact is local and the previous state is easy to restore.
Examples include copy corrections, replacing an image within an approved layout, or updating a date on a single content page.
Marketing and editorial teams should normally publish these changes themselves. Requiring technical approval would add delay without adding meaningful control.
Routine does not mean careless. The publisher still checks the preview, links, and the live result. The important point is that the boundary has already been agreed, so a small content change remains a small operational event.
Controlled publishing
The change is led by marketing but has a wider footprint. It is still reasonably reversible, although an error could affect several pages, campaigns, or measurement points.
Examples include launching a landing page from approved components, editing reusable content, adding redirects, or changing an existing lead form.
These changes benefit from a defined second review. Marketing can own the release, while another person checks the elements that carry wider consequences.
The reviewer does not always need to be technical. A campaign owner may be the right person to verify an offer or audience. Technical review becomes necessary when the change touches data flow, consent, scripts, global components, or an external integration.
Technical release
The change modifies the system or cannot be safely reversed through the editor.
Plugin and theme updates, code deployments, template changes, caching rules, DNS changes, hosting work, and new integrations belong here.
Administrator access does not make these suitable for direct changes on the live site. A technical release needs a known starting point, an appropriate test route, a credible rollback, and someone who can judge interactions across the system.
Marketing may still need to confirm the customer-facing result. Technical release authority, however, belongs with the person who understands the dependencies and owns recovery if the release fails.
Joint release decision
Some changes carry both substantial business consequence and difficult recovery.
A checkout change, a new form integration, a consent platform migration, or a major release immediately before a high-value campaign can fall into this class.
Neither marketing nor the technical owner has enough context to decide alone.
Marketing understands timing, offer logic, campaign dependencies, and expected user behaviour. The technical owner understands system dependencies, failure modes, and recovery time. The release decision needs both perspectives.
Senior leadership does not need to approve every deployment. It does need to name the person who decides when a commercial deadline conflicts with operational risk.
So who gets to publish?
The practical answer is to give enough people access to keep the business moving, then place clear boundaries around the kinds of change each person may release.
Marketing should be able to publish content that has no material technical dependency. That autonomy is part of a healthy operating model.
System changes should be released or supervised by the person who can assess their effects and take responsibility for recovery. An Administrator badge is not evidence of either ability.
Changes with broad commercial and technical consequences need a named joint decision. This does not require a committee. It often requires a short conversation between two people who know they are accountable.
What uncertainty tells you
If a proposed change cannot be classified, the problem is rarely a missing WordPress role. More often, the company lacks a reliable picture of how the site works.
If nobody knows where form submissions go, nobody can confidently approve a form change. If a shared component has no known list of uses, its consequence is unclear. If recovery belongs to "the agency" but no individual owns it, reversibility is an assumption.
The model exposes those gaps before a live release does.
Good governance protects speed
Release governance can sound like another layer of process. Done well, it has the opposite effect.
Marketing moves faster on routine work because the boundary is already clear. Technical attention is reserved for changes that can actually affect the system. Joint decisions happen only where commercial timing and technical consequence genuinely meet.
The Publish button then becomes what it should be: the final action in a decision that already has an owner.
Checklist for the next live release
- Classify each change by consequence and reversibility.
- Distinguish routine publishing, controlled publishing, technical releases, and joint decisions.
- Name an accountable owner for technical and joint releases.
- Check the preview, rollback path, and business outcome before release.
Next step
If production access has grown over time but release responsibility is still vague, I can help you define a workable model. We can separate the changes your team should publish independently from those that need controlled review or technical ownership.