A concept repeatedly flogged in this space for more than 15 years is the difference between business processes and business practices.
Optimizing big, formal, core business processes is a form of engineering — it’s often called “re-engineering,” and ain’t it a shame process re-engineering so seldom involves actual engineers?
Optimizing business practices isn’t engineering. To optimize a business practice you have to improve the practitioners.
Most business processes require Big Software to manage them. But business practices don’t. Business practices are akin to crafts, and crafts depend on toolkits. The standard business practices toolkit consists of an office suite, remote collaboration tools, and maybe something specialized like a project management system. These toolkits are non-trivial, but orders-of-magnitude smaller in scope than what business processes require.
But unlike traditional crafts like cabinetry, baking, or jewelry-making, with business practices mastery of the tools of the trade is strangely optional. The impact of that optionality is, to be kind, significant.
Take the common situation of a team collaborating to write documentation. Typically, different team members write different sections, which someone — perhaps a technical writer — assembles into the final document.
That’s where the fun begins, assuming, that is, your version of fun consists of making lots of round pegs look like they belong in all of those square holes.
We’ll leave alone the challenge of multiple writing styles. While insisting everyone take a class in business writing would be helpful … I’ve spent more of my life than I’d care to admit re-writing colleagues’ passive voice into a form where it’s clear who’s going to do what … in the end there’s no substitute for an old-fashioned re-write to make sure the final document has stylistic consistency.
The importance of tools-mastery comes from something far more prosaic: Making the physically assembly faster and less error-prone.
To understand how it should work, let’s take a look at how it usually does work in a “modern” (which is to say, backward) workplace:
- Jack’s a Unix jockey. He learned to format text writing in Vi and perfected his skills in Eudora. He uses the default font for just about everything, adds spaces to line up columns of numbers, hits <enter> twice to separate paragraphs, and uses a Perl script to convert his personal <number this> tag into actual numbered lists just before handing his section over to the team’s technical writer.
- Jill likes formatting — she likes to say formatting is the written equivalent of body language. She handcrafts every title, subtitle, and heading. She particularly likes Comic Sans for headings and handwriting fonts to give words particular emphasis. Her bullets are adorable … hearts, hands, stars, each in a color that fits the mood of what she’s writing about, or perhaps her mood when writing it.
- Jerome is a visual sort of guy. He’s a brilliant Visio jockey. And he’s even smart enough to paste his Visio diagrams into Word as bitmaps instead of OLE objects, knowing this will help him keep control of the diagrams. He’s mastered the art of adding a caption to his diagrams, and stylistically he reliably makes statements in his text along the lines of, “As Figure 3 illustrates …”
- Jane thinks in terms of bullets. She’s terse and to the point, clicking the Bullets button in Word’s ribbon so often that if it was a physical button she’d have long ago rubbed away the ink of the image that labels it.
What’s wrong with all this is that these habits can add literally days to the job of document assembly. Double-enter paragraph spacing ends up with no space in front of some paragraphs and extra spaces after others after the editor has moved a few paragraphs around. Manually numbered lists end up as mis-numbered lists after the first edit.
“As Figure 3 illustrates” points to the wrong figure when the assembled figure captions in different sections automatically renumber. Or, worse, it points to several figures, because other authors manually number their captions, so the assembled document has several Figure 3s.
Add to all this the nightmare of having to manually construct and periodically revise a table of contents when few headings in the document make use of Heading styles.
And on, and on, and on.
Documents have an architecture just as surely as databases do, and teams of practitioners who violate these rules wreak every bit as much havoc as those who violate Codd and Date’s 13 principles of relational design.
The moral of this tale of woe? To optimize your business practices, insist your practitioners learn the tools of their trade.
Because while learning them isn’t the same thing as mastering the craft, failing to learn them is the same as failing to master it.
I was going to say that a better approach might be to have the collaborators submit unformatted content and assign the job of formatting to one person. But considering the problem of “referring to figure 3” made it clear that some formatting is part of the content. But I suppose a good formatter would find an efficient way to deal with that. I’d pick Jill.
The problem with unformatted content is that it isn’t just formatting. The formatting reflects the document’s structure, and if it’s unformatted there’s no way to differentiate between heading levels, or even between a short, one-sentence paragraph and a heading.
Next week’s piece will discuss this in more depth. Unless I’m not in the mood, at which point …
Bob;
I have been there, more than once, and its not just formal multi-person effort documents, though I have worked as “compiler” of a few dozen multi-hundred page proposals and RFPsin my day.
Administative assistants, who try to duplicate a paper form, to create an “electronic” version, Where formatting and alignment are done by using spaces, no actual fill-able form fields and when you type in your info, the underscores that make the line just start shoving across the page…
…and when you email them back the “filled in” form, they complain because you ruined their pretty page layout.
I think it’s a hopeless cause, but thanks for giving me something I can show my worst offenders.
Just a quick correction for “Jack.” A UNIX jockey would NEVER use spaces in lieu of tabs!
This seems to go beyond simply knowing how to use ones tools.
At a high level, someone working a process focuses on the steps, while someone working a practice focuses on the result or output. To do this well, the practitioner has to know what resources are available and what constraints apply. Constraints can be the obvious, such as cost and time, or less obvious, such as regulatory and legal.
In your example, it appears the practitioners were not provided sufficient information to properly perform their jobs. They need guidance on the constraints – in this case: how to output the documentation so it can be combined in the most effective manner. Without that, it’s like a chef asked to prepare something special, but not being told the main guest has a severe food allergy. You might get lucky, but don’t count on it. In effect, the practitioners are being setup to fail.
We seem to have reached very different conclusions. My opinion: For document construction there’s a minimum standard of basic professionalism knowledge workers should be expected to adhere to. It includes knowing how to make use of Styles as a way of identifying standard document parts (heading, sub-head, sub-sub-head, list bullet, and so on).
If we’re talking about folks who create documentation on a regular basis, I agree. If we’re talking about a random group of engineers who are expected to document their knowledge, not so much. Given how much practices rely on the practitioner’s personal knowledge, we may be making different assumptions about the team members prior experience.
I will concede that anyone who performs practices on a regular basis should anticipate such issues and act to minimize such problems. For example, when I’m asked for an ad-hoc report, I almost always kick back something quick and dirty and ask “Is this what you need?”, then tweak based on their feedback. It’s reasonable to expect someone on our example team would have done the same, which could have saved everyone a lot of wasted effort.
I gotta go with Bruce on this one. Knowledge or skill about how to work use the tool isn’t the main issue, though it’s table stakes. It’s that thing Bob Lewis always talks about, “how we do things around here.”
The document contributors need to adhere to a common set of practices. It’s somewhat important what those practices are; it’s more important that they be standardized.
There are multiple style guides for journalists to use, and multiple formats for listing sources in a bibliography. A newspaper or teacher or school will set the standard for which to use.
Likewise, I assume that even when developers are using the same language/software, there will be locally-set standards to adhere to.
With your example, I guess it would be like having your programmers use C++, while they have a varied background in Fortran and Pascal and COBOL and Basic; and then expecting them to pick up, or have picked up, C++ on their own, without providing training or even setting standards.
Collaborative document creation tools will likely keep evolving, just as word processing tools have evolved, and it’s unwise to simply assume that your workers will have kept up-to-date on all the tools out there.
It’s one thing if your new hire told you he was proficient in Google Docs, and turns out he isn’t; but if he says he’d only ever used Word, then you’d want to make sure he understands how your workplace uses Google Docs, and that means some educating.
Thanks as always, Bob, for the insight. I think this is a fit: I’m a developer on a growing team that is rapidly closing in on a critical mass where we must better master tools such as Team Foundation Server for more than just source storage. But for many in my group it will also be a shocking culture shift where, before a few years ago, source control was a file share on a server.
Oh, that’s a fit alright. Excellent example, too.
The question is, do you expect your team members to master tools like Team Foundation Server on their own, or does your workplace provide some training on it once it’s been selected and implemented?
Since you say “tools such as”, I’m assuming that TFS is one among other options. Should knowledge workers be expected to be proficient in all of them? Or if they move from an environment that uses one to a workplace that uses a different one, should it be understood that existing staff teach the newcomer the idiosyncracies of their particular platform, and any standards the workplace has set.