TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
Ahhhhh I see. I once read an article that used the jargon-y phrase
"double-loop learning". It used the metaphor of a thermostat. In real life,
a thermostat only responds to a temperature change, and turns on or off
accordingly. This is single-loop learning. In fantasyland, a thermostat
should turn on or off, but also ask why the tempaerature changed, and add
some logic to its process that will make it better prepared next time. This
is double-loop learning.
I like your hot-pepper analogy better.
Anyway, you raise good questions. I beleive I'm blindsided because there
isn't a process in place that anticipates clients' needs. Each time the
regulatory environment changes, our developers are all over it, but I don't
get the heads-up. That situation is improving, and I'm participating the
improvement, so I hope to be blindsided less.
But even if I'm not blindsided as often, the information will change
continue to change as regulations change, which becomes a maintenance
nightmare. For the last couple of years, we've responded to the nightmare by
not updating the Framemaker-to-PDF documentation at all, which makes me
think a more flexible, informal, easy-to-update, easy-to-distribute format
like a knowledge base might be more appropriate. Hell, all I'm doing now is
firing off two page solutions over email, and that seems to work fine -- if
I put them in a knowledge base and index them to death (as another whirler
suggested), that would at least make the information slightly more
accessible to clients.
Ok, I'm just thinking out loud now. Thanks to all for the great ideas.
Regards,
Brian
> Bill D. pontificated [his word!]:
>
> There is a major distinction between symptoms and problems. Symptoms are
the
> result of problems. Here's an example. You go to the doctor with a stomach
> ache. The doctor prescribes medication. You take the prescription
medication
> and your stomach feels better, some of the time. But, what caused the
> stomach ache in the first place? It turns out that you love hot peppers
and
> eat them twice a day. Now, the problem is not your stomach ache, that's a
> symptom. The problem is your love of peppers. Eating hot peppers is not
the
> problem. However, your symptoms come about from eating the peppers. Stop
> eating the peppers, your stomach ache goes away, and there is no need for
> the prescription. Now, in this case, you did not remove your love of hot
> peppers, the real problem. But you eliminated all of the symptoms.
>
> OK, back to reality. One symptom is you are being blindsided by urgent
> requests. The question is, why are you being blindsided? If you can answer
> that, you may get to the root of the problem.
---
You are currently subscribed to techwr-l as:
archive -at- raycomm -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- raycomm -dot- com
Send administrative questions to ejray -at- raycomm -dot- com -dot- Visit http://www.raycomm.com/techwhirl/ for more resources and info.
