All Posts in Policies and Procedures

|In: Leadership|Last Updated:

Do you believe in astrology?

Me neither. Still, a few years ago when I worked in product development for awhile, my boss and I regularly finished each others’ sentences. The rapport was immediate and strong.

The weirdest moment of this relationship came when our whole team took a personality inventory. When they were scored, I grabbed our profiles and held the graphs up to the light. They were perfect overlays.

Here’s the weird part: Fred was born just one week before me. Happy birthday, Fred.

Our mutual personality profile hit the target. The evaluator explained that people like us have no trouble with well-defined procedures. As long as we are the authors, that is. Otherwise …

Which may be why I flinch whenever I read about organizational maturity models, the need for clear procedures, and the importance of repeatable, predictable results. It’s the words. We need to give this idea to marketing for a complete makeover. Do you want to be repeatable and predictable? Sounds awfully dull, doesn’t it?

Don’t get me wrong. Manufacturing systems (and any system that produces large numbers of the same kind of item is a manufacturing system) had better produce repeatable, predictable results. I, for one, want every pill in my Exedrin bottle to have exactly the same contents as every other pill.

Data center operations fits the manufacturing model very well, too. If your data center doesn’t run by well-defined and documented procedures, you probably have a pretty big mess on your hands.

Systems development is a different animal. Don’t blindly apply a manufacturing metaphor to it: the fit is less than perfect, which is one reason programmers commonly rebel when managers try to institute quality initiatives. The best programmers are creative sorts, and when you use words like “repeatable and predictable” to them, they have an immediate, gut-level reaction.

To these folks … and they’re usually the ones you depend on the most … a focus on process and procedures sounds a lot like premature embalming.

Here’s the dilemma: we already make too big a fuss about designing a database, some screens, and a bunch of reports. You’d think that by now we’d be good at it, but development projects still go in the tank more often than not. One of the many reasons: We think of every new project as something new and unique, instead of it being just one more database, a bunch of screens, and some more reports. In other words … it’s the same old stuff, so we ought to be able to establish a repeatable, predictable practice. Sigh.

There is a sweet spot in the middle of these positions. That’s the difference between understanding current best practice and slavishly adhering to one-size-fits-all procedures.

So welcome to the magic boundary separating professionalism from bureaucracy. Professionalism includes an understanding of best practices. Bureaucracy means a shift of power from people to rules. And once you transfer power from people to rules, you’ve begun to slide from performance to mediocrity.

Sure, you need to organize people into processes and services. But when you do, define “process” as “here’s our current procedure, which we’re always ready to dump in favor of a better one, or ignore when it doesn’t fit the circumstances.”

Dale Dauten, who writes the syndicated “Corporate Curmudgeon” feature, once wrote that companies start by having “… a leader, employees who think they’re important because they are, and customers who think they’re important because they are.”

Companies lose their souls when leaders become managers, putting their faith in rules and procedures instead of employees who are important. Make rules and procedures … repeatable, predictable results … means to an important goal. Ask employees to focus on that goal. Employees should use procedures when they make sense, and their creativity and judgment when those make sense.

Which, of course, is always.

Comments

|In: Industry Commentary|Last Updated:

If you blow enough smoke, you’ll convince a lot of people there’s a fire somewhere.

Last year, Bob Metcalfe and other pundits predicted the imminent collapse of the Internet. I, on the other hand, courageously predicted its non-collapse, and even more courageously endorsed the free-market economic model on which it is based.

The collapse contingent cites big outages last year, especially at Netcom and AOL, as evidence of the coming collapse. Their recommendation: throw a big party for the Internet’s inventors, thank them, shake their hands, and send them home so professionals can take over the job, replacing the current “anarchy” with modern central administration.

Here’s where I get lost. Netcom and AOL are private corporations operating centrally planned and administered networks. Both suffered big, noisy, noticeable outages. So to save the Internet from collapse, we want to centrally plan and administer it?

What am I missing? Most Americans think communism collapsed because big, centrally planned and managed economies don’t work. Most Americans are right. The Internet’s stability comes from its decentralized model. Rules are established centrally and kept simple – hence “Simple Network Management Protocol (SNMP) and “Simple Mail Transport Protocol” (SMTP) – while implementation of the rules is decentralized.

(One other problem with the proposed solution: there are no other professionals to call in. Only the Internet’s designers and implementers have experience in designing, building and running a successful, global network that links millions of independent computers. Who else are you gonna call?)

Despite all this enjoyable gloating, I give Dr. Metcalfe a lot of credit for sticking his neck way out, and for making a self-preventing prophesy. When disaster fails to strike, very few people give credit to those who sounded the alarm. I wonder how much of last year’s investment in Internet capacity resulted from the publicity attending Bob’s predictions.

Any lessons for you in all this? Ya, you betcha, as we say in Minnesota. The Internet’s successful use of centralized rule-making and decentralized implementation, far from being anarchic, gives you a wonderful model for organizational design.

Awhile back one of my readers sent me Sahakian’s Rules (Corporate Partnering Institute, Skokie, IL, 1995). It’s worth buying. One entry: “In ancient times, in order to manage large masses of people in the battlefield, Commanders used gongs, banners and horns. If a plan of battle was not simple enough to communicate with gongs, banners, or horns, it was a bad battle plan.”

Manage your organization like the Internet, or like a Commander on an ancient battlefield: with simple, easily communicated rules, not close, central supervision.

One other useful lesson: when you manage, ignore currently fashionable theories, especially those that demonize some group that Isn’t You. The idea that current Internet management doesn’t hack it anymore comes from one such notion that I call the BIG/GAS theory (for “Business Is Great/Government and Academics are Stupid”).

Yes, you can certainly find waste in government. Some comes from its sheer size, more comes from having lawyers (most of Congress) designing work processes, and much of the rest is unavoidable. (The military, for example, is staffed to conduct wars. When there’s no war, it’s over-staffed. Big deal.)

While government isn’t as good as it could be, the Internet’s history proves that BIG/GAS is just … vapor. In the 1960s visionaries in the academic and defense community created it. It’s been an international reality for decades.

In the 1980s the Graphic Communications Association (where, coincidentally, I worked for a few years) began creating the Standard Generalized Markup Language (SGML). Commercial publishers ignored it; the defense community embraced it as part of its Computer Aided Logistics System (CALS). Early in this decade, Tim Berners-Lee, working at CERN (the international particle physics laboratory) adapted SGML to invented the HyperText Markup Language (HTML).

And business finally caught on three years ago. BIG/GAS indeed.

Comments