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.

I have, in my day, gone through lots of leadership training.

I’ve learned how to recognize excellent personal and team performance with recognition and a variety of financial and non-financial incentives. How to deal with difficult situations, like personal crises, policy violations, substandard performance, and terminations. How to facilitate meetings. Delegate tasks. Coach employees who make mistakes without demoralizing them.

Serious stuff.

I have to be fair. I’ve also received training in how to provide small rewards and incentives as morale-builders, such as T-shirts, pizza, or tickets to movies or plays. The small stuff is important in creating an atmosphere where good work and good attitude are appreciated.

But in all my training, I never once heard anyone talk about the single most common situation most managers have to deal with: Minor infractions.

I’m heartily sick of the phrase, “… potentially leading to termination.” Regular readers will recall an employee who received a one-week suspension without pay for sending a joke over his company’s e-mail. As Mom used to say, they made a federal case out of it.

Have you established techniques for dealing with minor infractions? Small stuff like lateness for meetings, dead-horse-beating in discussions, or slightly too long lunch breaks? It’s important to do so. If you let minor matters go unchallenged, they eventually grow into significant problems. On the other hand, if every time you see some trivial problem you call the offender into your office for a solemn conversation, you’ve established an image … as a pompous twit.

So if you can neither ignore the problem nor counsel the offender, what can you do?

I learned the answer the hard way. After a reorganization I walked into the weekly staff meeting of one of my new teams 5 minutes late. Another attendee, who’d apparently arrived 4 minutes late, breathed a sigh of relief and said, cheerily, “You bring the donuts next week!”

A front-line supervisor in a company with whom I’ve consulted has a similar strategy: When someone breaks the rules he holds a “kangaroo court” and when the accused is found guilty they impose the cookie penalty. You guessed it — the guilty party has to provide cookies for everyone.

Donuts or cookies, it was minor, good-natured, expected, and public. Since the penalty directly benefited the team it boosted morale in the bargain, even if it did harm the aorta a little bit. And these are the keys.

Keeping your penalties small emphasizes your own sense of perspective. Mom would have approved — no federal case.

Keeping the atmosphere good-natured reinforces the desirability of an open, casual environment where you don’t lead by intimidation.

Unlike rewards, where inventiveness is the key, minor penalties should establish a team tradition. Traditions are important in building teams, just as with any other kind of community.

It’s important to publicly razz the trouble-maker in this kind of situation. You get to make the point to everyone that whatever the behavior is, it isn’t appropriate. You again reinforce an open communications environment where nobody has to measure every word they speak.

It’s important for the penalty to benefit other team members, which is why desserts are such a great punishment, as is making the guilty party take notes at the next meeting. Since the offender does something good for teammates, the sentence amounts to community service and builds up the team (whereas each minor infraction incrementally damages team cohesiveness).

And although some companies (for example, those whose IT departments gripe about screen-savers) don’t seem to value it very much, you get to make the workplace just a wee bit more fun.

Maybe you’re the kind of sourpuss who doesn’t see the value of all this. If so, I have the perfect solution.

You get to bring the next plate of cookies.