Last month I watched a marketing manager at a Series B startup wait four days to fix a typo - not a risky typo or anything legal-sensitive, just the word "their" spelled "thier" on the pricing page.
She submitted a Jira ticket on Monday and it sat in the backlog until Wednesday afternoon, when a frontend engineer picked it up between sprint tasks and opened a PR. Another engineer reviewed it Thursday morning, and it finally deployed Thursday afternoon.
Four days. Six characters.
I asked the engineering manager about it and he just shrugged. "We have a process." When I asked how many hours per week his team spends on content changes, he didn't know - so we counted together.
The answer was 14 hours every week, across a five-person frontend team. That's the equivalent of one full engineer doing nothing but text edits and image swaps.
The Hidden Math
I tracked the actual time spent on content changes at three different companies. The breakdown is remarkably consistent:
- Ticket creation: 8 minutes average. Half of it is finding the right Jira project and filling out required fields.
- Backlog time: 2.3 days median. Urgent requests jump the queue. Everything else waits.
- Context switching: 23 minutes. The engineer needs to find the file, understand what's being asked, verify they're changing the right thing.
- The actual change: 47 seconds average. I timed it.
- Code review: 18 minutes of someone else's time, including back-and-forth if the reviewer has questions.
- Pipeline and deploy: 12-40 minutes depending on the CI setup.
You're burning an hour of skilled labor on a 47-second task. And that's the best case, when someone actually picks up the ticket promptly.
At one company I worked with, their React devs billed at $180/hour loaded cost. Every typo fix cost them roughly $300 in engineering time. They processed 40-50 content requests per month.
Why This Happens
This workflow made sense in 2008. CMSs like Drupal and early WordPress were genuinely fragile. I once watched a marketing intern take down an e-commerce site by pasting formatted text from Word into a WYSIWYG editor. The curly quotes broke the JavaScript. Revenue stopped for two hours.
So we wrapped content changes in process. Developers became gatekeepers. Every change went through code review because any change could theoretically cause problems.
But now we have git that can revert any change in 30 seconds, preview deployments that show exactly what will deploy, TypeScript catching type errors at build time, and CI pipelines that won't let broken code through. The safety net already exists - we just keep acting like it doesn't.
- Git provides instant rollbacks with full audit trails
- Vercel and Netlify spin up preview URLs automatically for every branch
- Type-safe content schemas physically can't produce broken HTML
- Lighthouse, Percy, and automated tests catch visual regressions before deploy
Meanwhile, someone added a "content approval" step in 2019 because of one bad incident, and someone else added a "stakeholder sign-off" field in 2021. Now you need three approvals to change a team member's headshot, even though any mistake could be reverted in seconds.
What Good Actually Looks Like
I watched a content manager at a company with a proper workflow fix three typos in under two minutes - no tickets, no PRs, no waiting for anyone's approval.
- She opened the page in her browser
- Clicked on the text (the page has inline editing)
- Fixed the typo
- Hit Cmd+S
Done. Live in production.
Behind the scenes: her edit created a git commit with her name on it. It ran through their CI pipeline (12 seconds for content-only changes). It deployed to their CDN. There's a complete audit log. Her manager can see every change she's made this month. Any change can be reverted with one click.
She made a mistake once, about six months in. Changed a headline on the wrong page. Her manager caught it in the daily content digest email, mentioned it to her, she fixed it. Total time lost: maybe 10 minutes.
Compare that to the cost of routing every single change through engineering.
Pre-approval vs. Post-approval
Most companies run pre-approval workflows where nothing changes until someone explicitly allows it, which makes sense for some things but is overkill for the vast majority of content changes.
Post-approval flips the model: make the change, let it go live, and have someone review it afterward. If there's a problem, revert it - the audit trail shows exactly who did what and when, so there's complete accountability without the bottleneck.
Pre-approval for everything assumes your employees will break things if left unsupervised, treating every content editor like a liability waiting to cause damage. But that's a hiring problem, not a workflow problem. If you don't trust someone to change a paragraph on your about page, why do they work there?
Post-approval treats people like the adults they are. They have context you don't have, they're closer to the content than you are, and they're perfectly capable of making good decisions if you let them do their jobs.
Where pre-approval makes sense
Not everything should be post-approval. Some changes genuinely need a second set of eyes before going live:
- Pricing. A misplaced decimal point in your pricing table has real financial consequences. Worth a review.
- Legal copy. Terms of service, privacy policies, compliance statements. Your lawyers will insist, and they're right.
- Brand-sensitive messaging. The homepage headline, the company description, positioning statements. These should be intentional.
- New pages or major restructuring. Adding pages affects navigation, SEO, user flows. Worth thinking through.
The trick is applying the right level of review to the right type of change. A blog post image swap doesn't need the same scrutiny as a pricing page update.
One company I worked with set up three tiers: instant publish for low-risk content (blog posts, team bios, image updates), single-approval for medium-risk (product descriptions, feature pages), and full review for high-risk (pricing, legal, homepage). Their content velocity tripled. Error rate stayed flat.
How to Fix Your Workflow
Before changing anything, you need data - spend two weeks tracking every content request that comes in.
- Log everything. A spreadsheet works fine: date, requester, what they wanted changed, time to completion, and who touched it along the way.
- Categorize by actual risk. Be honest with yourself here. Is changing a team member's job title really a high-risk change? Is swapping a blog post image something that needs engineering review?
- Map the bottlenecks. Where do requests sit the longest? Whose calendar is always the blocker? Which steps consistently take more time than the actual change?
Every company I've done this exercise with finds the same thing: 75-85% of their content requests are zero-risk changes that got routed through engineering out of habit, not necessity.
That's your opportunity. Give non-technical people a way to make those changes directly, and suddenly your engineers get their time back, your marketing team stops waiting, and your website actually stays up to date.
The Trust Question
"What if someone publishes something wrong?"
They will - it's not a matter of if. Someone will typo a headline, upload a low-res image, or accidentally publish a draft before it's ready. This will happen eventually, and pretending otherwise is just denial.
And when it happens, you'll click revert and it'll be fixed in 90 seconds. The whole incident, from discovery to resolution, takes less time than waiting for your coffee to brew.
Now compare that to the alternative: routing 50 content requests per month through your engineering team to prevent the one mistake that might happen. You're spending $15,000/month in engineering time to avoid a problem that would cost you 90 seconds to fix.
The math doesn't work and it never did - we just never bothered to run the numbers.