•A highly placed but dissatisfied IT professional from a major software company is considering leaving because he does not like the approach of the person recently hired to manage the programmers, a Harvard MBA.

I ask whether he feels he could do a better job.  In response he tells me three times: “I am a programmer; I am not a people person.”

•I am on the phone with the recruiter for a consulting company.  She says her company has 60 to 70 consultants.  She mentions problems staffing the San Francisco office.  Four years pass, we speak again.

This time she tells me, “We have between 60 and 70 consultants and we will probably always have between 60 and 70 consultants.”  Oh, and PS:  The company “still can’t staff the San Francisco office.”

The problem?  In each case, Lethal Language.  Each speaker described their situations in words that express that killed off possibilities.

Memo to you:  As sure as words describe, they likewise specify limits.  “I am not a people person,” and “We have between 60 and 70 consultants and we will probably always have between 60 and 70 consultants,” are descriptions that limit possibilities and ward off even trying.

 Can you sense the case-closed, what’s-the-point-of-further-action vibe?

There is another way to speak and think.  Effective language transforms limits by suggesting that it is reasonable to act.  Thus, while lethal language eliminates hope by creating boxes from which you seemingly cannot escape, effective language sparks hope and action.

I never spoke to the recruiter again.  But I began coaching the IT guy and went right after his “I’m-not-a” statement.  First I asked what he would do differently from the MBA.  Then I asked what kind of people skills his programmers needed and whether he didn’t already have them.

At first sheepishly, then with a quality of certitude, he acknowledged that he thought he actually knew quite well what his people would best respond to, and that it was different from what the MBA was giving.  Next I asked whether his bosses usually listened to his ideas.  He acknowledged that they did.  He then went to them, made his case, asked for the job and got it.  And in his new position, Mr. IT thrived and so did his staff.

What did we do?  1) Questioned the limits; 2) questioned his definition of people skills needed for the job; 3) opened up the possibility that as an IT guy who understood programmers, he had knowledge and skills that others didn’t; 4) implicitly suggested that with a plan and clear arguments, he might be able to persuade his bosses.  Result:  transformation.