No, no, no. I wasn’t talking about Social Security and credit card numbers. It’s all the stuff companies claim is uniquely valuable, that has never occurred to competitors, and that would never occur to them unless and until someone sent them a PowerPoint deck.

Last week’s KJR made the case that most businesses have become so permeable that it’s a fact, not a problem, which means they have to deal with it, not solve it.

And further, that the best way to deal with permeability is to take advantage of it as a better path to profitability than trying to build ever-higher and thicker walls around the enterprise.

As all software testers know, good test plans include a plentiful portion of edge cases, so it isn’t surprising some correspondents expressed concern that KJR might take the position that corporations should relax their controls on information whose compromise could result in, for example, identity theft.

These edge cases are good tests, only not of the overall principle. Customer identification and privacy information? Protect it to the best of your ability. Short-term plans where whoever gets to market first wins big? Protect those to the best of your ability, too.

The process you use for purchase-order/invoice reconciliation, or, as Jimmy John’s notoriously seems to think needs protecting, for making a ham and cheese sandwich?

Uh … no.

As pointed out last week, many business theorists and leaders, for several decades now, have considered employees to be fungible commodities, to be traded into and out of the pool of available talent without compunction or regret.

But when they’re traded, they take their knowledge with them — an apparently unintended consequence of this employment philosophy.

Shared knowledge is at the heart of the Cognitive Enterprise. One consequence of replacing a long-term employee who has a vast fund of institutional knowledge is …

Well, it depends. If the employee’s replacement is quite a lot less experienced, or if there is no replacement, the enterprise’s total shared-knowledge account will have been diminished.

If, on the other hand, the business replaces the departing employee with one who has just as large a fund of institutional knowledge, or larger, only it’s a fund accumulated in different institutions, then the enterprise’s shared-knowledge account will increase.

It’s permeability in action, even without any electronic knowledge sharing. Imagine the company chart of accounts had a way to track shared knowledge. Think its executives might make different staffing decisions?

It would be an intriguing exercise in finance, figuring out how to tote up all of the valuable knowledge held in an organization. The trickiest part wouldn’t be how to put a number on it. Not that this would be easy, understand, but given how many non-disclosure agreements claim that revealing any of it would cause irreparable harm, you’d think someone would know how big a number “irreparable” is, at least approximately.

Not to keep you in suspense, here’s what would be the trickiest part: In a cognitive enterprise, knowledge is widely shared — it’s what the whole organization knows that counts, not just what an individual who works there knows.

Which gets to one of my own trade secrets, which I’m allowed to share with you because it was knowledge I had that preceded my joining Dell Services: No matter what the challenge or issue, there are employees who know all about it and what to do about it. Their problem, and one of my best ways of earning my keep as a consultant, is that until my team and I show up, nobody has any interest in what they have to say.

To be fair, after my teams and I show up and do listen to them, putting it all together into a nice, coherent narrative and plan, very often client leadership doesn’t want to hear it from us, either. It is, I guess, cognition prevention at the highest levels of leadership.

This is also why embracing permeability is a safe knowledge management tactic: If your company’s stuff makes it into, for example, a LinkedIn discussion forum where the employees of other companies read all about it, you have little to worry about.

The odds are long nobody will listen to them after your employees have made them smarter. If you’re smart, you won’t duplicate that mistake.

So stop trying to protect your own IP and learn from all those other folks who are sharing theirs.

Once more thing. If you think this week’s KJR is worth sharing, please do so. Just make sure to respect the copyright notice at the bottom when you do.

“Do the right thing” is to ethics as “best practice” is to business processes. They’re phrases that sound just like they might mean something.

Except that they don’t.

Case in point, based on a recent request for advice: You’re on a team. The team’s job is to figure out a better way for the company to do something or other.

In the early stages of analysis two alternatives came into focus as potential solutions. Neither was obviously wrong, but over time a team consensus has emerged as to which of the two was the better path forward.

When the time comes to report the preliminary solution to the project’s sponsor and steering committee, though, the project manager presents the other alternative. He’s completely within his authority. You and the rest of the team simply disagree with him.

The ethical question: You’re on the team. Your company’s Values Card makes it clear you’re supposed to do the right thing.

What, however, is this “right thing” you’re supposed to do?

The most obvious approach is to blow the whistle. That’ll show him.

And it might. Or it might not, but the telltale here is “that’ll show him.” Blowing the whistle might in fact be the right choice, but you’d have no way of knowing, because what you’d be doing is satisfying your urge to vent, not holding yourself to high ethical standards.

There is, after all, a reason mutiny on the high seas is frowned upon, even when the captain’s orders appear highly dubious to the crew. Blow the whistle and it won’t be just the project manager’s standing that is lowered in the eyes of the project sponsor — the entire team will look bad whether or not you persuade the sponsor to overrule the project manager.

Add to that the impact on ongoing team dynamics. Your ability to work with the project manager will be permanently impaired. So will your ability to work with many of the other members of the team, who, while on your side with respect to the design itself, disagree with your decision to escalate.

As an alternative to whistleblowing you might simply leave the team. Except, you can’t just leave the team. You’ll have to provide a reason, or perhaps three reasons — one for the project manager, one for your reporting manager, and one for your soon-to-be-erstwhile teammates.

For each audience you can either be honest about the reason or you can make up a plausible excuse. Plausible excuses being convenient falsehoods, this branch probably won’t survive ethical scrutiny, while honesty will result in everyone who knows about what’s going on concluding you’re a prima donna who bails whenever something doesn’t go your way.

So far, so bad: Two alternatives, two unsatisfactory outcomes.

Here’s another one: You can confront the project manager. “What the fleep do you think you were doing!?!?” you might calmly ask at the next team meeting, or, if you’re in the mood to be discreet, privately.

If the project manager were the sort to accept that he’d done something wrong, he wouldn’t have violated the team’s consensus in the first place. If you choose the public option the blow up you’ve just engineered will further damage the ability of the team to function. If you do this privately you’ll merely damage your ability to work effectively with the project manager.

Either way, you won’t change the outcome.

Hmmm.

Another possibility: You can accept the project manager’s decision and move on from there without comment. This avoids all the previous downsides. It does, on the other hand, encourage a repeat performance.

The point of this little tale of woe? It started as a what-do-you-think-I-should-do inquiry, and from that perspective my answer is simple: Keep your mouth shut and document the event. That way, if everything does fall apart as a result of the project manager’s poor choice, you have some hope of salvaging your own reputation.

But there’s a difference between doing what’s most prudent and taking the most ethical course of action.

Those who advocate doing the right thing generally imagine the main barrier standing in the way of right-thing-ness is fear of the personal consequences.

That may be so in some situations. But in just as many, to my way of counting, the biggest barrier isn’t timidity.

It’s the difficulty of figuring out just exactly what the right thing to do is.