Too Many Different Kinds of Things

My favorite piece of advice for aspiring managers has always been, “Never admit that you know how to clear a jam in a photocopier.” It's something that invites even the lowliest employee to delegate grunt work to you.

It's perfectly logical, but I always enjoyed clearing my own jams, and creating my own spreadsheets, databases, and websites. When a new piece of software or hardware came into the workplace I'd always curl up with the manual until I mastered it. When a new programming language came out, I'd buy some books and take them with me camping on an isolated stretch of the Rogue River or at the fire tower overlooking the Three Sisters in central Oregon. I found it an exciting union of technology and nature.

But as time passed, my non-technical job responsibilities grew and new hardware and software started coming out faster than I could learn it; printed manuals disappeared, and instructions started being given in pay-to-play “webinars” -- a bastard of a word if ever there was one. Still, I hate not knowing how to take something apart and put it back together – at least in theory.

I remember attending a panel discussion where several great minds debated the relative merits of scientists having broad general knowledge versus in-depth command of a narrow area of study. The moment in that discussion which stands out in my memory came when one of the participants quoted a British academic chiding a confused colleague by saying, “The trouble with you sir, is you know too many different kinds of the things.”

The trouble with having too much technical knowledge is that it's tempting to spend your time clearing jams in copy machines instead of creating content, programming spreadsheets instead of running a business, or learning a new computing device instead of writing the great American novel. 

When I had a business that created custom software, I found that the hardest part wasn't writing the program, it was figuring out what the client wanted to do. It wasn't unusual to be in the initial meeting and have someone say, “What we need is a form with two drop-down boxes, a set of check boxes and a button . . .”

After the fourth or fifth time I confronted that kind of thing I started interrupting with, “Before we start talking how we're going to feed this thing, tell me what you want to come out of its ass end.” Often, it would take hours to figure out what the client really wanted, because they had been so focused on the tools rather than tasks.

If I had to divide people into two categories I would say there are: (1) Technicians – people who are fascinated with tools, and (2) Architects – people with a vision that cannot become reality without the use of tools. (There are also politicians, but I'll deal with them another time.)

Technicians always have the coolest toys and the best home entertainment centers, but most people's eyes glaze over as soon as they start talking.

Architects tend to do well at cocktail parties, but you can't sleep in a castle built of dreams.

The real danger of being too much the architect and too little the technician is falling prey to technicians who believe their ability to control the plumbing is a license to control the creative forces in society.

Several years ago I had a client who returned from a professional association conference with the pronouncement, “I'm convinced that within five years our whole business will be Internet-driven.”

I asked, “So what's driving it now? Telephones? Fax Machines?”

The Internet is, of course, just a data delivery system. Like airports and highways, it enables things to move around, but doesn't drive anything.

A pure technician sees a tool and looks for a problem it can solve. The danger in that is, as psychologist Abraham Maslow observed, “If the only thing in your toolbox is a hammer, everything looks like a nail.”

A pure architects sees a problem, thinks up a solution, then tries to find tools that will fit the solution. Architects and technicians need each other, but while an architect's hands may be on the steering wheel, technicians control the throttle and the brakes.

To offer a first-hand example: In the county government I work for there's an ongoing struggle for control of the budget between the elected official that controls the accounting software that holds the budget data and the appointed official to whom the county charter delegates responsibility for making budget decisions.

The appointed official can hold his breath until he turns blue, but nothing gets entered into the budget program until the independent department head approves. The result has been the creation of a parallel budgeting system – which, of course – adds another technical gatekeeper into mix.

How does one find a balance between the dreamers and the keepers of the tools?

Please don't look to me for an easy answer. I'm afraid that I know too many different kinds of things.