Building and governing a team style guide
Ten years, one style guide, two different problems to solve
Tags: Content strategy · Style guide · Team leadership · Process improvement
The problem
When I joined the team, there was no shared style reference. The team's 12 writers (a number that was growing!) resolved ambiguous decisions like how to style a UI element, whether to spell out a number, or what voice to use in a warning by digging through past deliverables to find a precedent. It was slow, and it still produced inconsistent results.
The lack of a style reference really showed up during peer review. When you edited someone's work, you were often working from instinct rather than a documented rule. That made it harder to give confident feedback, and even harder for writers to receive it. When you don't have a shared reference, an edit can feel like a matter of opinion rather than a question of consistency. Having somewhere to point makes a real difference.
Building from scratch
I researched industry conventions and drew on established references to build a basic guide covering terminology, formatting, UI element naming, voice and tone, punctuation, numbers and dates, abbreviations, and product-specific terms. Once a solid draft existed, my co-lead and I facilitated discussions with the full technical writing team to introduce guidelines, discuss disagreements, and get the team's buy-in.
That buy-in was a really important part of building the style guide. A style guide only works if the team trusts it, and trust comes from being part of the conversation, not just being handed a document. Over time, peer review got easier. Writers spent less time hunting for precedents, new team members had a reference point from their first week, and reviewers could point to a specific guideline instead of defending a judgment call.
Governance: the harder problem
After several years, ownership of the style guide changed hands. When I returned to leading it, I inherited a document that had grown significantly. It had grown really quickly while being owned by someone who didn't know the whole document inside and out, and this rapid growth introduced a few issues. Guidelines contradicted each other. Examples were meant to illustrate specific rules but often illustrated something else, or contained errors that violated other rules. Some sections had expanded into long passages that read more like thinking-out-loud than usable reference entries.
My current work is a systematic audit: resolving contradictions (treating each one as a decision that needs team input, not just a quick fix), rewriting examples that don't accurately illustrate their guidelines, restructuring entries that are hard to scan, and removing content that doesn't belong in a style guide at all. I'm leading a group of 6 writers who contribute to discussions about the style guidelines and improvements to the guide. We've overhauled about half of the style guide, starting with some of the most widely used sections like the word list and the capitalization and formatting guidelines.