The typical view of a business type by a software engineer is not pretty. It gets pretty close to, we do all the work, they do little but interfere with us, and then they take all the money. So it's an uphill battle to have a good relationship. (The _truth_ of this view varies wildly from company to company, but the perception is always there.)
See the movie "Office Space" for details. :)
Things that are a good idea:
* Your technical staff is probably very smart, and not just about their jobs. Listen to them. They're particularly good at working with data. If they say that your market research doesn't sound right, even though that's your job and not theirs, it's worth going through it. Geeks are generally happy to learn things, too, so if you're actually right and can show it, we really like that too.
* Give your geeks the big picture. It really does help, because we're constantly making long-term tradeoffs, and if we know where the company is going, we'll be less likely to need to say, "Uh, we need to do a massive project for that feature, sorry!"
* Try to give clear requirements and make changes early. It's not an easy thing to ask, but a change made in planning phases is cheap. A change made when the project is in beta is expensive if not impossible. A business type giving a list of changes every day late in the project is infuriating.
* As a corollary, ask to see things early. A prototype with partial functionality is good. It's really true that a lot of times a business type just can't reasonably know what they want until they have something to play with (which is fine), so get that sooner, when things can be cheaply redesigned.
* Understand that changes aren't free. Schedules get made based on original requirements. If the requirements change, it will take longer to finish. If the deadline is fixed, you can't ask for something new without giving something up. Business types that understand this are much, much easier to work with than ones that don't, and are by far the exception.
* Programming requires uninterrupted time, like making a painting or writing an essay. If someone asks you a five minute question, it can take half an hour or more to get back in the flow of what you were doing. Try and send not-urgent questions via email, schedule meetings for the beginning or end of days, and if you can take, "Can I get back to you in 15 minutes?" for an answer, that'd help.
* Understand that these guys can, and do, do the math with respect to compensation. When I had a CEO that asked everyone to put in 60 hour weeks, and then we ended up with 3 figure bonuses when he got a 7 figure bonus at the end of the project - none of us ever respected him. If we're giving more than expected, and we will, show us some of the reward, or watch us leave. Even in a down economy, a competent techie can find greener pastures if it turns into us vs. them.
* Techies are not big on hierarchy and authority. After all, especially in a technology company, we know more about what we do than you do, and if that's the core product, there's often conflict between who is in charge and who knows about what actually is the product that pays the bills. We like to think that we work _with_ the business types, not _for_ the business types. If you project the story of doing some useful work that we don't want to do (like find buyers for our product, get us good press, find investors, stuff we want to happen but don't want to do), it'll go a lot better than if you present yourselves as 'leaders' with 'vision' and expect us to do your bidding. It's a team, and while we get that the buck has to stop somewhere and it's going to be the person with the title in the end, prima-donna VPs are just as well liked by us as prima-donna developers by you.
Someone could write an equivalent set of bullets in the other direction - yes, business people are smart, their jobs are hard, and they're often worth the salary they earn too (and certainly a lot of techies are useless.) But I'm probably not that someone. :) Hope that this is somewhat useful to you, though! I certainly have found that some business people treated technical people well and were good to work with, and others, not so much.