As every programmer knows, God was able to make the world in only six days because he didn’t have an installed base. Programmers rarely have that luxury.

New managers have a different kind of installed base to worry about. While the difficulties they face are not as technically daunting as creating a backward-compatible operating system upgrade, the social engineering issues faced by a manager taking over an existing organization present their own set of significant challenges.

When you take over a department, whether it’s through a promotion or a job change, you don’t get the luxury of designing your operation from scratch. You’re inheriting an installed base — an existing team, well-worn processes and ways of doing things, and an entrenched culture. But where programmers usually have a test environment in which they can safely find and fix mistakes, managers have to do their testing in the production environment of an ongoing operation. Missteps are very public, and hard to unmake.

The social engineering starts before you take the job. If at all possible, find out whether you’re walking into a problem area or not. If it isn’t a problem area, try to get a mandate for change from the reporting manager to create a problem where none existed before. Failing that, let some other victim take this no-win job.

Coming into a smoothly running organization is much harder than taking over a disaster area. How are you to succeed? Your chances of further improving the situation and having the team look to you for leadership are low. If your charter is to maintain the status quo, your predecessor will get the credit if you succeed; you’ll get the blame for any deterioration.

Compare this to the desk o’ death. The department is in shambles. The team is demoralized, productivity is low, waste is high, service levels aren’t. Whenever possible, choose the desk of death, especially if you’re the third or fourth manager to get the job — expectations will be so low that your success is virtually guaranteed.

So long as you follow a few simple rules.

The first is to keep your yap shut. Beyond the usual pleasantries of how delighted you are to have the opportunity, say as little as you can. Listen to everyone, in group settings and one-on-one. Neither agree nor disagree with anything beyond broad philosophical concepts, and above all, don’t choose sides or make any commitments. Offer no ideas of your own. Listen and make note of who says what.

In a desk o’ death, everyone has a private agenda and is trying to recruit you. Assume everything you’re told is biased. You have to piece together an accurate assessment jigsaw puzzle fashion out of bits and pieces. The moment you accept any individual as a preferred or unquestioned source of information, you lose your ability to lead — your preferred source will have established his perspective as your own.

So the first rule is to take time to size up the situation. Then you can decide what needs to be changed — processes, technology, reporting relationships, team members (chances are, if it’s the desk o’ death not everyone is a great employee), attitudes, or what have you. And, you can choose your priorities.

That’s the first rule. The second will have to wait until next week.

Until then, trust nobody.

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.