In a scene in the 1976 movie “All the President’s Men,” senior editors of the Washington Post questioned the paper’s coverage of the Watergate break-in: If the Watergate story is so important, they asked, why aren’t other newspapers covering it? And why is it in the hands of Bob Woodward and Carl Bernstein, a couple of junior reporters? There are lots of senior political reporters, seasoned veterans, sitting around. One of them could wrap up this Watergate nonsense in no time, they argued.
Exactly, replied one editor. The seasoned reporters were sitting around.
The implication is clear: Had the Watergate story been in the hands of some sage veteran, it wouldn’t have gone the distance, and Richard Nixon would have flashed his victory sign over America’s Bicentennial celebration. Woodward and Bernstein were “hungry,” and they did what was needed to get the story.
This isn’t to imply that your senior developers are just sitting around, or that you need to place the fate of your current project in the hands of your most inexperienced programmers. But the management lessons at work in “All the President’s Men” can work in development, too. Be willing to go in a new and perhaps unlikely direction, even when your peers won’t; dig far below the official documentation in search of solutions; and—perhaps most importantly—cultivate your own “Deep Throat,” a quiet voice in the user community you can go to for inspiration and insight into what’s really going on.
Nobody else does it that way
One of the worst reasons to dismiss an approach to a project is because “nobody else does it that way.” Conformity is certainly the mortal enemy of innovation, and standards can blunt the imagination when it comes to solving problems. Is this better than the “anything goes” world of development in the early years of IT, before common tools and standards? It depends on whether you’re a manager facing a common problem or one that doesn’t have a standard solution.
Back in the early days of Windows, I rode shotgun as a user-community liaison to a development team facing a terrible dilemma. The team needed to deliver an order/inventory package that could compete in a niche industry with the new user-friendly, GUI-based packages. This team had little money and no experience whatsoever with Windows or GUI.
I wish I could take credit for their solution, because it was brilliant. They concluded, and I observed it to be true, that the end user—generally a modestly educated operator riding a constantly ringing telephone—had a single criterion for ease of use: speed.
The team wrote a system that used a single assembler routine for direct-to-disk read/write, eliminating the need for any database interface software. With simple DOS screens, data efficiently crammed to the bolts on the hard drive, and the lightning speed of the I/O routine, they put a system in the field that pleased the users far more than all of Windows’ ungainly bells and whistles. The system was unbelievably fast; the available information was complete; and harried users found themselves the envy of their community, with a reputation for quick and thorough responses.
The lesson is clear: Don’t worry about what the other papers are printing. Go where your story is.
Keep digging for a solution
Same situation, different company—only five years earlier, before PCs made it onto everyone’s desk: The user in this case was one of an army, sitting next to a video terminal and a telephone, calling up delivery schedules or shipping manifests (often both) as the voice on the other end of the phone required. Unfortunately, the warehousing database that provided the manifests and the scheduling system that marked the progress of delivery were completely separate systems. The users had to leave one system and go into the other to provide complete information—and they howled about it.
I didn’t come up with this one, either—I was just a bystander—but it was a sweet solution. The documentation said it couldn’t be done, short of redesigning the screens and database read routines. But one of the programmers must have failed to read that documentation. He discovered that, once a database read routine was called from either program—this all occurred on a mainframe, remember—he could create a kind of “hot link” from one system to the other. You could momentarily bounce out of whichever system you were in and bounce right back, without really leaving. For the users, it was a simple stroke of a key—and their telephone time was cut in half.
Official statements only say so much—always go to the source for the real story. Be willing to go beyond what you see in print and dig up some real information.
Trust your source
Woodward and Bernstein changed the face of American journalism with their Watergate coverage. But they freely acknowledge that they couldn’t have completed the story without the view from the inside provided by their anonymous source, “Deep Throat,” who would only meet them in a parking garage in the dead of night. To this day, Deep Throat’s identity remains a mystery, but the role he played is abundantly clear: He gave Woodward and Bernstein the clues they needed to bring together all the separate pieces of their work and form a coherent picture of what was really going on.
In your role as manager, you’re a bit removed from the day-to-day user by a hierarchy, even in a “flat” organization. But you may not realize you’re more isolated still by the procedures that your own people employ to draw functional information from those users.
Consider that, more often than not, “analysis” consists of having one of your people interview or sit with the user while the user does a job. This is great for gathering and improving upon procedural minutiae. But do you really think you’ll get the big picture this way? And don’t haul out the high-level oratory written by the users’ department head: You’ll have the same problem from the other direction.
The user level is the place where things happen, but you need to know what users really think, and you need to get it in a “parking garage,” a place where they’ll speak freely. Cross a social boundary or two and introduce yourself in the hallway or cafeteria. To break the ice, ask how a new system or module is working. Cultivate an environment of friendly, informal exchange and show a genuine interest. You run the risk that these people might occasionally jump the Help Desk and bother you with some problem that isn’t yours to own, but that’s a small price to pay for the inside scoop on where the bottlenecks in distribution really are, or why there are so many billing errors, or how a junior clerk figured out how to reduce inventory shortages.
The legacy of the well informed
Whether you’re unseating a president or an outdated system, the enabling step is to be as well informed as you possibly can. In the IT domain, a manager’s legacy is the efficiency and ultimate effectiveness of the change he orchestrates. Going all out to gather the necessary background information for your project—through unconventional methods, obscure documentation, and lowly end users—will give you the edge in delivering project successes that make history.
Tapping into the source
How do you get the information you need? Post a comment below or send us an e-mail.