Many of those windbags are your potential customers. :) When you are doing customer development in a B2B startup, for example, you should speak the client's lan

Many of those windbags are your potential customers. :) When you are doing customer development in a B2B startup, for example, you should speak the client's language. In a consultancy role, you should be able to speak to both programmers and management. It is not duplicitous to speak a different language and use different cultural cues when speaking to programmers than when speaking to non-programmers. Learning the basic customs and language of business is a start, when we speak of the original poster's position that others were promoted above him despite technical skill. "What's funny about these books is that none of them tell you how to act like you didn't just read these books. Personally, I find the tells so obvious that I can't even interact with people that are following this advice. It's like talking to Eliza." It takes time and practice to develop fluency. Perhaps it is unfair to speak of a couple of books as a "magic bullet," but it's a decent start. That said, I do not suggest that these strategies should be used with other programmers necessarily. But strategies of facilitation (if I may delve into organizational communication for a bit) can help in many situations. I've seen inferior ideas pushed through because someone was more aggressive in argumentation, not because the idea was superior technically. I've seen developers ignored because they had a softer voice. (I've seen developers ignored because they were women, tangentally.) Collaborative conflict management models have their place, particularly in larger organizations where departments have cross-purposes.