> > Instead of continuing to > make the request, ask what it would take for the request to be > possible. >
Thanks, Jason. I like this shift. It moves the dynamic away from a tightly confined yes/no (and often win/lose) to an expansive *how*. It welcomes collaboration in finding something better than either yes or no to the original request, in that both/all parties' needs can be addressed, not just one. - Conal On Thu, May 21, 2009 at 11:04 PM, Jason Dagit <da...@codersbase.com> wrote: > On Thu, May 21, 2009 at 10:53 PM, Conal Elliott <co...@conal.net> wrote: > > > <advice> > > One thing you may try is to ask the architect for evidence and/or logical > > proof of his claims that something cannot work. As much as you can, ask > > from a place of curiosity and even awe. After all, existence can often > be > > proved by demonstrating an example, while non-existence proofs tend to be > > much more profound. And stick to your open-minded disbelief until you > > really see evidence or logical rigor. If the architect gets flustered > and > > embarrassed, he may well go on the attack. After all, bravado signals > weak > > ego, which can quickly become a cornered animal. So pay attention to his > > stress level, and help his salvage his ego, by suggesting he let you know > > more about the evidence and/or logic when he's worked it out. Be careful > to > > stay in your integrity, neither going along with someone's forcefulness, > nor > > representing yourself as having more grounds for confidence than you > really > > do. > > </advice> > > Thanks Conal for that sagely advice. > > I recently asked my local conversation expert how to deal with passive > aggressive people/managers, and he gave similar advice. He said that > when someone is dragging their feet or providing excuses, change the > conversation into one about problem solving. Instead of continuing to > make the request, ask what it would take for the request to be > possible. I think your advice is exactly that, just in a slightly > different context. > > Also, in the times when the speaker understands the problem better > than myself, I tend to learn something new about the problem domain > that, whether it is a show stopper or not, is a significant issue to > address. > > Thanks, > Jason >
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
