The Constraint That Is Not On The Org Chart
Most corporate marketing teams cannot change their own website without asking someone else. That single fact shapes more outcomes than channel selection, agency choice or budget.
The title on the other side varies: webmaster at older organisations, front-end developer, web team, platform owner, or an agency on a maintenance contract. What they share is that your website is one item on a list that also holds the customer portal, an ERP integration and a security patch somebody in compliance is chasing. Marketing requests enter that queue with no inherent priority.
Two failure modes follow. In the first, marketing treats the developer as a service desk and is surprised by the queue. In the second, marketing gives up and routes everything through a tag manager or a third-party overlay, producing a site nobody fully controls. Neither is fixed by escalating harder. Both are fixed by asking for the right thing, in a form that can be acted on, at a size the asker understands.
Four Sizes Of Request Wearing The Same Clothes
Changing the heading on one page and changing the heading pattern on every product page are the same sentence in a brief and completely different work.
| Request type | What it touches | Who has to be involved |
|---|---|---|
| Content change | Copy, images, meta title on specific pages | Usually marketing alone, in the CMS |
| Template change | Every page using that layout | Developer, code review, regression testing |
| Platform change | CMS configuration, a module, a form engine, an integration | Developer plus security and licensing review |
| Infrastructure change | DNS, server or CDN rules, redirects, certificates | Systems administration, under change control |
These are not a hierarchy of importance but of blast radius. A content change breaks one page; an infrastructure change can take the domain and its email offline. Asking for an infrastructure change in the casual register of a content change tells the developer you do not understand the risk, and the request loses credibility before it is read. Say which size you think it is. Being wrong is fine; showing you thought about it is the point.
The Five Lines That Make A Request Actionable
A ticket a developer can act on without a meeting contains five things:
- The exact URL or URLs, not a page name or a section of the site.
- The current behaviour, evidenced: the screenshot, the crawl row, the Search Console report, the browser and viewport width.
- The desired behaviour, stated as a rule rather than one example, so the developer knows what to generalise.
- The reason, in business terms, so it can be ranked against a security patch by someone who is not you.
- The acceptance test: how both parties will agree it is done.
The blog looks broken on mobile is not actionable. This is: on /resources/, the second image in each card overlaps the card heading in iOS Safari at 390 pixels wide; expected behaviour is that the heading clears the image at every width below 420 pixels; acceptance test is no overlap in iOS Safari and Chrome on Android at 360, 390 and 414 pixels.
Add a deadline only when a real event depends on it, and name the event.
Release Cycles And The Cost Of Just Pushing It Live
Most corporate sites ship on a cadence: a fortnightly sprint, a monthly release window, or something slower where changes need documented approval. Work outside the cadence is a hotfix, which means somebody owns the risk personally.
That is what can you just push this live is actually asking. It asks a developer to skip review and absorb the risk. Reserve it for cases where the cost of waiting is real: a form that is not delivering, a factually wrong price or claim, a legal correction, an outage, a live campaign landing on an error page.
Staging is only useful if it is a genuine copy — same templates, comparable content, integrations pointed at test endpoints. Confirm two things about yours. That it is closed to search engines by HTTP authentication or IP restriction rather than a robots directive alone, because directives get missed and staging sites do get indexed. And that marketing may review on it, since approving from a screenshot is how the wrong thing goes live with your approval on it.
Access Marketing Should Hold, And Access It Should Not
Marketing should hold directly: CMS authoring rights for content pages; analytics and Search Console at a level that allows submitting sitemaps and inspecting URLs rather than requesting a screenshot; ad accounts; the marketing automation platform; and the tag manager, at a permission level where publishing is reviewed.
Marketing should not hold: the domain registrar and DNS zone; server or CDN configuration; the production database; and template code without review. The reason concentrates in DNS. A team that can add a verification record can also edit an MX or SPF record and take company email down.
The distinction that matters is between holding credentials and having a route. Marketing does not need DNS access; it needs a named person who will add a record within a working day. Separately, insist on ownership where you do not have control: the domain, analytics property, ad accounts and tag container should be registered to the company with a marketing leader named — not to an agency, or a developer who left in 2019.
Tag Managers Solve The Problem, Then Become One
A tag manager such as Google Tag Manager exists because of the queue described above. It lets marketing deploy tracking and third-party scripts without a code release. The conventional framing is that this frees marketing from IT; the honest version is that it moves the risk rather than removing it.
First, performance. Every script in the container executes in the visitor's browser. A chat widget, a session recorder, a personalisation tool and four advertising pixels compete for one main thread, which is where Interaction to Next Paint — INP, the Core Web Vital measuring responsiveness to user input, documented by Google as 200 milliseconds or less at the 75th percentile — degrades.
The second is measurement: duplicate analytics tags double-counting conversions, and triggers keyed to URL patterns that changed six months ago.
What works: one named container owner; version notes on every publish; a quarterly audit removing tags for tools nobody pays for; and a rule that anything writing to the page or loading before first paint goes through a developer.
Technical SEO Requests Fail On Specification
A vague technical SEO ticket does not produce nothing. It produces a wrong fix, which costs more than doing nothing because the site has changed and nobody knows exactly how. The pattern to correct:
- Fix the redirects becomes a mapping table of old URL to new URL, one hop, a 301 permanent status rather than a 302, no chains.
- Add canonical tags becomes which URLs self-canonicalise, which point elsewhere, and what happens on paginated and parameterised pages.
- Improve site speed becomes which template and which metric — LCP, INP or CLS — measured in field data at the 75th percentile, not a Lighthouse score, since Lighthouse cannot measure INP at all.
- Add schema becomes which type, on which template, with which properties. It also means not requesting FAQPage markup for a rich result: FAQ rich results stopped appearing in Google Search on 7 May 2026.
One habit improves the hit rate more than any other. State what must not change: do not alter any URLs is a sentence that has saved entire migrations.
Credit With A Development Team Is A Balance You Spend
Every request flagged urgent draws down an account. Teams that flag everything urgent get treated as noise, and then the one genuine emergency waits behind somebody else's font change. Not crying wolf is a strategy, not a courtesy.
The behaviours that build the balance are unglamorous. Batch non-urgent work into the release cycle instead of drip-feeding it. Close tickets, and say when a fix worked and what it did, because developers rarely hear the outcome of anything they ship.
The highest-return move available to a marketing director here is structural rather than interpersonal: negotiate a standing allocation of development capacity, a fixed share of every release reserved for marketing work and spent at marketing's discretion. That converts a permanent political negotiation into a capacity plan, and it lets you say no internally with a reason. If the allocation is refused, that refusal is the thing to escalate — expressed as campaigns and fixes delayed, not as frustration. Escalating a queue is a business argument. Escalating a person is not, and it costs you the relationship you need.
Frequently Asked Questions
How do we get web development requests prioritised?
Give the request a business reason and a size, then compete on the reason rather than on urgency. A ticket saying this template change affects 340 product pages and unblocks a campaign launching on the 14th can be ranked against a security patch by someone who does not report to you. A ticket saying this is urgent cannot.
Longer term, stop negotiating item by item. Ask for a standing allocation of development time in each release that marketing controls — a scheduling conversation that usually succeeds where escalation does not.
Should marketing have access to Google Tag Manager?
Yes, with governance. Tag manager access is the difference between measuring a campaign this week and measuring it next quarter, so withholding it costs more than it saves. But set it up so publishing is a reviewed action rather than a free one.
The working arrangement: marketing holds edit and approval rights, one person owns the container, every publish carries a version note, and anything writing to the page or loading before first paint goes to a developer instead. Audit quarterly and delete tags for tools you no longer pay for.
What is a staging site and why can we not just edit the live site?
Staging is a separate copy of the website where changes are built and reviewed before they reach visitors. Editing live means the first person to see a mistake is a customer, and on a template change the mistake affects every page at once rather than one.
Content changes in the CMS are usually safe on production, which is why marketing holds those rights. Anything touching templates, integrations or server configuration should be seen on staging first — and confirm your staging site is closed to search engines by authentication.
Who should own our domain name and DNS records?
The company should own the registration, with the registrar account in a company name and company email address, and at least two internal people able to reach it. Not an agency, not a developer's personal account, not a contractor from a previous decade.
Day-to-day DNS changes should sit with whoever administers infrastructure, because a mistaken MX or SPF edit takes down company email rather than a web page. Marketing needs a named contact who will add a record within a working day, and needs listing as an owner.