Near the end of my home remodeling adventure, when my wife and I had had quite enough dust and debris, the subcontractor responsible for laying the carpet failed to show up as scheduled. Apologies were issued, new commitments were made. Then he failed to show up again. This went on for nearly a month (carpet layers being in high demand, apparently). It was frustrating, but would have been much worse if we had to deal with it ourselves. Instead, we had a channel for all that frustration: our general contractor. He was our complaint department, our liaison, our punching bag; he took responsibility for the people he had trusted to get the work done. And he knew he wouldn’t get paid until the carpet was laid.

Most IT departments would benefit from a general contractor, a user liaison who is tasked with keeping users up-to-date until a problem is solved. Your general contractor should speak in a language the user can understand. Telling a frustrated worker “the F5 switch isn’t distributing the load properly” means nothing – in fact, the jargon only frustrates users further. Saying “there’s a problem with the network, and the proper people are working on it” is more than adequate, and all most people want to hear.

The general contractor can serve not only as a user liaison, but also as a referee. It’s not unusual for internal IT squabbling to hinder the troubleshooting process: Your DBA insists the database is functioning fine and the problem must be network traffic; the network administrator sees plenty of bandwidth latency and insists the application has a slow memory leak; your developers insist the application is handling memory just fine and insist the database isn’t indexed effectively. And on and on.