Jeniffer C. Johnson asked about the 'client - techie gulf': >>One, just how does one handle talking down to a general audience? Easy ... Don't! Address your remarks and writing to a specific audience. If the people in the room you happen to be speaking in have diverse backgrounds and levels of experience, then you may need to restate your key points several times - each time addressed to a different 'specific' audience - in order to "get through" to everyone. If there isn't a 'one size fits all', then offer multiple sizes. >>Second question, less important but to me more interesting: is this >>the norm? To some extent, yes. Simply because no one is an expert in everything. It sounds like you understand the important bit ... ignorance of a specific obscure technical detail does not, alone, make anyone a moron. I've spent a LOT of time being dragged to meetings to sit between the business folks and the technical folks and act as an "interpreter". One of the problems I see in these meetings is that, often, neither side seems to appreciate what's important to the other. Another problem, closely related and very common, is a lack of articulation on both sides. So I get to ask a lot of leading questions. ;-) I see biz users fail to ask for things that are critical to make the application run properly. [D'Oh! Do they _want_ it to fail? ... No, they just didn't realize the techie folks don't work in their area and didn't already know this stuff. The people they interface with on a normal day-to-day basis thoroughly understand all of that 'elementary' stuff.] I see techie folks build in features that they know are useless and stupid (like 150,000 value LoV dropdowns) because "I vas only vollowing oooorders. It vas in de requirementskis!"  Oftentimes it doesn't seem like either side understands that specifications are negotiable. I've seen both sides get freaked out when I point out something like "Mr. User? Do you really *need* this field you are asking for? Or is it merely a *nice to have*? ... The reason I'm asking is because, if we leave this out, the application Ms. Techie is building for you will run twice as fast ... and could be delivered six months earlier." - I've seen users freak and yell at the programmer "Why didn't *you* tell me that?" - I've seen programmers freak and yell at the user "Why the &^%*&^% did you ask for things you don't *need*? LOSER!" <sigh? ... It's Fun! ;-) It's an interesting role. I just wish it had an impressive (and recognizable) job title to go with it ... so I could ask for more money! ;-) Hmmm ... "Technical Expediter", perhaps? ... although I'm not sure that has enough panache. (I once told my former CEO my job title was "Information Alchemist" ... but I'm not sure he got it.) >>What gets you frustrated? Heh ... Don't get me started! ... being 'in the middle' I get it from both sides ... the biz folks can be frustrating when they haven't thought through want they want - mostly because that's going to mean lots of revisions and changes in the future. But frankly, the tech folks can be just as frustrating ... they do lots of 'stupid stuff' too ... physically deleting records from OLTP systems, including dozens of 'lookup-able' text description fields in my millions of records of transactional data! WTF? Who do they think they are? Grrrrrr! Oh well ... <shrug /> ... that's My 2¢, RonL.  Not to be overly mean ... I've seen it in rare cases on-shore, but I'm not sure I've ***ever*** seen an off-shore techie team question *anything* in the requirements document ... or even attempt to negotiate the specs. Hmmmm ... maybe I'll add a "... and monkeys fly out of your butt" requirement to the next spec sent overseas and see if it gets any reaction.   Of course, I'll definitely make sure *I'm* not going to be working acceptance testing first!