Google Help Center · Lead Writer, team of four

To fix a sentence or fix a system?

I was staring at a page with words and blocks. One by one I reviewed whether each block fit the content requirement for that kind of article. Then there it was — another comment, asking how this system would apply to every new kind of article we needed. I didn’t have an answer. I just had more blocks.

Context

I was part of a contracted team of writers embedded at Google through Accenture — Google badges, Google IDs, Google culture. We wrote and maintained Help Center content for Google products, and I'd just crossed over from a newsroom into tech. Ten months in, I was promoted to content lead, editing and making final calls for a team of four writers.

Then Google shifted the Help Center to a snippet-based system — every sentence in an article got its own number in the CMS, reusable across pages. That meant we weren't just writing articles with content block types anymore; we were building them from smaller modular pieces, matching content needs to existing snippets or creating new ones. The writing got more precise, but the architecture got a lot more complex.

As a writer, I could spot a mismatch between a snippet and an article's needs and just fix it — reassign a number, create a new one, move on. As a lead, four writers were hitting those mismatches at the same time, and to give them the confidence to apply the change today and in the future, I had to build the logic they could apply moving forward.

The hardship

The comments started coming in steady: "I'm trying to follow the snippet guidelines, but adding the required one here breaks the whole article." Six cases a week from four writers, and the number kept climbing. Each one needed individual judgment — there was no blanket rule — so every case landed on my desk before it could move forward.

When I couldn't solve it case by case anymore, I realized the problem wasn't my team — it was the snippet system itself, being rolled out company-wide. No one above me had a fix either. So I stopped waiting for the process.

The moment

One of my writers was working on a Google News Publisher Center article that needed to walk users through managing an organization in their account. The block called for a step-by-step, but the snippets available didn't match the actual steps. She came to me and said she'd rather write something that made sense to the reader than follow the system. She was right.

I told her I'd build a principle we could all use, not just a fix for this one article. Here's where I landed: if a snippet breaks a sentence but the article still holds, we keep it. If the snippet breaks the article — if the reader loses the thread — we create a new one. The line was whether meaning survived.

What held

The team started applying the principle on their own once they saw it held up — no system breaks, no pushback. They'd still flag each case for me, but after the fact, with a note on what they'd decided. I stopped being the bottleneck. The work got faster, and so did they.

Delivery stayed on timeline, and the one-off escalations that used to eat meetings just stopped — I'd already given the team what they needed. They started finishing with room to spare, and for the first time, felt like they could take on more than what was expected of them.

My takeaway

Before this, I thought leading writers meant reviewing their work and making sure it followed the guidelines — a final pass, a few suggestions. What I actually learned was that my job was to clear the path. When my team kept hitting the same wall, the answer wasn't better reviews — it was building something they could use without me. That's what made their work better, not my edits.

Why this matters now and always

What I carry from this is that the work of a content lead isn't just editorial — it's structural. When the process hasn't caught up to reality, someone has to build the interim logic that keeps the team moving. That's the part of the job I didn't expect, and the part I've relied on the most since.