All Posts in Process Management and Improvement

|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

|In: Organizational Effectiveness|Last Updated:

All IT organizations test. Some test software before it’s put into production. The rest test it by putting it into production.

Testing before deployment is widely regarded as “best practice.” This phrase, as defined here, translates to “the minimum standard of basic professionalism.”

Which brings us to organizational change management (OCM), something else all organizations do, but only some do prior to deployment.

There is, you’ll recall, no such thing as an IT project, a drum I’ll continue to beat up to and beyond the anticipated publication date of There’s No Such Thing as an IT Project sometime in September of this year.

Which brings us to a self-evident difference between testing, aka software quality assurance (SQA), and OCM: SQA is about the software; OCM is about the business change that needs the new software.

As we (Dave Kaiser and I) point out in the upcoming book, organizational changes mostly fall into three major buckets: process, user experience, and decision-making.  Process change illustrates the SQA parallel well.

Probably the most common process change goal is cost reduction, and more specifically reducing the incremental cost of processing one more unit.

As a practical matter, cost reduction usually means layoffs, especially in companies that aren’t rapidly growing. For those that are growing rapidly it means employees involved in the process will have to handle their share of item processing more quickly.

In a word, employees will have to increase their productivity.

Some unenlightened managers still think the famous I Love Lucy chocolate factory episode illustrates the right way to accomplish this increase. But for the most part even the least sophisticated management understands that doing things the exact same way only faster rapidly reaches the point of diminishing returns.

Serious process change generally results in different, and probably fewer distinct tasks in the process flow, performed by fewer employees because there are fewer tasks and those that remain will be more highly automated.

Which brings us back to OCM and when it happens in the deployment sequence.

Managers don’t need a whole lot of OCM know-how to understand the need to re-train employees. But many still blow it, teaching employees how to operate the new software: Click here and this happens; click there and that happens.

Training shouldn’t be about how to operate software at all. It should be about how employees should do their changed jobs using the new software.

But training is just the starting point. What’s often also lost in translation are all the other organizational changes employees have to adjust to at the same time. Three among many:

> Realignments: Employees often find themselves reporting to new managers. This, in turn, usually leads to a severe case of heads-down-ism until employees figure out whether spotlighting problems in the new process flow will be welcomed, or if a new manager’s style is more along the line of messenger-shooting instead.

> Metrics: With new processes often come new process optimization goals, which in turn should mean new process metrics, but too-often doesn’t.

The first rule of business metrics is that you get what you measure — that’s the risk you take. So if a company changes a process without changing its metrics, employees will do their best to continue using the old process, as this is what’s being measured.

> Colleagues: Some work that had been performed by employees who work in a different city, building, floor, or cubicle down the hall, and oh, by the way, these folks used to know each other by name. That work might now be performed by total strangers who live in a different country and time zone, and speak a different native language.

Just adapting to different accents can be challenging enough. Add cultural and time-zone differences to the mix, make everyone involved unknown to each other, and the opportunity for process traffic jams increases, not by increments but by multiples.

No matter what the intended change, for it to be successful all these factors, and others, will have to be addressed.

Change leaders can address them before instituting the change, helping the organization and everyone in it prepare. Or, they can leave it up to everyone to muddle through.

Muddling through does have one advantage: Change leaders can blame anything and everything that goes wrong on change resistance.

Given a choice between effective planning and blaming the victims … well, it’s hardly even a choice, is it?

Comments