The real cost of a content ticket

A developer receives a Slack message: "Can you update the pricing tiers before Thursday?" They stop what they're doing, context switch, make the change, deploy it, and go back to work.

The change itself took 10 minutes. But what did it actually cost?

The context switch tax

Research on developer productivity consistently shows that recovering from an interruption takes 20–30 minutes. Not to re-read the Slack message — to get back to the level of concentration you were at before it arrived.

A 10-minute content change costs 30–40 minutes of productive engineering time. If your team gets two of those a day, that's more than an hour of focus lost — before the actual work is counted.

Multiply it across a team

A five-person engineering team getting two content requests per day each loses roughly 5–6 hours of productive time. Per week. That's nearly a full engineering day, gone, on content changes that have nothing to do with the product.

Over a year that's roughly 250 engineer-hours. At even a modest billing rate, that's significant money. But the real cost isn't measured in dollars — it's the features that didn't ship because someone had to update the blog.

The fix isn't a better ticket system

The instinct is to formalise the process. Make people submit tickets with proper descriptions. Add a content change queue. Batch the requests.

That doesn't fix the problem. It just makes the interruptions arrive in a more organised way. Engineering still has to process them.

The fix is removing engineering from the loop entirely. When marketing can publish directly — without a PR, without a deploy, without asking anyone — the ticket never exists. The cost disappears.

That's what Dyrected is for.