If I were a journo-entrepreneur 30 years ago one of the more important relationships I'd have to cultivate would be with the labor union. They drove the trucks and delivered the paper. They were literally the manpower that took your information to the masses. It would be a subtle and important working relationship with the union leaders and the workers they represented. My paper would be dead without them.

Today one of the most important relationships I have is with my developers. The joke goes "developers are the new teamsters." (Can't remember who made this joke first, but I am a notorious joke-repeater).

So far Spot.Us has worked with Hashrocket and I am very happy with our working relationship.

Ideally you are an Adrian Holovaty and are your own programmer. For the rest of us I give you:

Tips on working with your dev-team.

1. Give credit and sing their praises.This one is a little obvious – but it doesn't hurt to say it out loud. You should work with developers that rock hard and when they do, let them know how hard they are, in fact, rocking.

If you can't find a way to sing their praises – consider a new developer.

2. Open source: Not just the code, but the process.
Developers like working on open source projects. But they also want to feel like their work is being used and improved. This requires being open about the development process so it can be improved by users. Bottom line: Developers like that people are using the product and that it will improve through user suggestions. It's your responsibility to have that feedback with your users.

3. Understand the tools they are using and how that translates into practices.
Drupal, Ruby on Rails, Django, Joomla, etc. Different development communities have different philosophies. There is the "Drupal Way" and there is "Getting Real" which the RoR community espouses. Know what these philosophies are and how they translate into their work flow.

Use their existing workflow, project management tools, etc. Don't dictate to them how they should work. A good developer has already established their own best practices.

4. Be SPECIFIC with what you want.
Perhaps the MOST important tip! The more specific you are with your acceptance criteria – the less likely they will deliver something from left field. More importantly – they will appreciate that you (a. have a vision (b. can give the detailed steps to achieve that vision (c. have given thought into what you want them to build and how it can all come together.

I can't stress this enough. I'm not talking about a detailed 3-year strategic plan. I'm talking about the "what does every button on every page do" level of detail!

5. Learn to crawl with the technology, so they don't have.
I've learned to run the spot.us code on my computer and edit the views when I can. This is an incredibly small feat to any programmer, so I'm not patting myself on the back (it's really just slightly advanced HTML). But when I want to change the FAQ's or any other text on the site – I can do so without bothering the developers. They can stay focused on the more difficult programming tasks. This also means all spelling errors are your fault and you have nobody else to blame.

6. Separate design and development.
Unless of course you have a designer/developer. Let people work on their strengths.

What advice do you have? As always I don't claim to have written the book. But I'm learning as I go and these have helped me out a lot.