Last week, posing as Tinkerbell, I asked you to let me know if you still find KJR valuable. Hundreds of readers took the time to answer in the affirmative.
For a writer, there’s no greater gift than having an audience. Thank you all for letting me know my weekly sermons are still useful.
# # #
I guess I’ll have to publish it here.
You might have already seen the now-not-so-recent piece on The Wall Street Journal’s editorial page, titled “It’s Time to Get Rid of the IT Department.” (Joe Peppard, 11/27/2021).
It isn’t all that different from Nicholas Carr’s tiresome and business-illiterate “IT Doesn’t Matter,” which, in 2003, led to his earning the Rocky and Bullwinkle Wrongway Peachfuzz award for polar opposite prediction. After all, here in the present, IT saved the world economy by enabling remote work during the COVID-19 pandemic.
That was after it became the centerpiece of business strategy, driving the Digital revolution.
Highly visible yet profoundly wrong ideas, even if they’re mere rehashes, require rebuttal, but the WSJ, by editorial page policy, doesn’t accept rebuttals. I guess they don’t like to be contradicted.
So I’ll have to publish my nominees for Mr. Peppard’s wrongest propositions here. Feel free to share.
Proposition #1: IT is a box on the org chart, with its own management hierarchy and budget, and that’s a problem.
KJR rebuttal: If a box, managers, and a budget are problems, they’re problems for every business function in the enterprise. Why single out IT?
Proposition #2: IT-as-partner is a bad thing. And I quote, The problem starts with what I think of as the “partnership engagement model” … While intuitively appealing this model positions the IT island as a supplier, mandated to build IT solutions and deliver services to the mainland.
KJR rebuttal: Say what? IT as partner … more precisely, IT as partner in achieving intentional business change … is the polar opposite of IT as supplier to internal customers.
Proposition #3: IT is measured on inputs, not outputs. Examples: money spent, system availability, project completion rates, and, OMG! deploying technology on time, on budget and meeting the specs. These don’t, Mr. Peppard tells us, correlate with success.
KJR rebuttal: So fix the metrics. The solution to measuring something wrong isn’t to eliminate what’s being measured. And oh, by the way, if the specs are right, meeting them does correlate with success. If the specs turn out to be wrong, fix the process used to create the specs.
Proposition #4: The Crystal Ball conundrum. And I quote: The partnership model also assumes that it’s possible for the various corporate units to define upfront and many months in advance exactly what they will need from the IT department. The assumption is reinforced by the demands of the traditional yearly budgeting process.
KJR rebuttal: The problem isn’t reinforced by the annual budgeting process. It’s caused by the annual budgeting process. Solution: Fix the annual budgeting process.
Proposition #5: Decentralizing technology also requires some centralization. And I quote, excerpted from an account of an organization that supposedly has eliminated IT: Everybody has to use the same security protocols and software programming languages, and conform to a prescribed architectural blueprint when building digital products and solutions. But within those guardrails, employees have the scope to do whatever is necessary to get the job done.
KJR rebuttal: Presumably, these security protocols, languages, and architectural blueprint are created and maintained by IT professionals, who also establish protocols for assuring compliance. Presumably, these IT professionals live in a box somewhere on the org chart. What should we call that box? Wait … I know! … my hand is raised – call on me! … let’s call it “Information Technology!”
Bob’s last word: Boil it all down, and Mr. Peppard’s proposition is that business departments are in a better position to figure out the information technology they need than a centralized IT organization.
That is sometimes correct, and when it is, IT ought to support DIY IT efforts for all the reasons I’ve written about over the past couple of decades (see, for example, “Stop stomping out shadow IT,” 9/4/2012).
But Mr. Peppard ignores the very real complexities associated with sound, secure, and compliant technical architecture, and especially with integrating what would otherwise result in inconsistent islands of automation.
So DIY IT gets a thumbs up. IT-supported DIY-IT gets two thumbs up.
Making all IT DIY IT gets a big thumbs down.
Even if it does look superficially persuasive on The Wall Street Journal’s editorial page.
Bob’s sales pitch: In response to last week’s column, one commenter pointed out that I don’t make subscribing to KJR easy enough.
And so … if someone has forwarded this to you and you like what you read, here’s where you can subscribe: Subscribe – IS Survivor Publishing.
https://pbs.twimg.com/media/CiHO0UoVIAAC16a.jpg
Says a lot! Hope you find it humorous.
Yep. Thanks!
Sorry but Peppard is correct. as in 100.000000000% correct.
IT should be doing what the enterprise tells them to do not dictating to the rest of it.
IT is NOT a partner. It is a support department that should do what it is told not be such a problem to the company by insisting they have to do it a different way because they want to do it a different way.
Yes!
IT should be judged by what it succeeds in doing that is good not by how much resources it consumes. Changing the metrics would be good to do, IF your company actually had those metrics you claim, but IT would fight that like ww3.
The suits are telling IT what the enterprise needs. IT is telling them they need the fanciest new program and time and money and then they still fail to deliver.
THE PROBLEM is IT not the enterprise.
IT should do what they are told for security and justify their languages and platforms not given a free hand to do anything that they want to do to tweak their resume for their next job. And ALL architecture should be done by the SYSTEMS department not dictated by IT.
It is time for you and IT to get out of the box you are stuck in and let the Big Boys run things for a change.
Hi Bob!
In regard to Proposition #3: “IT is measured on inputs, not outputs. Examples: money spent, system availability, project completion rates, and, OMG! deploying technology on time, on budget and meeting the specs. These don’t, Mr. Peppard tells us, correlate with success.”
It appears to me that sentence is conflating inputs and outputs. Money is an input. Availability, ‘project’ completion rates and deployments are (some of) the outputs. Your response is spot on IMHO.
In response to wmba dams: Who do you think SYSTEMS is?! It’s IT! Anarchy (and ultimate failure) reigns if no one with expertise and discipline is providing some guidance…
Bob if any other reason was ever needed for the importance and value you bring, the mere existence of people who bring up these same old troupes at the WSJ is reason enough for me. It truly starts my day out right when I see your email in my inbox!
“IT is measured on inputs, not outputs.” So, Money Spent is an input, not an output, so it is NOT a metric for success; more money spent is not more value gotten or more product made or more quality included or more profits earned; yeah, I get that.
But System Availability is an input, not an output? So it is NOT a metric for success? For anyone? It’s misguided to measure it? And God forbid, to INCENT anyone over it, based on that measurement?
If System Availability isn’t a metric for success, for anyone, then why is anyone bothering with it? Why do we even care? Let’s stop wasting money (and attention!) on something that’s useless for success. Let the system go up and down and up and down all day long if it really wants to. Let’s not spend one red cent on measures to prevent downtime, or to shorten it when it occurs. Red cents are, after all, an expense. It doesn’t matter if the systems that people use to do their jobs are only actually THERE oh, 20% of the time maybe? or 30%? or three minutes per day? Because that’s a mere INPUT, i.e. an input TO THEIR JOBS, and therefore measuring that input, i.e. measuring how much systems ARE THERE, is irrelevant to success, anyone’s success. It is CERTAINLY unrelated to the ENTERPRISE’S success.
That editorial is behind a paywall, so I can’t read it; I’ll just have to ASSUME that it’s as brazenly silly as it appears to be from the description here at KJR.
It is true that System Availability “is an input” — for the people who use that system to do their jobs, on behalf of their employer and for the benefit of that employer. It is also certainly true that the mere fact that a System is Available, does not, by itself, guarantee that the System is any good at the job it’s being called on to do, or well-designed enough for the people who use it to do their jobs to actually DO their jobs well with it. And it is also true that a system that is available (expensively!) 24/7/365 with 99.999% uptime but only actually used for three minutes per day, if that three minutes turns out to be enough, is probably wildly overpowered and wildly overbuilt and may well have been much more expensive to build and maintain than strictly necessary. (Although, if nobody can ever predict WHICH three minutes per day the System will be needed, but terrifying gargantuan losses will instantly occur if it isn’t instantly available for those particular three minutes, it might well be cost-justifiable after all to pay for it to be available 24/7/365 with 99.999% uptime.)
But even if System Availability is a mere “input” for the organization as a whole, so that high System Availability does not guarantee success by the organization as a whole, System Availability is definitely an “output” for SOMEONE — and that Someone is the IT department — who should be measured for System Availability, and incented for System Availability. Or else, soon enough, there won’t BE any System Availability.
Similarly, “project completion rates” as an input: if the completed projects are useless for their intended purposes, and nobody measures or incents THAT, it doesn’t matter what percentage of them are “complete”, if being “complete” is what is being measured and incented. Or, if the projects take so long to “complete” that they are hopelessly obsolete and useless by the time they are delivered, no matter how reasonable the specs happened to be lo! those many years ago when the specs were drawn up, then yeah, “completion rates” are not, by themselves, all that good as a metric for success (or a basis for incentives). And “meets the specs, delivered on schedule” is equally useless as a metric or an incentive if the process for drawing up the specs and the schedule is so broken that a project that “meets the specs” is routinely useless, or the schedule is routinely so grossly unrealistic that projects are routinely delivered long after needs have changed or disappeared, or routinely delivered as half-baked rush jobs with vital features missing or else constantly malfunctioning. So, as Bob says, if the metric is a misguided metric, then fix the metric. Duh.
Oh Lordy.
Wow! It’s probably good that you couldn’t access the whole thing!
And you triggered another thought about system up-time: Can you imagine Amazon acting as if system uptime is just an “input metric”?
I’ll see your Amazon and raise a Zoom!
What in hindsight, is truly astonishing, is during the initial pandemic lockdowns, when Zoom grew from 20 million users in December to 200 million in March to 300 million in April, what did NOT occur:
Hours-long outages. Mass collapsings under unprecedented load. Total system failure. For MONTHS, they deliberately feature-froze EVERYTHING, making no changes, no matter how trivial, for fear of triggering God-knows-what. What the world suddenly needed was videoconferencing, and not JUST videoconferencing (which had been here for years) but EASY videoconferencing WITH ACTUAL AVAILABILITY, at truly shocking scale, and Zoom delivered. And that’s why Zoom, a former “face in the crowd” in a modest-sized field, is suddenly global infrastructure with a market capitalization to match.
They didn’t dare tweak ANYTHING for weeks and weeks and weeks. They let a whole swarm of itty-bitty known bugs and much-demanded feature enhancements slide until something vaguely resembling a growth plateau was achieved. And THEN, of course, working down the backlog promptly caused a major partial outage for a few hours, and mass screaming, and golly! imagine how that would have served the world, and Zoom, during Pandemic Lockdown March and April!
Oh yeah, I’ll give you ONE GUESS whose cloud platform Zoom is running on…
You are SO right about Zoom!!
Bob,
I appreciate your taking the time to dig into Mr. Peppard’s critique of IT and rebut some of his contentions. Unfortunately I just gave up my WSJ subscription and can’t read the article, does anybody know where it might be posted?
Thanks.
Sorry – I’m not in a position to provide this. I hope someone else knows how to get a copy in your hands.
Lets see, eliminate the boxes.
To my mind there are three classes of companies when it comes to IT.
One class is a manufacturing company manufacturing widgets, which has an IT department to manage the information technology services needed to manufacture the widgets.
The second class is a company which provides software as it’s only product.
The third class is all those companies which do not fit comfortably in the first two classes.
Now I am trying to imagine getting rid of the IT box, because the box is a problem. While we are at it, get rid of the marketing box, the human resources box, the finance box, the shipping and receiving box, the legal box, and any other box I may have overlooked. To do that would probably require that we completely overhaul the business administration colleges, the law colleges, the computer science colleges.
Anybody ready for a paradigm shift like this? Or maybe there is a company out there that has actually done something like that?
Regards,
Greg
I think there are more types of business than the three you mention – services firms, for example, which subdivide into quite a few subtypes.
Regardless, your point is right on the money – if enclosing an internal service in a box is a problem, the logical conclusion is that we need to disband all internal service boxes.