Leaders Can Learn from Employees’ Vantage Point

AFTER A FEW MONTHS in my new position as director of software development at a midlevel ERP applications company, an amazing thing happened to me. I had run through all the classic management techniques of holding staff meetings and one-on-ones with my managers, maintaining an open-door policy and so on. I was comfortably ensconced in my cushy corner office, and my only major concern at the moment was the CEO’s total lack of technical knowledge. Then good fortune smiled on me, and the lights went out.

This is hardly the occurrence that most executive dreams are made of, but it brought me closer to my staff of 60 than anything else I could have imagined. When my office lost electricity and heat, I moved my PC and some paper files, had the phone extension switched and set up shop for two days next to one of our senior QA analysts.

What an experience! It had been 15 years since I was a cube dweller. We are all familiar with sending IT analysts out into the business units to experience “real life”?I now make the case that top-level managers need to climb into the trenches to experience real life too.

For all the CIOs and VPs out there this is going to be an eye-opening experience. Let me share my insights with you.

Hardware

I had a 19-inch monitor, and I used it mainly to read e-mail and access Microsoft Office. My programmers, on the other hand, had 14- or 15-inch monitors, and they needed to have multiple windows open at once for coding, debugging and documentation. No wonder they made typographical errors?they were continually misreading variable names or transcribing code incorrectly because their work area was too small. My PC, installed by the friendly IT manager on my first day, was the most powerful in the department. Company policy equated rank with CPU speed and disk capacity. My junior programmers had machines that barely did the job. Lesson: Just as I needed a big desk to function, they needed big screens and a powerful CPU.

Software

If the daily environment in which we place our staff does not reflect a commitment to quality, what right do we have to expect it in return? When crashing e-mail servers, network and printer outages, and the need to restart browsers and PCs throughout the day are standard operating practices, what are the realistic expectations for your staff to “get quality”? Lesson: If you expect quality output, give your staff quality tools.

Environment

The noise was unbelievable. Listening to my neighbor’s phone conversations as well as the din of ringing phones, the tip-tapping of keyboards and all of the other work-related (because the boss was around) conversations going on was amazingly distracting. Most of the staff claimed to be able to filter the noise out, but I wondered how much of their brainpower was going toward that instead of working. I also noticed that, despite having filters, many people had their monitors in strange locations because of the glare from overhead lighting. Programmers did not have enough space to store manuals, files and the other paperwork used by our paperless office. Chairs could not fit under desks, heating and ventilation were not uniform, and there was minimal natural light. Psychologists tell us we are all a product of our environment, and poor surroundings lead to poor work. Lesson: Your employees need a quality workplace that lets them perform quality tasks.

Location

The development and quality assurance departments at this organization had traditionally been physically segregated onto different floors. During my two-day exile into cubeland I noticed that many programmers were forced to make the two-minute trek to visit my QA neighbor. I also discovered that a huge number of e-mails were passing back and forth between programmers in adjacent cubes?causing the creation of “re: your code” e-mail threads 40 messages long?instead of actually having a conversation. Lesson: It’s not just executives who are stuck in their ways. Make communication a natural act.

What to Do?

The repetitive bleating of the CEO about the bug count led me to challenge him to put his money where his mouth was. Upon reflection, this is probably why I lost my job six months later.

After squeezing a few extra dollars out of him and my budget, I put all my proposals up on a big board outside my office so that my staff could measure how I was doing. We installed uniform versions of Microsoft Office, browsers, editors and other productivity tools. We implemented a purchasing program to upgrade old 14-inch monitors to 17- or 19-inch ones, and we upgraded the development machine and installed a new backup machine. We replaced chairs and repaired desks; we started a project to fix the lighting and air-conditioning; we rearranged some workstations; and we found more public meeting space. We also commingled the development and QA departments and saw a decrease in e-mail use, an increase in face-to-face communication and the formation of product teams on the fly. The big board was updated daily as the environment was gradually upgraded. Other departments started to come by and check it out.

The net result was a tenfold decrease in “dumb” coding and QA errors, a marked slowdown in turnover and a gradual decrease in the bug count. The ultimate measure of success was the huge spike in revenues and profits as our new products hit the street. Did I mention I lost my job? Our CEO of Very Little Brain never did come out of his office.