Marketing can add tags to your site through a tag manager without engineering review, and the number of scripts on each page keeps climbing. As the engineer accountable for page performance, what governance would you put in place, and what would you concede?
answer
- cumulative cost, diffuse accountability
- budget measures cost, not tag count
- every tag needs an owner and an expiry
- zero-sum: something comes out
- pre-approved fast path prevents bypass
basics
~20 sSet a per-page script budget expressed as a measured cost with a named owner and a real consequence when it is exceeded, require every tag to carry an owner, a stated purpose and a review date, and give marketing a fast approved path so governance does not become a queue.
solid answer
~50 sI would make the page's script load a budget rather than an open bag. That means a number tied to something users feel — main-thread startup cost and the field metrics it drives — not a count of tags, and it means the budget is zero-sum: adding a tag when the page is at its limit requires taking something out or making an explicit, owned exception. Every tag entering the page carries four things: an owner, a stated business purpose, a loading treatment that cannot hold up rendering, and a review date at which it is removed unless someone defends it. What I concede is speed of change, and I would concede as little as possible by pre-approving a pattern for common cases so marketing can move without a ticket, reserving review for anything that wants to run early or gate content. Then I would report field data by tag, so the conversation is about measured cost rather than an engineer's opinion.
go deeper
Know that third-party tags accumulate and that each one costs the user something, so somebody has to keep a list of what is on the page and why.
Be able to describe the mechanics you would ask for: non-blocking loading for every tag, a written inventory with owners, and a measurement that shows what each tag costs the page.
Show how you turn that into practice — a budget expressed in measured cost, evidence per vendor from field data, and audits that produce removals. Interviewers want to hear you make the case with numbers rather than by asserting that tags are slow.
Own the tradeoff and the politics: what autonomy you concede, how you keep the process from being bypassed, how an expensive but valuable tag gets approved with named accountability, and how the whole structure survives after your attention moves elsewhere.
## Why this is a governance problem, not a technical one Every individual tag is defensible. The marketing team can name a reason for each one, and none of them is obviously the problem. The cost is cumulative and the accountability is diffuse: nobody owns the sum. That is why the technical answers — load them later, isolate them — buy time but do not stop the trend. The number of scripts on the page is an organisational output, so the fix has to change how decisions are made. ## Make the budget a real number A budget that says "keep JavaScript reasonable" changes nothing. Three properties make it bite: - **It measures cost, not count.** Ten cheap tags may matter less than one expensive one, so the budget should be expressed in something like main-thread execution time during startup plus transferred script bytes, tied to a stated device and network assumption. Counting tags produces gaming, not improvement. - **It is anchored to a user-facing target.** Work backwards from the field experience you want — the responsiveness and paint numbers at the percentile you care about — to how much startup work the page can afford, then divide that between first-party code and vendors. Now a tag's cost has a denominator. - **It is zero-sum.** At the limit, something comes out or the new tag waits. Without this, a budget is a graph nobody acts on. The point is not to say no; it is to force the comparison between the new tag and the least valuable one already there. ## Attach conditions to entry Every tag on the page should carry, in a place people can read: 1. **An owner** — a person, not a department. Unowned tags are the ones nobody dares delete. 2. **A purpose and a consumer** — which report or decision uses this data, and who reads it. If nobody can answer, that is the removal you were looking for. 3. **A loading treatment** — non-blocking by default, later than that where possible, and never anything that gates rendering without an explicit exception. 4. **A review date** — an expiry, after which it is removed unless the owner renews it. Campaign tags in particular are added for a six-week campaign and live for six years. The expiry is the highest-leverage item on the list, because it inverts the default. Without it, removal requires someone to argue against a colleague's tool; with it, retention requires someone to make a case. ## Give marketing a path, not a gate Governance that makes every change wait on engineering fails twice: it slows the business, and it drives people to route around it. So pre-approve the common shape — a standard, non-blocking, post-load container for measurement tags — and let it be used without review. Reserve review for the genuinely risky requests: anything that wants to run before content is visible, anything that manipulates the page, anything from a vendor not already on the page. This is the concession, and making it deliberately is what keeps the rest enforceable. ## Make cost visible where the decision is made The argument is won or lost on evidence. Report the field impact per vendor host — response times, startup cost, and the page metrics alongside — on a dashboard the marketing owners see, on the cadence they already meet. Two things follow. Vendor slowdowns become visible as they happen rather than as anecdotes, and the conversation shifts from an engineer's assertion that tags are slow to a shared table with numbers per tag. Periodic audits then have material: rank tags by cost, list their owners and consumers, and run the removals as a routine rather than as a crisis. ## What you are trading Be honest about the tradeoffs, because an interviewer at this level is testing judgment rather than enthusiasm for rules: - **Autonomy for predictability.** Marketing loses some ability to ship instantly, and you should minimise that loss with the pre-approved path. - **Some measurement fidelity for user experience.** Tags loaded late can miss short visits. That is a real cost, and the right response is to quantify what fraction of sessions is affected, not to deny it exists. - **Process overhead for a durable trend.** Reviews and audits take time. Keep them cheap and periodic, since a heavy process is the fastest way to end up with no process. ## The escalation you should design in advance The interesting case is a genuinely revenue-carrying tag that blows the budget. The answer is not to block it, and not to quietly absorb it. Make the exception explicit, name the person who accepted the cost, attach the measured impact to that decision, and buy the budget back somewhere else. Governance that has no legitimate way to say yes to an expensive thing will be bypassed the first time the expensive thing matters — and the value of the whole structure is that it makes cost visible and owned, not that it always produces refusal.
- How would you arrive at the budget's number in the first place?Start from the field experience you are committing to at a chosen percentile, on a stated device and network assumption. Translate that into how much startup work the page can afford, subtract what first-party code needs, and what remains is the vendor allowance. It will be uncomfortably small, which is the useful part — it turns an abstract argument into an allocation people can see themselves spending.
- A tag is business-critical and clearly blows the budget. What do you do?Approve it as a named exception rather than pretending it fits. Record who accepted the cost and the measured impact, then buy the budget back by removing or delaying something cheaper, and set a review date. A framework with no route to yes gets bypassed the moment something valuable needs the answer, and then you have neither the tag under control nor the process.
- How do you stop this from decaying six months after you introduce it?Tie it to events that recur without you: expiry dates that force renewal, a standing item in a meeting the tag owners already attend, and a report they see whether or not anyone asks. Ownership matters more than tooling — if the dashboard has no audience and the expiries have no owner, the structure quietly stops functioning while the tag list keeps growing.
saying these in an interview costs you the question
- Says no to every tag instead of offering a path
- Sets a budget with no owner and no consequence
- Counts tags rather than measuring their cost
- Assumes deferred tags are free so any number is fine
- Never expires or re-reviews tags once added