Promote the importance of using standard templates and styles in Word, and your personal brand will closely resemble that of a last-century librarian.

In the last century, librarians had the thankless but important task of making sure a book, once put on a bookshelf, could be found again when needed. But their image, like yours, is that of persnickety individuals who magnify trivia because they don’t have any important problems to work on.

Which is why, should you decide to try for standardization anyway, you’ll do well to remember the first rule of persuasion: Sell the problem (or opportunity), not the solution.

Last week’s KJR was an attempt to sell the problem, namely, that even when a business organizes work as a practice rather than as a process, failing to standardize on some of the basics can cause quite a lot of friction in the gears of getting things done, by creating completely unnecessary work whose prevention is almost entirely free.

And by the way, there are also situations where trying to institute standards would cost a great deal while being a hopeless cause. My daughter the programmer tells me GitHub illustrates the point well. While GitHub does publish style guides, the nature of the beast means there’s no way to enforce them, nor should there be. The result, though, is that making sense of what’s out there takes more work than if everyone followed the same coding standards.

Leaving this “And by the way” by the way, let’s get back to last week’s entirely prosaic example of a team that, in addition to coding, has to write documentation together. What’s the best way to get everyone on board? Put it differently, what does everyone have to understand about using Microsoft Word so standardizing on styles makes sense, rather than just being an act of resentful obedience?

MS Word styles are usually explained entirely wrong. They’re usually presented as ways to keep formatting consistent throughout a document.

They do achieve that, but it’s a happy byproduct, not the main event. Here’s what everyone on your team needs to understand about a style in Word: It identifies a specific part of a document.

Which in turn means that in order to use styles correctly, writers need to think about how they’re structuring what they’re writing. If you’ve ever been on the receiving end of someone who thinks their job is done if the information they’re supposed to convey is in there somewhere or other, you’ll understand the value of taking a writer through this thought process.

Documentation writers aren’t (or shouldn’t be) budding James Joyces. Their readers are more likely to be waiting for the project to be finished than for Godot, so there isn’t much justification for stream-of-consciousness expression in the documentation they write.

Authors of documentation should recognize when what they’re writing right now is the document title, subtitle, a section heading, body copy, one bullet in a bulleted list, a sidebar, a table column heading, table text, or something else.

They should, that is, understand the structural nature of what they’re writing as a document part. As author, they’re responsible for identifying this. Someone else can decide what a heading, sidebar, or list bullet should look like.

What’s strange about all this is that programming teams seem particularly resistant to adhering to the principles of document architecture in their writing, and this in spite of their being better-equipped to understand these principles than just about anyone else in the company. There’s no important difference, after all, between styles in MS Word and what developers do when coding cascading style sheets — the programs (yes, they’re programs — give them proper respect) that explain to a web browser how to render every HTML tag that’s included in a downloading stream of text.

One more point: As is so often the case, the all-too-frequent response to programmers who violate the rules … whether of documentation architecture or, more importantly, of software architecture and coding standards … is enforcement.

As a last, desperate alternative to receiving bad code and junky documentation, enforcement is better than nothing.

But if your goal is a high-performance software development practice (and this applies, by extension, to any business practice), enforcement isn’t what will get you there. Enforcement takes too much managerial effort to overcome too much team friction.

High performance comes, not from oversight, but from education and culture — making it how we do things around here.

Otherwise it won’t be how we do things around here.