Relationship Building is a Process, Not an Isolated Task

Dan Goldstein ”who rose, without any formal education in programming, from a $58-a-week job (in 1964) wiring control panels for

IBM accounting machines to a high rank in IT management ”also stresses communication and respect when dealing with an end user . Dan, now retired , spent his last twenty-seven IT years with a large manufacturing company as the data processing manager.

He notes: In that job I got to install and support several computers in widespread locations in the States and in the Caribbean. I got to hire and work with programmers and to work directly with the company owners . I tried to hire programmers with skill, but also with a personality that let them relate to and communicate well with end users and with management.

In the early days, I was a one-man shop ”programmer, DP manager, systems person, and sometimes operator when the operator was out, Dan says. But that meant that I got to understand the entire application. For instance, when I had to put in a cutting-room incentive payroll, I had to know what a cutting room was (where stacks of clothing fabric were manually cut into clothing parts ) and know what the cutters did.

Today, programming seems to me to be segmented, and the programmer only knows a tiny piece of applications. Companies seem to want programmers to sit in an office rather than go out into the company. I made it clear that IT was a service department. I knew the name of every person in the company that I worked with, including the factory employees . But in my last job, the new middle managers who came in made it clear to me that they thought I was spending too much time working with the end users ”I should be sitting in an office instead, writing code to implement processes that I hadn t observed . That s the idea today, and it s ridiculously counterproductive; that s why programmers today can t see the forest for the trees.

Having rapport with users, building their trust, means that the end users don t feel as if IT is shoving something down their throats, Dan says. That matters, because if the users don t buy into something you re introducing, it is not going to work. They can make or break any system.

The power of the computer today is immense, and the younger programmers use lots of fancy op codes, but they really don t know what is going on inside the CPU. You could say, ˜Set up a system, and they wouldn t know where to begin in setting up the databases, master files, and integrated systems for a major application. That is primarily because they are not involved with the end users. They don t know the jobs of the end users, so they can t see how all those jobs integrate to get the job done in the company.

You have to understand your business and be willing to work respectfully with your end users. In my opinion, anything less creates mistrust , and that is a disaster in the making.

$$ The Bottom Line $$

When you got your first programming job, it was all you could do to learn the ropes . Now that you are more experienced , your boss should (and, if you re lucky, will) expect you to interact with end users. Use the tips in this chapter to make your interactions with end users professional and productive.