All Posts by Bob Lewis

|In: Cognitive Enterprise|Last Updated:

What do self-driving cars have to do with IT governance?

As it turns out, quite a lot.

Start with (self-promotion alert #1) the phrase “IT governance.” As long-time (and, I hope, short-time) readers know, in KJR-land there’s no such thing as an IT project — an idea so important Dave Kaiser and I named our soon-to-be-available book after it.

You’d give a perfect self-driving car your destination and let it figure out whether the best solution is to drive you there, to fly … at which point it would book your tickets and drop you at the airport … or make some other arrangements. Self-driving car governance should be transportation governance, just as IT governance should be business change governance.

More important than even this is how badly many designers of all forms of corporate governance ignore one of the most basic elements of delegation.

The element in question is the difference between delegating goals and delegating tasks. You’ll find (self-promotion alert #2!) what you need on this subject in Leading IT: <Still> the Toughest Job in the World. Put simply, the most effective leaders only delegate tasks when they can’t trust the person they’re delegating to enough to delegate the goal and leave the details to the delegate.

Look at it from the perspective of a self-driving car’s owner, who, even if the current state of the art doesn’t include booking tickets for some other mode of transportation, should be able to enter the destination and let the car handle the rest.

Except that no self-driving car is reliable and adaptable enough to handle all the details without human supervision. Humans metaphorically delegate driving tasks to the car but … and this is the essential point … can’t trust the car to handle the job without oversight.

Take a look at business governance as usually practiced and you’ll find distrust is baked into the heart of it. Governance is all about controls. Some controls are useful — they make sure processes are … well … in control.

They’re fine. But then there’s the other kind — approvals, to make sure those who have a job to do lack the authority to screw it up by just doing it, by requiring one or more signatures first.

This doesn’t mean organizations should become free-for-alls. No, organizations should prescribe their processes and practices clearly enough, and educate their managers and supervisors enough that those responsible for doing stuff know when there’s a corporate recipe in place because, for example, legal and regulatory requirements don’t leave room for creativity.

They should prescribe processes and practices in detail when the company’s systems and process management would be messed up if everyone accomplished similar goals in radically different ways.

That’s all fine. What isn’t so fine is when what’s prescribed is, in self-driving car terms, turn-by-turn directions, each turn of which requires someone’s signature.

Because that’s what controls end up looking like — the need for outside approval of each step managers, supervisors, and employees need to take to get their jobs done.

Governance by controls, which is what we’re talking about, has three major disadvantages. The first: it slows things down, because each approval takes actual time, which incurs delays.

The second: It adds to the workload of already up-to-their-eyeballs-in-more-important-matters executives. This doesn’t have to be overly onerous, so long as the executives in question are willing to just rubber-stamp the decisions in question. But if they rubber-stamp everything, what’s point of requiring their signature?

The third disadvantage? It’s demoralizing. I worked with a company a number of years ago that wanted to revamp its capital approval process. Something my team learned along the way was that the smallest decisions required the most signatures (six), and each signatory except the last resented being second-guessed.

What we heard, over and over again, was the same complaint: “If the company doesn’t trust me to make a decision like this, why did they hire me?”

Which might (and, I hope, did) lead you to ask, if governance isn’t to operate through controls, what’s the superior alternative?

The self-promotion-opportunity #3 answer: As Scott Lee and I point out in The Cognitive Enterprise, culture is (or should be) the new governance.

That is, for self-driving cars, culture provides, metaphorically, the lane markers. Controls are the guardrails, something self-driving cars that stay in their lanes will never make contact with.

The parallel? Governance bodies should spend most of their time instituting a culture that makes most controls unnecessary.

Oh, and I hope I didn’t hurt your feelings by comparing you to a car.

Comments

|In: Leadership|Last Updated:

Is Amazon a brutal place to work? Do you have a reason to care?

To answer the first question you’ll have to do some googling, after which you’ll have to decide which sources you find more and less credible.

I don’t know if its warehouse workers pee in bottles to keep their productivity statistics in line with what is required or not. I also don’t know how accurate recent reports about its independent delivery contractors’ allegedly unsafe driving practices and working conditions are.

What I’m pretty sure of: An organization as big as Amazon is neither entirely innocent nor thoroughly guilty of allegations like these. If Jeff Bezos set out to make Amazon the worst place in the world to work he’d have almost as hard a time achieving this nefarious goal as he’d have if he wants Amazon to be the best.

Not that he’s off the hook. Not at all. Executives are, as has been pointed out in this space more than once, responsible for the business culture they preside over because how they behave in different circumstances has more impact than any other factor.

Which leads to the conclusion I’m least certain of, which is also the one I’m most confident of, and is the most important to you:

To the extent Amazon’s reported awfulness is real, it’s an unintended, or perhaps not-cared-about consequence of something quite positive that, as with so many other positive somethings, becomes quite negative when pushed beyond its limits.

Amazon is very likely the most efficient retailer in history — efficient in terms of:

  • Cycle time: How long customers wait for their merchandise after placing their orders.
  • Quality: The percentage of delivered merchandise that matches what customers ordered.
  • Marginal cost: The average incremental cost of one more purchased and delivered item.

If you’re Amazon or anyone else, you don’t become this good at what you do in one big implementation (and I’m going to resist the temptation to segue into a waterfall-vs-agile karaoke number).

You become this good in large part by establishing a culture of continuous improvement.

A culture of continuous improvement is a Good Thing (to coin a phrase). It means never being satisfied with how good you already are, and never assuming there’s no way to become better.

It’s a good thing right up until the organization crashes into the point of diminishing returns.

I first wrote about this phenomenon fifteen years ago (“Do you deliver?” KJR, 6/24/2004). What I said at the time was, Squeeze a wet sponge and water will come out. Squeeze it again, harder, and you’ll get more water. Try to dry a sponge this way and you’ll get pretty frustrated. No matter how hard you squeeze, it will still end up damp. You can’t get all the water out, but you can damage the sponge.

Squeeze a flabby organization and cost will come out. Squeeze it again and you’ll find more efficiencies. No matter how hard and how often you squeeze, you’ll always see more waste. But like the sponge, when you squeeze an organization too hard you damage it.

So … never assuming you can’t get better is good. But inferring that doing more of what made you better will make you even better … that’s a false and dangerous inference.

A very long time ago, Byte magazine reported on a newly announced file compression package. Its developers claimed it was loss-less. They also claimed you could run a compressed file through it as many times as you liked, and each time you did it would come out smaller than the last time.

Think of continuous improvement programs as process compression algorithms and you’ll see the point: Trying to squeeze additional inefficiencies out of a process by squeezing harder is like trying to compress an already-compressed file by applying the same compression algorithm to it that you’ve already applied.

Dispensing with the dueling metaphors, what’s a beleaguered manager to do?

In a word, think.

In a few more words: To make a process better, take the time to:

Decide what “better” means — which of the six dimensions of process optimization you’re going to improve.

Evaluate proposed ways to improve the dimension in question.

Determine the tradeoffs. Unless the process in question is pretty awful, improving one dimension will probably lead to making at least one of the other dimensions worse. And even if it doesn’t, it might very well do some other organizational damage that, if not anticipated, would become an avoidable unintended consequence.

Then you’re in a position to mitigate the tradeoffs, because … do you really want to be the one forcing employees to pee in a bottle?

Comments