Case study · Google (via Accenture) · 2022–25
Rescuing a 50-article content refresh
Fifty hard-to-read help articles kept losing to launch work: a low-priority, high-volume job with no firm deadline that other teams had repeatedly deferred. I decided ours would be the team that finished it.
A note on confidentiality. This work was done at Google via Accenture and is covered by an NDA. Product names and source material are omitted, and any figures are relative. The reasoning below is mine to share; the tracker shown is rebuilt for this portfolio with invented data.
The problem
QA flagged 50 articles in a product's help-center canon as too hard for users to understand. They were supposed to read at a 7th grade level: plain, jargon-free, short sentences. That's the best user experience, and clean source text is also what makes accurate translation into other languages possible. These articles didn't meet that bar.
On paper it was a straightforward refresh. In practice it was the kind of project that never gets done, for three reasons. It was low priority but high volume, 50 articles with no firm deadline, which made it the first thing to lose every time an urgent, launch-related request came in. It was tedious; next to a shiny product launch, refreshing old help docs is unglamorous work the team didn't enjoy. And it lived on the same split-shift global team, half in India and half in the Philippines, so coordination had the same small-overlap problem everything else did.
Plenty of product pods had looked at work like this and kicked the can down the road. I recognized that the canon mattered to the overall product experience, and I decided ours wouldn't be one of those teams.
The constraint
The defining constraint was the absence of one: no hard deadline meant nothing forced the work forward, so it competed, and lost, against everything with a date attached. I couldn't invent authority I didn't have, and I couldn't stop the launch work from arriving.
What I could control was two things: whether the refresh moved a little every week regardless of what else was on fire, and whether the team stayed willing to do work they found boring. To give the thing a spine, I set us a target of three months. A deadline I manufactured, because the project wouldn't survive without one.
Plenty of pods kicked this kind of work down the road. I decided we'd be the team that finished it. The reputation was worth more than any single article.
The decision
The approach I chose was to make the team visibly reliable: to be the pod that finished the unglamorous work instead of deferring it, precisely because so many others deferred it. That reputation with the QA and content strategy teams was worth more than any single article.
To make it real, I built a tracker that organized the 50 articles into sets by length, by the specific issue flagged, and by the writer assigned, so at any moment I could see what was done, what was stuck, and who had room. I ran a weekly sync timed for both shifts to check status. The important part: I treated it as a handoff mechanism, not just a status meeting. When a writer had to drop a refresh article to take on an urgent launch task, that article got handed to someone with bandwidth instead of stalling.
The work advanced in small, deliberate increments while everything louder kept interrupting it. And because the work was tedious, I watched morale as closely as I watched the tracker. A boring project only gets finished if the people doing it don't quietly give up on it.
| Article | Flagged issue | Reading level | Owner | Status |
|---|---|---|---|---|
| Set up two-step verification | Jargon, long sentences | Gr 11 → Gr 7 | Writer A | Done |
| Recover a locked account | Passive voice, steps out of order | Gr 10 → Gr 7 | Writer B | Done |
| Change your billing plan | Unexplained acronyms | Gr 12 → Gr 8 | Writer A | In review |
| Export your data | Dense paragraphs, no steps | Gr 11 | Writer C → B | Handed off |
| Manage notification settings | Jargon, nested conditions | Gr 10 | Writer C | Not started |
What happened
All 50 articles shipped by the three-month deadline, at the target reading level, and the content strategy team called out our pod for clearing a high-volume backlog on time while still absorbing competing launch work. The real result was reputational: we became a team that could be trusted with the work nobody wants.
If I ran it again, I'd change the meeting. The weekly sync landed at 6 a.m. for the Philippines team, and because both teams rotated between day and night shifts week to week, no fixed time was ever fair. The 6 a.m. Manila slot was the least-bad compromise, not a good one. More than that, I'd question whether a standing live sync was even the right instrument. Most of what we did in it was status, which could have lived asynchronously in the tracker; live time should have been reserved for the handoffs and blockers that actually needed a conversation. I'd protect people's sleep and spend our small overlap window only on the things that genuinely required everyone in the same call.