I believe you ahve the right concept, but you may be taking it too far.  A better question than "What does my audience need to know?" is "What would my audiance benefit from knowing?" And that benefit should be defined very broadly.

I am working on a Masters in Math.  I have no need to know the history of the mathematics, but I do benefit from it.  It helps me to understand why some of the stranger definitions are the way they are.  It helps me see the human side in the development of mathematics past and present.  I do not need to know it in the way I need to know the proofs of the Pythogorean theorem, but I benefit from knowing it.

Similarly, a DBA may not need to know about the intricacies of LSNs or log chains, but they may benefit from it.  It may help them make better decisions in their coding, though I admit that would be fairly rare.  Even if they never apply it directly, it may help them understand and appreciate what they are working with and its capabilities, limitations, and reasoning.  

With all that said, I do believe in truth in titles.  If the title says it is delivering practical advice to be applied that very day, then it should do that and discussion of the technical details should probably be limited to footnotes and links in a further reading section.  If the title says it is a broad overview or else a detail technical discussion of the intricacies then it is fully appropriate to discuss those things in depth, whether or not your think your expected audiance has any need to know.

I don't see this so much with SQL Server as with new .NET technologies.  I love it when something like WCF comes out, and authors think they need to a) first explain it in gruesome detail from the inside out and b) immediately show you how to *extend* it with custom classes rather than simply *use* it.  

You need a simple view of something and some practical experience with it before a look "under the hood" is going to mean much.  Then you will have some "a-ha" moments when you understand why it works the way it does.

In addition to technical documentation for my databases and apps, I have to write users manuals for our staff.  I used to include everything in the manuals no matter how small the detail.  The truth is, everyone really did need to know that information depending on what they were doing or what issue they were having.  What I found is that I spent a lot of time writing manuals that hardly ever got read.  And even when someone did bother to consult the manual, they didn't seem to find the answer that they needed (and that *was* included in the manual).

So, then I started writing slimmed down manuals that might be less intimidating to the users.  The idea was to get more people to read them in order to solve their own problems.  I also spent a great deal of time coming up with key "How To" questions and organized the manual around those questions that involved common tasks that staff needed to perform in the application.  I was still spending a great deal of time on the manuals.  The result?  The same one or two people ever bothered to even once consult the manuals.  And now it was more likely that when someone did have a problem, I couldn't gently say, "Look it up", because that "small" detail was not actually in the manual.

So, then I started trying to create more comprehensive manuals (that were mostly still organized around how-to tasks) and also create supplementary one or two page "manuals" that I called "Cliff Notes".  The idea is that the user could use those quick reference sheets for the main tasks and dive into the manuals if they needed more help.  This also takes a lot of time to put together.  The result?  Same as above.  Still almost no one reads the manuals.  They just come to me.

So, then I started trying to do trainings with a few screen prints and skipping the manuals altogether.  If no one is going to actually read them, why waste valuable time that I could be spending on creating more apps instead?  The result?  Great outcries from everyone.  "WHERE'S THE MANUAL?????" they ALL cried.  Seriously.

The result?  I don't know.  I'm still figuring it out.

(Of course, if you are writing technical articles for people who actually want to read them, that might be a bit different than my situation.  I do think that attention to a readable writing style and relevant content is vital if you are going to write something.  You are spot-on there.  The problem is, there are so many different needs/angles out there, you are not likely to be able to please everyone/most people?  My bottom line is that it is the process that counts:  Do ask yourself those questions and write the best answers you can.  Then grit your teeth and smile at the critics.)

In the good (or bad, depending on one's disposition) olde days, such manuals were referred to as Procedure Manuals (or Docs).  They reached their apotheosis quite early, with the invention (by IBM, of course) of the Railroad Diagram.  

This is what a Manual need do; more so today with the Web everywhere.  With the Web everywhere, the question to answer is, "What function is missing from the Web everywhere?" and put that material into physical manuals.  Which leads us right back to the Railroads.  The manuals should show folks what steps need be taken to accomplish a given task.

Applications in those days were almost universally Menu Driven (still are if you're condemned to use an IBM mainframe or iSeries/AS400 in native gear); with a primitive command line, in a manner of speaking.  So, doing anything amounts to following the screens.  Knowing that what you need to do is 20 screens down some arcane path...

Oddly enough, even in a GUI world, applications are still largely Menu Driven, just with pretty pixels.  One still needs to know: 1) what specific screen is needed and 2) the path to that screen in order to complete a task.  On-line help, helps; but those Kiddies who've known nothing but Windoze *assume* that an application *won't let them do anything bad* -- there will always be an omniscient Undo key to fix their screw up.  

Such folks really to need a Procedure Manual, since much of what we see in GUI software is either a minimal port of an olde character app, or written to a procedural mode (OO languages not withstanding) by Koders who don't quite grok event driven paradigm; admittedly, much of what is tutorialed in OO languages ends up being wholly procedural (modulo an Eiffel application written seriously).  So, we're back to the beginning.  A Manual (physical or not) tells the user how to do stuff, and how to fix the problem(s) that ensue if they didn't quite do it right.  That last bit is generally missing; I know from much painful experience.

> "The more I write and edit, the more I become convinced that the real art of technical communication lies in knowing what to leave out."

Bravo!

I think the writer needs to question himself:  is he writing in order to edify the Ubergeek?  Or for the more attainable goal of providing practical knowledge, and to impart perhaps a bit of hard-earned wisdom, to the rabble of DBAs (e.g., myself) to whom our professions are more livelihood than loveliness?  Or to make money?  Or to build fame?  Or to entertain himself (and perhaps anyone else who serendiptiously happens along)?

Readers have perspectives, too.  An old warhorse colleague named Ken had been writing code since the early 1970s (BAL on IBM mainframes) when I first met him in 1988.  Whenever I would bring up "newfangled" concepts (which at the time included relational databases), Ken would fix me with a cold stare and announce, "Look, I'm not trying to get an 'A'; I'm trying to get a job done."  Well, some of us are looking for that 'A', and some of us aren't.  And some of us might be interested in pursuing that 'A', deadlines aside.  (As intellectually interesting as it might be, most of us are not likely to devote many resources to learning all about the fascinating taxonomy of, say, alligators at the moment in time when we're cheek-deep in them.)  In short, time is a finite commodity and the writer who respects that is a wise writer indeed.

Not being an Ubergeek myself (just an old working stiff), I could never write for Ubergeeks, they'd sniff me out in a heartbeat.  (I know this from experience.)  I'm at an age where I have used up all my brain cells, or at least the ones not already earmarked for death by martini.  Yes, I can still learn new stuff, but it requires that I permit something I already know to slide out of my brain -- so any new stuff better be good, because I don't know until after the fact what it has cost me.  It would be great if I could run a biological version of SDELETE which would compress the facts and concepts in my brain toward the frontal lobe; then, in my newly freed-up hinterbrain, it would scour out all the useless information I've gathered in 56 years of inhabiting this mortal coil.  But, alas, there is no control switch by which we are enabled to memorize the various editions and version numbers of SQL Server simply by targeting and re-purposing only those brain cells which hold a useless piece of knowledge -- e.g., the "Gilligan's Island" theme song.

My advice to most tech writers, however, is to try and learn how to write -- entertainingly would be ideal, but clearly would be acceptable.  And by that, I don't mean that prospective readers should require the printed English version of dancing girls and trained seals to hold our attention.  I simply mean, try to explain concepts as simply as possible, but (to paraphrase Einstein) no simpler.  An old jazz trumpeter once explained the problem of young virtuosos -- "It's like they're trying to show you everything they know in the first five seconds."  Explain the problems as clearly as possible and resist the urge to inundate the reader with red herrings.  If you can explain yourself clearly, in crystal-clear prose, they will stick around on their own and eventually discover your depth of knowledge all on their own.

There's some great feedback here – thank you to everyone. JJEugene, your tale made me wince and laugh at the same time. I think Lee nails it though; if you are writing to impart practical advice, the emphasis should be there – on the hard-earned wisdom, on ways of describing a new technology or technique in terms of something with which you know the audience will be more familiar. Very little is "completely new", though much is presented that way. It should not become a 'peacock display' of internals knowledge, which is the trap I felt I was falling into with transactions logs. Yes, as Timothy suggests, this knowledge will definitely be beneficial….at some point. And therein lays the 'art of reveal' that marks out the best, practical technical writing.

As a writer of internal technical documentation I have often found that I am too "wordy" and to “convoluted” in that way I write it. What has help me countless of times is to have a “none technical” user check and explain back to me what my documentation is trying to explain. This has most often led to my documentation being simplified and easier to understand, even by myself.

Do you understand this reply? :-)