Journals by RSS
Journals by EmailLast week the thought popped into my head: “Good enough really isn’t good enough.” Then, at the STC Intermountain Chapter meeting last week, one of the members said that where she works, Agile methodology has given rise to the concept of “good enough documentation.” It was funny she should say that because I had just been thinking about it.
I’ve talked to other technical writers who are on small teams and are kept on the go all the time. Probably due to their companies trying to save money, their teams are understaffed and overworked. When deadlines loom, it’s time to pick and choose the most important pieces of documentation to focus on and shrug off the rest. As a result, the documentation isn’t all it could be.
Some may say that what is most important really is all that should be documented so that you don’t end up with too much documentation. But can you guarantee that even the priority items are polished and perfect when you’ve got a deadline every few weeks and only one or two other writers are there to back you up?
I’m enough of a perfectionist that I mentally wince every time I find myself thinking, “It’s good enough.” It sounds like a cop-out. It sounds like avoidance of responsibility and ownership. It sounds like I’m indifferent.
And the older I’ve gotten, the more I’ve realized that there are few things I’m indifferent about.
So for me, “good enough” really isn’t, at least when it comes to what I produce as a professional.
I wonder if settling for good enough contributes to lower job satisfaction and a feeling of not adding value. I know a guy who is constantly looking for better ways to contribute in his role as a technical communicator. What management asks for is probably good enough, but he wants to give the users the best he can put out. When he pushes the envelope and goes beyond people’s expectations, he gets positive feedback, especially from users. He gets more out of his job, and it gets more out of him, than if he settled for good enough.
Anyway, just some thoughts I’ve had. If I find myself thinking “It’s good enough” on a regular basis, I—and my users—am probably not getting all that’s possible out of my work. Those of us who are perfectionists may be right in thinking good enough is good enough because to someone else, that may be pretty exciting. For that reason, though, I think it’s by setting our own expectations high that we can deliver exceptional products.
Related entries (auto-generated):
When Tech Writers Don’t Read Directions
Making Learners the Teachers in E-Learning
Three Ways to Get Developers to Keep You up to Speed
Release Scrums: An Important Resource for the Agile Technical Writer
7 Comments to '“Good Enough” Really Isn’t'
April 23, 2009
Quote: I wonder if settling for good enough contributes to lower job satisfaction and a feeling of not adding value.
To the contrary, ‘good enough’ maximises value. It’s an optimisation problem. Low-quality documentation results in dissatisfied customers and enquiries to a help desk. Excessively high-quality documentation wastes resources. Our task as technical communicators is to produce documentation that is ‘good enough’.
[Reply]
April 23, 2009
As Mike hints, the underlying thinking, as a professional, should really be focussed on ROI.
It’s a classic and much needed conflict that is at play here, where one side of the scales is weighted with cost, the other with quality. Good enough documentation should, ideally, balance the scales.
[Reply]
April 23, 2009
“Good enough” is good enough only when your supervisor says so. That remains my benchmark.
[Reply]
April 24, 2009
Ben:
I feel the same conflict you do. “Good Enough” may be what my boss and company want, and are happy to get, but when I know the product could have been better or more complete with just a little more time or effort, I have regrets that it wasn’t.
Maybe it’s an age or attitude thing, and in this economy, especially, we have to do what we can with the resources available, and balance the competing demands and restrictions. But we can always resolve to try to add what we missed this time to the next release.
[Reply]
April 25, 2009
@Mike, Gordon, Craig,
Sounds like you have a handle on your perfectionism. I’m not at that point yet. Mike used a key word: excessively. Anything that is excessive is by definition more than is healthy. This post reflects the connotations I have with the phrase “good enough”—it involves concessions and giving up. For some, including you guys, it may not carry those negative associations. However, I agree that this is an issue we have to be smart and deliberate about in our work.
@Margaret,
Thanks for adding your voice. Perfectionists of the world, unite!
[Reply]
May 12, 2009
Ben
Your post leaves me wondering: who says when the documentation is “good enough”? It *should* be the customer: the people who *need* assistance. In some organisations, however, I think the “good enough” philosophy is sometimes driven by individuals outside the documentation team who really mean: “let’s just give them the minimum possible amount of documentation we can get away with while avoiding them (i.e. the customer) suing us or bad-mouthing us in public.” I’m lucky to work for a company where “good enough” documentation means: “let’s aim to deliver documentation that meets our customers’ requirements”.
The temptation is always to keep improving your documentation way past the point where anyone other than a fellow tech writer would value – or maybe even notice – your improvements. If we do this at the expense of other documentation that needs written or updated, then we’re not doing our customers any favours.
[Reply]
May 12, 2009
Great point. In my post and our discussion, we neglected the customer perspective, which is really the most important consideration. I completely agree with your comment. Sometimes (or maybe most of the time) we may think we’re pushing our improvement of the documentation to meet users’ needs, but we don’t actually find out if it’s doing so. As a result, we don’t know whether we’re improving it in reality.
[Reply]
Set Me Straight. Leave a Comment.