All Posts in Organizational Effectiveness

|In: Leadership|Last Updated:

A few columns ago I mentioned a science fiction story titled “The Political Engineer” and asked if anyone remembered the authors. Patrick Berry remembered reading it in an anthology of stories by Cyril Kornbluth and Frederik Pohl titled Critical Mass.

Thanks, Patrick.

Lots of IS Survivalists expressed their appreciation for that column. Many see themselves as apolitical engineers treated poorly by politicized corporate cultures. So here’s a question: What are you going to do about it?

You have three choices: leave, learn enough about corporate politics to avoid being victimized, or suffer. Pick one.

The problem my correspondents described — nontechnical managers making technical decisions without involving the engineers — has nothing to do with politics, though. Not the good kind (figuring out how to move forward when legitimately different points of view collide) nor the bad (back-stabbing and hidden agendas).

While it may seem to be politics, the problem is our natural tendency, as human beings, to trust and associate with those most like us. It’s a lack of appreciation for diversity.

Think of the executive ranks of your company. Can you think of anyone who’s there without any visible achievements that seem to warrant it? Think about the fast-trackers who aren’t executives, but who obviously will be. What is it about them that makes them fast-trackers? Ability? Maybe.

In many businesses there’s a sort of executive club. Some people belong to it. Others don’t. Its members can spot each other from a distance and say, “Yes, he’s one of us.” Nonmembers mistakenly call it the old boys’ network, but it’s nothing of the kind. It’s a club and you’re either a member or you’re not.

It’s depressingly like a high school clique, where you know who’s in it and you know you’re not. I suspect sociologists have written oodles of research papers on this subject (if not, it’s fertile soil for some Ph.D. candidate) but we don’t need research papers. We need a manual. Nobody has ever written a step-by-step instruction manual for joining the clique. (Memo to IDG Books: Publish Joining Cliques for Dummies.)

That’s why so much of today’s diversity training is completely ineffectual. While discrimination based on race and ethnicity still happens (and is inexcusable) far more comes from distrusting people with different thought patterns than skin color. As a friend put it, lots of companies hire and promote people of all races, creeds and backgrounds, as long as they think alike. Real diversity comes from differing points of view, perspectives, priorities, and values. Valuing real diversity is the antithesis of being part of the clique.

Did I say “the clique”? I meant “a clique,” because there’s more than one. Techies have cliques, too. So do most other identifiable groups. If you’re part of a clique, you probably don’t even recognize it. That changes nothing.

How well do you look at the world from the other person’s perspective when the other person doesn’t think the way you do? Do you try to see the world through her eyes, or do you take the easy way out, applying a convenient label that trivializes or demonizes a perspective that makes you uncomfortable?

“Aw, that’s just politics!” means, “You didn’t make this decision the way I would have,” just as much as “They’re just techies — they don’t think the way we do” does.

It’s time for all of us to appreciate real diversity — and that means listening to those least like ourselves, discovering how it is they perceive the world.

After all, listening to members of your own groups is a whole lot like listening to yourself.

How much will you learn doing that?

Comments

|In: Organizational Effectiveness|Last Updated:

Some ideas pop up in every culture.

An old Islamic proverb advises you to “Trust in Allah, but tie your camel.” Former President Reagan translated the Russian version — “Trust but verify.”

And we chip-heads have extranets.

I gave my first speech about extranets to the Minnesota Telecommunications Association in 1993, not that I was smart enough to coin the term.

It was a simpleminded speech. The World Wide Web was just getting started, e-mail gateways were expensive and unreliable, and the office suite wars were still raging with no clear winner yet in sight. So I guessed wrong on many of the specifics. The key point was right, though. IT’s focus was typically internal — on WANs, which improved communications with ourselves, not on ways to improve communications with customers.

An extranet is a private network connection between two or more companies built around standard Internet technologies. I’ve recently moved from speechifying to setting one up, finding out first-hand that successful extranets have some tricky, trust-but-verify-related design issues. For example:

Security policy: Does yours describe the level of trust you assign to your customers’ employees? You can’t toss this problem over the transom to your security group either: Their job is to implement your security policy, not to create it.

Firewalls: You need one per company, of course, not a particularly sophisticated insight by itself. Each company needs to protect its network from its trusted partners. Don’t, by the way, economize by using the same firewall for your Internet and extranet connections. Each implements a different security policy. Internet users are total strangers. Presumably you trust extranet users more.

Authentication servers: If an extranet is a good idea for one customer it’s a good idea for lots of them. And once you’ve established an extranet connection to two customers, you’ve connected their networks to each other. They may even be competitors.

Authentication servers restrict the use of extranet connections to trusted individuals, protecting your customers from each other. A key point here: Your role is to encourage your customers to implement this technology. They each have to install and administer it. Otherwise you’ve taken ownership of their network security, along with the liability if something goes wrong.

In the Fun-You-Don’t-Need department, think about compatibility testing. Authentication servers require client software on every system that accesses the extranet. Different customers may choose different authentication servers.

Server ownership: In some cases this is a non-issue. What if you’re running a joint project, though? Like a lot of issues, this one’s easy to resolve if you remember it. One company or the other owns and administers the server and puts it inside their firewall.

Mobile users: This is the toughest design issue your network engineers face. When you’ve established a joint project team and a customer’s team comes to visit, you should be able to provide desks and network connections. They should be able to work without right-clicking on Network Neighborhood to reconfigure their IP settings.

Problem resolution: Don’t forget this one. Although every device on your extranet may be fully managed, the end-to-end connection is not. When something fails, nobody knows whose device is at fault. You’ll need reporting and escalation procedures. Probably, each company’s employees will call their own help desks. Instead of pointing fingers at each other, the help desks will work together to solve the problems.

And last but by no means least: Make sure everyone involved knows why you’re doing this. “Improving communications with our customers” sounds really great, but as Gertrude Stein said about Oakland, there’s no there there. If you think through the tangible benefits up front, everyone involved will know what they’re trying to accomplish.

Comments