Hackers and Suits: 10 Tips for Managers to Bridge the Gap

There is a Great Divide in the realm of information technology. I’m not talking about Windows versus Linux or Java versus .NET—no, nothing like that. The gap I’m referring to is between software developers and the people who manage them—what I call hackers and suits.

Let’s clarify one thing first: The word hacker is used in at least three senses. There is the Hollywood sense of a kind of “digital burglar” (more properly called a cracker); there is the sense of a person who throws software together quickly and without skill or caution; and finally there is the “true” sense of the word: a craftsman who is a master at what he does, knowledgeable and capable.

It’s the third sense I’m concerned with here. If you’re unfamiliar with this usage, refer to the Jargon File or even better, read Paul Graham’s excellent essay “Hackers and Painters.”

MORE ON DEVELOPERS AND MANAGERS

Geek Bonding

Top Questions a CIO Should Ask about Software

Sign up for our Development/

And what is a “suit”? Well, if you don’t know what one is, you might be one. The term is common (though not universal) slang for a manager—deriving, of course, from the contrast in dress code. In many or most firms, developers are permitted to dress casually. Managers tend to wear suits—in some cases even appearing to like wearing them—and this sometimes puts developers on their guard.

This article has been difficult to write; it is not dispassionate or unbiased. I am a senior developer with no management background, which places me firmly in one camp. But honesty compels me to admit that neither side is wholly right or wholly wrong in its attitudes. There are certainly things that hackers can learn from suits, and vice versa. The gap can be bridged—has to be bridged—if a department is to run smoothly.

The other reason for my difficulty is that I am writing for the other group—the one to which I don’t belong. But bear with me, and I will try to be fair.

First of all, it helps to understand where the hacker is coming from. Software is a strange thing—it is abstract and malleable since it is written in some kind of language—but it is also like a machine in that it has to be precisely correct and has to function properly. Software development is a hard skill to acquire, and mastering it often gives the practitioner a kind of tunnel vision. The hacker may worry about many aspects of his code, such as readability, portability, maintainability and performance; but his code is basically his world.

The average hacker has no business sense. He isn’t even aware that he lacks one. His world is megabytes and milliseconds, not dollars and cents. He likely has never had a management course—perhaps has never had any kind of business course whatsoever. He evaluates things by their performance and their technical excellence. He may tend to overlook the user; usability and user-friendliness, good online help and good documentation are not usually highest on his list of priorities. Even farther over his horizon is “the bottom line” itself. He is buried so far in the internals that he is unaware of any positive or negative economic impact his actions have.

So here is Tip 1: Remind the developer that technical excellence is no guarantee of success. In fact, sometimes they’re hardly even correlated. History is littered with examples of superior products that failed for various reasons: bad timing, bad marketing or one crucial design flaw. These range from the Tucker automobile of the 1940s to the BeOS operating system of the 1990s. There is a good reason that betamax is often lowercased and used as a verb. Developers can understand this if they are reminded.

Tip 2 is directly related. Point out the economic impact when you can, and be as specific as possible. If a developer wants to slip the schedule by a month to add a feature he considers important, bring money into the equation. Talk about revenue lost to a competitor who reaches market first. Talk about how many sales might be made in that extra month. Ask the developer to evaluate the situation in light of those facts. (Of course, he may still disagree; but you’re still the manager.)

And, of course, disagreements do happen. Either side may be wrong in a given situation. But good two-way communication can mitigate the conflict. If a developer is balking at following your course of action, don’t dismiss his opinion immediately—he’s a professional in his field just as you are. Don’t be a dictator. Tip 3: Explore the developer’s specific reasons for disagreeing, because they may be valid. And Tip 4 is the flip side: Explain the constraints and the assumptions you are working under and the reasons for your decisions; if you must overrule a developer’s opinion, at least give some justification for it.

I was once in a sticky situation. A coworker without all the facts at his disposal made a recommendation to my manager—a suggestion that seemed innocent and reasonable. But I knew that the course of action that would save us four hours that week would come back to haunt our nightmares for weeks to come. What saved time in the short term would have cost us 20 times as much in the midterm.

The temptation some people would face is to fly off the handle—to call the coworker and/or the boss an idiot, to get angry, to flatly refuse to comply. Too many developers, I admit, have egos the size of Kansas. Truthfully, I wasn’t thrilled with the situation, but I knew that playing prima donna is never the answer. I took a deep breath and crafted a long and unemotional e-mail message to my boss, and filled it with as many cold, hard facts as I could. “This sounds like a good idea,” I said, “but it is really a very bad one.” And I went on to list 14 specific reasons why it was bad.

His e-mail response was only four words: “Do it your way.” When developers are reasonable, managers are often reasonable, too; and vice versa. Communication is the key.

Of course—forgive me for stating the obvious—communication is possible only if the parties speak a common language. And that’s often not the case with these two groups. Tip 5: If your company pays for courses and seminars, encourage the developers to do some management-related studies. If you’re lucky, that will open their eyes. And likewise—Tip 6—it doesn’t hurt you as a manager to do some studying at a more technical level. You can’t match the expertise of someone who spends all of his or her time buried in those details—but you can at least try to stay somewhat current. But Tip 7 is very important: Never fake it! Honest ignorance is always better than pretending knowledge.

The larger your company, the more bureaucracy it probably has, and the more “process” or red tape—”administrivia,” as some call it. This is the bane of the developer’s existence. There are few things a software person hates more than to be pulled away from “real work” to fill out useless forms or to attend seemingly irrelevant meetings where nothing is decided or accomplished. I vividly remember a coworker’s comment from years ago. “The product of the process isn’t code,” he said. “The product of the process is more process.”

The process exists for the company, not the company for the process. It’s necessary to follow rules and procedures, but don’t be a slave to them. Tip 8: Shield your developers from bureaucracy and red tape as much as possible. They will appreciate it, they will respect you more and they will be more productive.

In fact, I would go so far as to say (as Tip 9): Help streamline the process, even help short-circuit it, if it helps productivity. Do all your developers really need to track their time in 15-minute increments? Do they really need to fill out a three-page status report every week, adhering to a rigid template? If these things contribute to the bottom line, then keep them; if not, silently look the other way while these things get shoved to one side.

And Tip 10? Read Dilbert, of course. Don’t be surprised to see some people you know in that strip: people who work under you, over you, and around you. It’s not a real portrayal of corporate life, of course…but it is corporate life held under a magnifying glass. Look past the exaggeration, and you’ll see reality. Learn from it.

Now, having said that…. Software developers don’t appreciate their managers enough. I admit it. They have much to learn about the difficulty of “steering” a company and the essential roles that managers perform. But speaking as a developer, I know the reverse is also true: Managers don’t appreciate their developers—the difficulty of their tasks, the expertise they wield, or the constraints they have to deal with.

But my real message is, it doesn’t have to be this way. The gap can be bridged, and the two groups can work together. Honestly—can’t we all just get along?

Hal Fulton is the author of The Ruby Way, now in its expanded second edition. He was one of the early adopters of Ruby in the United States, having started to learn it in 1999. Fulton has two degrees in computer science and 20 years in the industry, including several years of teaching experience. He lives in Austin, Texas.

The rest of the story: Fulton is roommates with a cat with the suitably droll name of Meg, short for Megabyte. He is a direct descendant of the first man ever to lock his keys in his car. His short stories have been rejected by some of the finest magazines in the country. On rare occasions he plays chess and piano, both incredibly badly. He spends his spare time putting Slinkys on escalators and passing counterfeit bills to homeless people.