Dear Bob ... Your point: Beware of anecdotes and metaphors. They're useful ... for illustrating a point, or for demonstrating that something is possible. For anything else you need statistically valid evidence. Yes, Disraeli said there are three types of lie. He miscounted -- argument by anecdote is far more pernicious than argument by statistics, and argument by metaphor is even worse. Yes -- you do have to und Dear Bob … Your point: Beware of anecdotes and metaphors. They’re useful … for illustrating a point, or for demonstrating that something is possible. For anything else you need statistically valid evidence. Yes, Disraeli said there are three types of lie. He miscounted — argument by anecdote is far more pernicious than argument by statistics, and argument by metaphor is even worse. Yes — you do have to understand statistics well enough to evaluate the evidence. Sorry. That’s part of your toolkit.I am trying to motivate my team, why they should they cooperate and collaborate as a team. If I cannot use sport anecdotes or mountain climbing metaphors or performance metrics to motivate them, what tool should I use … the pink sheet or the katanna?– Looking for the right tool Dear Looking …The long answer is (he said, sounding like a two-bit shill) one of the chapters in Leading IT: The Toughest Job in the World.Not wanting to either write it again or cut-and-paste it into a blog posting, here’s the short version: If you want people to operate as a team, you have to structure the work so they’re interdependent in achieving the goals of the organization.Never mind how you measure whether you’ve achieved the goals. Start with articulating them – the dreaded Mission, or however else you characterize them. So you’re running application development. What’s the goal: Implement, enhance and maintain the company’s applications so they provide optimal support for the processes in use throughout the business.If you parcel out pieces of work that each developer handles independently, telling them they’re supposed to act as a team is pretty much pointless. If each has part of the responsibility, and part of the responsibility of each is to make sure the next person in line is in a position to succeed. For example, if the data analyst and business analyst understand they, along with the coders, are collectively responsible for assuring the requester considers the result to be a success, they’ll make sure the coders understand what they’re supposed to build, and they’ll be available for periodic review, too – they’ll be mutually supportive because they’ll fail if they don’t. (Not that I’m recommending this as a development structure, necessarily, but because it helps get the point across.)If, on the other hand, the data analyst is responsible for the data design and the business analyst is responsible for the specifications, they and the coders will point fingers at each other until the cows come home, assuming the cows ever do with all that commotion going on.– Bob Technology Industry