Let’s clear something up: Submitting a ManagementSpeak to KJR isn’t whistleblowing. What the two have in common: If the manager you’re quoting catches on and figures out you were the source, you might be in for some personal discomfort.

What they don’t have in common: Congress has passed no laws protecting ManagementSpeak submitters from retaliation.

Send in what you hear anyway.

Speaking of whistleblowers, the estimable Randy Cassingham, who also writes and publishes This is Truea weekly compendium of strange happenings from headlines around the world — told of the recently deceased Shuping Wang in his Honorary Unsubscribe.

In the 1990s, Wang discovered that the Chinese government’s methods for managing its blood supply promoted the spread of blood-borne pathogens; her tests showed contamination rates of 83% for Hepatitis C alone.

Wang attempted to bring the problem to the attention of her management, and when that had no impact tried jumping a level, with predictable results: Dr. Wang’s research was stopped and one official bashed both her and her equipment with a club.

If you’re interested in the full story I encourage you to click the link. If you’re interested in how it relates to you and the organization you work in, read on.

In your career, you’ll run across all sorts of, shall we say, opportunities to improve how things get done around here. Not improving how you and your organization do things, but how other managers and their organizations do whatever they do to accomplish whatever they’re supposed to accomplish.

Some of these will be true opportunities. But some might be opportunities in the sense of the drivelous “there’s no such thing as a problem, only an opportunity.”

The problems probably won’t be as dire as actively spreading fatal diseases. So let’s be less dramatic about it and imagine you’ve discovered a data breach. It hasn’t exposed millions of customers’ credit card information yet … just a few thousand thus far … but the risk of larger losses is, in your estimation, quite real.

You figure your employer will want to eliminate this risk, so you send an email to the managers in the company’s org chart most likely to be in a position to do so, explaining the breach, its root cause, and suggestions as to what a solution might look like.

And … nothing happens, other than your receiving a pro forma email thanking you for being so conscientious.

The question: Why do organizations as diverse as the Chinese government and sadly not atypical large corporations do their best to ignore problems like these instead of fixing them?

Start here: Organizations don’t “ignore” problems, any more than they might be “greedy” or “evil.”

Ascribing these behaviors and motivations to the organization means something quite different from ascribing them to, say, human beings of the Homo sapiens persuasion.

Humans might and often do ignore problems and act greedily. Depending on how a person’s attitudes and behavior stack up against your moral code you might run across the occasional evil villain as well.

But an organization isn’t just like a human being only bigger. It’s different. If an organization appears to ignore a problem, what this means is that its systems and practices aren’t designed to accommodate reporting problems and fixing them.

In many cases organizations are inadvertently (?) designed to conceal, compartmentalize, and in some cases cause problems, as when fixing one would cause a manager’s P&L to go negative, creating one would make it shine, and everyone from the top on down manages to the numbers.

Compounding the metaphorical felony is that someone’s name is on the problem and the practices that led to it. If fixing it would be embarrassing and expensive, well, raises, bonuses, and promotions don’t go to managers who own embarrassing and expensive situations, so relying on luck can be quite appealing.

That’s especially true in the many organizations that consider identifying whose name is on a problem and “holding them accountable” (ManagementSpeak for “punishing them”) to be the essence of root cause analysis.

While it might seem logical that the company would want to fix a problem while it’s still small and manageable, companies don’t want anything. What’s good for the organization doesn’t matter unless it’s good for someone important in the organization.

So when something needs fixing, the first step is asking who, if anyone, will benefit from fixing it.

Most IT managers started reading in the first grade. So far as I can tell, most stop shortly after they’re hired for their first full-time position.

I’m no longer surprised, but am chronically disappointed in the response when I ask members of IT leadership teams what they read to stay informed about industry developments. The usual response? Embarrassed shrugs, punctuated by acknowledgement that Gartner is their primary … make that sole source of strategic IT insights.

You’re reading this right now, which makes you an exception. On behalf of all of us who write and publish, thank you.

But if you’re in management and especially if you’re in IT management, reading is just the ante. It won’t win you the pot.

As a reader you’re aware that “Digital” has become a noun. As a regular KJR reader you know that, whether noun or adjective, Digital is about turning new technologies into new business capabilities and turning those new business capabilities into competitive advantage.

Presumably you read more than just KJR, familiarizing yourself with specific Digital technologies that seem especially promising for your company. That’s what prepares you for conversations about using them to increase marketshare, walletshare, and mindshare.

As a regular KJR reader you’re an IT leader no matter what your job title or official position on the organizational chart is. If you weren’t, your eyeballs would be elsewhere. And so, a reminder: The most important difference between a leader and an individual contributor is that individual contributors succeed. Leaders build organizations that succeed.

It might be my fault. I named this e-letter Keep the Joint Running to embody the principle that, as put forth in the KJR Manifesto, before you can be strategic you have to be competent.

Keeping the joint running is no small thing. That doesn’t mean it’s enough. It’s necessary, but it isn’t sufficient.

Reading isn’t just for management. Reading is the difference between a data warehousing team actively promoting hyperscale “schema on demand,” data-lake repositories and wondering why IT management brought in outside consultants to make them happen.

It’s the difference between developers embracing microservices architectures and saying, “This is no different from what we used to do with COBOL copylibs,” while IT management brings in outside consultants to develop new applications built on a microservices foundation.

It’s the difference between IT infrastructure management advocating replacing the company’s MPLS-based WAN with an ISP-centric connectivity model, and figuring they’re meeting their SLAs so it’s all good while the CIO brings in an IT services firm to make it happen.

So reading isn’t just important for management. It’s everyone’s tool for staying current and not slowly sliding into irrelevance.

It’s everyone’s tool, and as an IT leader it’s up to you to encourage every member of your organization to use it … to recognize that being knowledgeable matters. Maybe not quite as much as competence, but close.

What does this encouragement look like?

Here’s one possibility: With the rest of the IT leadership team, settle on a handful of promising Digital technologies and parcel out responsibility for turning “promising” into either “important” or “never mind.”

Then, each IT leadership team member involves their staff in the process. For small and medium-size IT organizations this might mean reserving two hours in everyone’s time budget for this purpose — one hour to read and one hour for discussion. The desired outcome: A briefing on the technology, that (1) defines and explains what it is; (2) lists and describes the new or enhanced business capabilities the technology might make possible; (3) assesses the technology’s maturity and market readiness; and (4) sketches an adoption roadmap that takes IT from incubation to integration.

And, by the way, once-and-done isn’t good enough. These briefs will be out of date as soon as they’re published, and new high-potential technologies are popping up all the time. Those who write the briefs are responsible for keeping them current.

Keeping track of Digital possibilities is a vital role for IT because the company’s org chart says it is. It is, that is, unless the CEO gave up on the CIO’s ability to provide this level of leadership and hired a chief digital officer to pick up the slack.

In our upcoming book, There’s No Such Thing as an IT Project, Dave Kaiser and I reserved a chapter to describe IT’s new role as business strategy leader. It’s a role that’s important for IT because a department that doesn’t know What’s Going On Out There is a department that neither receives or deserves respect from the rest of the business. It’s important for the rest of the business because …

Well if it isn’t, what’s all the fuss about Digital about?