In the person-to-person enterprise, smart leaders avoid specific policies whenever possible, stating instead the principles they wish to embed in the corporate culture.

“Person-to-person” is the phrase introduced in my upcoming book, Lewis’s Laws (IDG Books, due on shelves next March), to describe how businesses will operate in the emerging post-process era. It means business success depends on how well individual employees connect with individual customers. A person-to-person business puts employees in the middle and views processes and procedures, information technology, knowledge-sharing systems, along with the telephone and office furniture, as nothing more than resources each employee may use to be more effective.

As for IT standards … the policy-ridden centerpiece of many IT organizations’ relationship with end-users … in the person-to-person enterprise these are defined and managed to make employees’ computing environment better, not more restrictive.

The following story, related by a regular reader, did not come from a person-to-person enterprise:

“My wife manages a help-desk call center. The IT department in her company is responsible for, among other things, maintaining the telephones. During a recent week, the telephones went down six times, for a total of about 7-1/2 hours. This was a very serious problem. My wife had one of her people create a simple Microsoft Access table listing the date, time and duration of each outage and sent it in an email to the IT manager. She asked the IT manager to fill in columns listing the cause of the outage and the corrective action taken in each case.

“When the IT manager received the email, she called her staff together. However, rather than talk about the problems with the telephones, the discussion centered solely on how to stop users from using an application (Microsoft Access) that wasn’t supported by that IT group. The telephone problems were completely ignored.”

Please pay close attention. In the person-to-person enterprise, the proper response to a reported problem is a root-cause analysis, not a shot aimed at the messenger. A crash-prone phone system does not promote employee effectiveness. When the problem persists, end-users have every right to ask what’s being done to fix it.

All is not lost, though, because the same IT department prides itself on monitoring the quality of its (internal) customer service. As evidence, my correspondence offers the following, related by a director within the IT department:

“The IT department sent out an electronic survey to the users within the company asking how the department is doing. When all of the responses were received, the IS department threw out all of the bad responses. Then, to partially offset the obvious bias caused by doing that, they also threw out the “really” good responses. (I’m not sure what criteria they used to define “really” good.)

“Evidently this is the practice that they have been using with this survey for a number of years.

“When the company CEO asked the CIO about the results of the survey, the answer was: ‘We are above average. The results are really the same that they have been for the past few years.'”

In a person-to-person enterprise, the goal of end-user surveys is neither self-congratulation nor self-flagellation. Surveys are a tool for finding opportunities to help employees become more effective.

In the person-to-person enterprise, employee effectiveness is the name of the game.

How do you decide which books to buy and read?

These are two different decisions. Some books are ammunition. When you need support for a position that’s been challenged, books follow the Harvard Business Review and official-looking analyst reports, precede trade press articles, and are a parsec or two in front of facts and logic when it comes to persuasive power. Luckily, you don’t have to read most business books, which simply stretch a pamphlet’s worth of ideas into a thirty-buck purchase.

Then there’s Robert A. Lutz’s Guts. Guts has a lot of munitions value — since Lutz is the guy who turned Chrysler from the failing “K car” company into a powerhouse, his credentials are impeccable — but that’s not why you should buy it. This book is well worth reading.

Lutz may have been the most successful “change agent” in the history of business. He took a company run by “professional” businessmen for the sole purpose of making money and transformed it into a car company run by people enthusiastic about cars … and in the process turned it from a money-losing disaster into a high-growth success story.

Read the chapter about the Dodge Viper. Strict business analysis said the Viper made no sense: It could have no real impact on profits, and absorbed critical resources at a crucial time. Lutz, the president, persuaded Bob Eaton, the CEO, to build it anyway.

The Viper saved Chrysler. It transformed Chrysler’s image (upon seeing a prototype, some industry analysts actually handed Lutz large checks to reserve their own); it restored employee morale, and it completely changed how Chrysler designed cars and brought them to market.

Lutz describes Chrysler’s top-to-bottom transformation as “getting back to basics”. That’s what it was, too — through the Viper project, Lutz and Eaton got Chrysler back to the basics of being in the car business and loving it.

Any lessons for IT? Of course, if you know where to look. For example:

Chrysler turned itself around by putting “car people” back in charge. IT needs technology enthusiasts in charge. Sure, you need good business judgment. Lutz has excellent business judgment. But he’s a self-described car nut first.

Chrysler turned itself around by making cars designed by car enthusiasts, not focus groups. The best information systems are created by IT professionals who also understand how the system will be “driven”, designing something they’d enjoy “driving” themselves. No, they don’t ignore the end-user, any more than Chrysler ignored drivers. Great IT designers work with end-users to become end-users themselves as well as engineers.

Chrysler changed its design process from a series of hand-offs that led to extensive re-work to collaborative teams that included all areas of expertise needed to create a complete design. In contrast, lots of companies still organize their business change programs into separate “business” and “IT” projects, almost guaranteeing both conflict and incompatible business and technical designs.

Guts describes more than technique. First and foremost it’s a book about leadership, from a proven leader who clearly understands the subject in both theory and practice. Lutz eloquently presents the case that “managing change” is the definition of leadership, that courage is leadership’s core competency, and that leadership is both in-born and teachable. Guts can’t help you with the in-born part. But for the teachable aspects, you need it on your bookshelf.

After you’ve read it.