Brad Wilson pointed out a new, interesting blog yesterday: Spurious Pundit.
It's like you're asking them to hang a picture for you, but they've never done it before. You understand what you need done - the trick is getting them to do it. In fact, it's so obvious to you that there are constraints and expectations that you don't even think to explain. So you've got some junior guy working for you, and you say, "Go hang this picture over there. Let me know when you're done." It's obvious, right? How could he screw that up? Truth is, there are a whole lot of things he doesn't know that he'll need to learn before he can hang that picture. There are also a surprising number of things that you can overlook.
One way I've found effective is to start it together, pair programming style. This also implies the people managing the developers actually are developers themselves-- and that's the way it should be.
On bargaining:
Allow me a brief digression here. Technical staff actually operate in a different universe from the business side of the house. They're "reality-based" in the disparaging way that our current administration uses the term. Put simply, shit will either work or fail based on the properties of the observable universe. No amount of personal motivation or focus-group work will let a spare, obsolete PC handle a million page hits a day. There's math there. You can prove things.On the business side of the house, to an alarming extent, believing things makes them true. If the sales guys are confident and self-assured, if they really believe that they're great salesmen and they have a great product, people will trust them and buy stuff from them. If the managers believe that the current project is destined for success, and can keep everyone enthusiastic and focused, it's much more likely to be successful. By contrast, once people start believing it's doomed, they don't work as effectively, maybe they leave, and the project fails. (This is that morale thing I mentioned earlier.) It's all unsettlingly self-referential.
These traits which managers and sales people need to be effective are actually bad for technical folks. Arrogance means you overlook things. You miss subtleties that you'd catch if you were more cautious. Two heads are always better than one; three or four better still. (Okay, yes, there's a limit to this.) But any technical solution will be better if you can put your ego aside and plunk your idea down in front of some other folks for a good, harsh critical review. Being able to sell them on it by force of personality doesn't make it better. Being aware of your own failings and limitations makes it better. Being able to let go of your proprietary defensiveness makes it better. Learning to value the people who will poke holes in your designs - the ones who are "not team players" - makes it better. A considerable amount of humility is called for here.
Only three posts so far, but excellent insights in each one. I'm looking forward to more punditry.