HomeOrganizational Effectiveness

To optimize a business practice, show some style

Like Tweet Pin it Share Share Email

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.

Comments (4)

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

    I’d argue that enforcement and particularly oversight is a large component of making something part of the culture – “how we do things”.

    Take for example the wearing of seatbelts and the use of helmets. Education, oversight, and enforcement all went into making those standard parts of our culture.

    Ditto for speed limits – if they’re not enforced, drivers decide for themselves what’s “safe” and they drive at all sorts of speeds. Where they are enforced, drivers so learn, and traffic moves along at about the speed limit, and newcomers pick up the “culture” of driving this speed on this road, with minimal enforcement necessary.

    When instituting cultural changes – I’m sure you’ve spoken about his before – it’s important to have leadership providing not only education, but oversight. And enforcement as a final resort (if someone is consistently not meeting expectations, typically they are “encouraged to find alternate employment”).

  • For the writers, perhaps the issue is caused by the initial sale pitch (long ago) of “what you see is what you get”. It focussed people on how the document looked, to the detriment of how the document was structured.

    When the rewards (either self-evaluations or from management) are based on the appearance of the product and little else, people will care about the appearance of the product and little else. To get people (writers, developers, anyone) to focus on the structure, we need a visible evaluation of the structure. Our current tools and processes (practices?) do not make that easy.

  • Good article, but if you’re going to cite Godot in a paragraph that also refers to an author, shouldn’t you name Beckett rather than Joyce? Furthermore, I don’t think anyone wants their documentation to look like Joyce’s Ulysses! 🙂

Comments are closed.