All Posts by Bob Lewis

|In: Policies and Procedures|Last Updated:

It’s time to revisit … or maybe just visit … your COVID-19 vaccination policy.

If you’re about to express your indignation about bringing politics into Keep the Joint Running, don’t. As has been pointed out in this space before, propositions that have been politicized are not necessarily propositions that are political.

Example: 98.9% of all COVID-19 cases that have resulted in mortality or hospitalization were contracted by unvaccinated individuals.

Just in case you’re having trouble classifying this statement, it is not political.

And it does suggest the text of what should be your COVID-19 vaccination policy:

All employees who:

  • Enter our facilities …
  • Enter a client’s facilities …
  • Perform any of their responsibilities face-to-face with colleagues regardless of location …

… must be fully vaccinated. Refusal to comply with this policy can result in termination or reassignment to a position all of whose duties can be performed remotely. If the result is reassignment the company reserves the right to adjust compensation to make it commensurate with the new position’s pay structure.

This policy applies to all employees and contractors, other than those who can perform all work remotely.

Understand, I’m among those who consider the quintessential element of American culture is that we’re all free to pretty much go to hell however we’d like. But I’m also among those who agree with John B. Finch that, “… your right to swing your arm leaves off where my right not to have my nose struck begins.”

But neither of these propositions is the driving force behind this vaccination policy.

The driving force is your responsibility as an employer to provide safe working conditions for everyone who works in your facilities. Every unvaccinated employee, even those wearing masks, constitutes a preventable hazard to every employee they come in contact with.

That includes vaccinated employees. While the approved vaccines have proven extraordinarily effective, in risk management terms they don’t prevent the disease perfectly. What they do is prevent it well and mitigate its effects among those who contract the virus.

So exposing even fully vaccinated employees to unvaccinated ones endangers them.

Another popular objection to mandatory vaccination is that the risks of vaccination aren’t known.

This is accurate, in the same sense that you don’t know if a piece of software you’ve relied on for the past year has undetected vulnerabilities. In both cases your confidence is limited to how well you know what risks to look for, and your ability to look for them.

What we know about the COVID-19 vaccines’ risks is that they are miniscule.

What we know about COVID-19’s risks is that the disease’s symptoms include death, severe debilitation, and months of everything you eat tasting like cardboard.

Requiring employees to be vaccinated doesn’t put them at risk. On balance it reduces their net risk.

But …

Employers are accustomed to having most of the power in their relationship with their employees, and if that’s your situation a policy such as the one recommended here might be workable.

But right now you have to strike a balance, because there’s a pretty good chance you have some otherwise valuable employees who, for one reason or another, refuse to be vaccinated.

So even if you like the policy I’ve described here, you’ll probably have to soften it to accommodate them.

Bob’s last word: If you’re concerned that a policy like this might create the impression that you’re endorsing a political party or governing philosophy, be reassured: even Fox Corporation has instituted a form of “vaccine passport.”

Regardless, please share your thoughts, and even better your company’s vaccination policy, with the KJR community by way of the Comments.

Bob’s sales pitch: On an entirely different subject, if you’re interested how to make IT process improvement initiatives successful, check out my most recent article on CIO.com: “The hard truth about IT process success.”

Comments

|In: Digital|Last Updated:

When you buy your next smartphone, what features will you compare to make your decision?

So far as I can tell, the dominant contrasts appear to lie in their cameras – cutting edge smartphones have, in addition to their main camera, ones for wide-angle, telephoto, and front-facing (selfie-mode).

Add to that a bunch of different image manipulation features and you have a complex comparison.

Next question: When you buy your next point-and-shoot camera, what features will you compare to make your decision?

Answer: Most likely you won’t buy your next point-and-shoot camera. You’ll upgrade your smartphone instead, and for higher-end photography you’ll buy a DSLR.

As a category, point-and-shoot cameras are, along with Monty Python’s famous Norwegian blue parrot, on the way to joining the choir invisible. Steadily-improving smartphone cameras are rapidly extinguishing them, just as steadily-improving digital cameras extinguished those that use film.

Which will get us to this week’s topic in a moment, right after we ask ourselves whether better product management on Nikon, Canon, or Olympus’s part might have staved off this category calamity.

The answer: Probably not. Product management is an in-category discipline, which is why Canon’s product line dominates the DSLR marketplace but doesn’t provide OEM componentry for any smartphone. More broadly, it’s why the major camera companies didn’t add telephone-oriented features to their point-and-shoot cameras.

Which (finally!) brings us to this week’s topic: Whether IT should organize according to software product management principles rather than software project principles (see, for example, this lucid explanation on martin.Fowler.com).

The answer? No, but IT shouldn’t continue to organize around software projects, either. As all enlightened members of the KJR community (if you’ll forgive the redundancy) know, there’s no such thing as an IT project. It’s always around business change or what’s the point?

Organizing IT around IT products is certainly better than organizing it around IT projects … product-mode thinking does expressly incorporate business improvement into its planning and governance practices, more easily incorporates agile thinking into the mix, and solves the problem of maintaining a stockpile of expertise instead of disbanding it once the initial implementation project has completed.

On the other hand, most agile variants keep teams in place until the backlog has shrunk beyond the point of diminishing returns, so this last “benefit” is something of a strawman.

Meanwhile, the product perspective brings with it a potentially crippling disadvantage – the inevitability of internal competition. Here’s how it works:

Imagine you’re the product manager for your company’s in-house-developed, highly optimized, strongly supported SCM (supply chain management) system. You and your team have deep expertise in its workings, which lets you respond quickly and efficiently when business needs change or new needs arise.

Meanwhile, as a result of several mergers and acquisitions, three other business units also have SCM systems and supporting teams, each with capabilities roughly comparable to what your team brings to the table.

And so, the CIO and IT planning committee decide it’s time to rationalize the applications portfolio, building out the architecture to a hub-and-spoke model anchored by Oracle ERP Cloud (this is, understand, just a ferinstance, not an endorsement).

Suddenly, your team’s expertise is irrelevant. And so, being savvy at the game of corporate politics, you invite the head of your business unit’s supply chain function to join you for conversational lubricants, in which conversation you explain the disadvantages of forcing his team to use a software vendor’s plain-vanilla SCM module instead of the finely-tuned application they’re used to.

Describing how this scenario plays out is left as an exercise for the reader. Suffice it to say, it wouldn’t be pretty.

Bob’s last word: More problematic than everything else, the product perspective leaves in place defining IT’s relationship with the rest of the business as a vendor dealing with internal customers. This is a bad idea, something I’ve been explaining since1996.

IT should be organized to support business optimization, where each business function defines optimization according to what it will take for it to run differently and better, and the company defines IT’s relationship with the rest of the business as partner and collaborator in delivering profitable value to Real Paying Customers.

Bob’s sales pitch: Not the first time I’ve mentioned this, and it won’t be the last – you’ll find an in-depth explanation of how to make this work in There’s no such thing as an IT Project: A handbook for intentional business change. And it isn’t just in-depth coverage of content that matters. Dave and I took pains to make sure it’s readable, too.

Comments