Best Practices are Stupid!

In their book, Hard Facts, Dangerous Half Truths, and Total Nonsense: Profiting from Evidence-based Management, Jeffrey Pfeffer and Robert Sutton make an interesting observation about best practices:

…a pair of fundamental problems render casual benchmarking ineffective. The first is that people copy the most visible, obvious, and frequently least important practices…. The second problem is that companies often have different strategies, different competitive environments, and different business models—all of which make what they need to do to be successful different from what others are doing. Something that helps one organization can damage another. This is true particularly for companies that borrow practices from other industries, but often is true for organizations even within the same industry.” (emphasis added)

 

So if success depends on being different why do so many companies spend so much time, effort, and money trying to identify and implement other companies' best practices? Perhaps it’s because they don’t know what else to do.

Until now.

My friend and innovation guru, Steve Shapiro has just released his fifth book on innovation, “Best Practices are Stupid: 40 Ways to Out-Innovate the Competition”.  Steve takes Pfeffer and Sutton’s argument one step further. How can you beat your competition if you are implementing their practices? Best practices might bring you up to par with everyone else, but they aren’t going to put you ahead. If you want to get ahead, you need to, as Shapiro states in the title, “Out-Innovate the Competition”.

Steve’s new book follows closely in the tradition of his prior books. He makes complicated ideas easy to understand, challenges conventional wisdom, packages his ideas in easy to digest nuggets, and along the way tells some great stories.

If you are just looking to catch up with your competition, Steve’s book may not be for you. But, if you are looking to leap ahead and become the organization to which everyone else aspires, then I strongly recommend that you order “Best Practices Are Stupid” today.

Data-driven targets

How much data do you collect and analyze to determine whether you are hitting your targets?  Many of the organizations with whom I work spend considerable amounts of time gathering and reporting performance data.  Leaders pour over reports in an attempt to ensure that the data is accurate and complete.  Some even spend so much time analyzing data that they never get to a decision.

Ironically, despite all of the effort put in to tracking progress against targets, there is often little data or analysis used to set those targets in the first place. 

One organization with whom I worked had a customer satisfaction target of 83.75 (out of 100).  I asked them why it was 83.75.  Why not 83 or 84?  Was there some data that said that 83.75 was the level at which they optimized their return on their investments in customer experience. Was 83.75 the point of diminishing return where it would start to cost more to improve satisfaction than they’d recover in sales?  Of course not.  The target was set based on the prior year’s result of 83.15.  Management wanted to do better and 83.75 seemed better (the word “seems” is generally a red flag that you’ve moved out of the realm of data).  They had no data as to whether it was attainable inside or outside of their organization or what impact a .6 increase might have. They just wanted a number that was higher than the prior year.  But higher isn’t always better.  Sometimes the incremental cost to improve on a metric doesn’t yield a proportional return.  Yet, I often find leaders who set targets based on an arbitrary increase or decrease from their prior year’s performance.  Simply using last year’s data as a baseline is not being data-driven. Being data-driven means that there is clear, factual evidence that hitting your targets will provide the outcomes that you desire.

Many years ago, the organization that administered our employee engagement survey sent us two interesting benchmark charts.  The first showed the level of employee engagement for those companies with the most highly engaged employees.  The second showed the level of engagement for the highest performing companies (from a business performance perspective).  The two charts were quite different.  The companies with the most engaged employees weren’t necessarily the companies with the highest business performance.  The higher performing companies did tend to have highly engaged employees and there is an increasing body of research supporting that.  However, they don’t need to have the most engaged employees.  There is a point at which increases in engagement no longer make a difference (from a business performance perspective).

My boss made the wise decision to target our engagement at the levels of high performing companies rather than the most engaged companies.  This is an example of a data-driven target.  He used the data to determine which target best met his goal.  His goal wasn’t to be on the list of organizations with the most employee engagement.  His goal was to improve business performance.  In doing so, he prevented us from over investing and over-optimizing our metric.

Unfortunately, when targets are set with little to no data or analysis, people misuse and misunderstand them.  Either they don’t get taken seriously (e.g., “It doesn’t matter that we missed it, it was unrealistic to start with”) or they are taken too seriously or misapplied (e.g., “Let’s see if we can beat the target by 50%).

The second problem might seem counter-intuitive.  What’s wrong with beating a target?  If you want $100 in sales and you make $200, isn’t your company doing better?  That depends.  If you had to sell the second $100 of merchandise at a loss, in order to get the sale, then exceeding the target hasn’t helped. 

Good targets should have meaning.  They are a guide as to where you want to be.  If they are truly based in data, then the goal should be to hit them or get as close as possible to them (just like a bulls-eye in darts) not exceed them.  Exceeding a data-driven target could be an indication that some other part of the business is being sub-optimized.

A few hints that your targets might not be data driven:

·         The precision of the metric is at a greater level of detail than your ability to perceive a difference in performance. (e.g., satisfaction targets that are expressed into the tenths or hundredths place or revenue/cost targets that are expressed to single dollar or cents place).

·         They are the same for disparate groups or business areas

·         They are based solely on an increase or decrease of the prior year’s performance

·         They don’t have an upper or lower limit

Brad Kolar is the President of Kolar Associates, a leadership consulting and workforce productivity consulting firm.  He can be reached at brad.kolar@kolarassociates.com.

Don’t forget to use data on the front and back end too

I was recently asked to review a presentation with proposed recommendations for addressing customer satisfaction issues.  The person giving the presentation asked me to ensure that he was presenting his case in a data-driven manner.

To his credit, he did a great job of laying out the problem using data.  He showed that every business unit was struggling to hit customer satisfaction targets (as opposed to it being an isolated problem) and that their slippage was not an anomaly but part of a clear downward trend.  He also had strong data that showed that the root cause of the problem had to do with a lack of engagement among staff.  His recommendations focused on a set of initiatives to boost employee engagement.  Overall it was a reasonable report that made sense and seemed credible.

But his report was incomplete.  His data only supported the middle of his argument - that there was a customer satisfaction problem (and its causes).  He overlooked providing data on the front and back end.

Supporting your context statements (front-end)

I often see presentations that make broad assertions on the front end (e.g., “Changes in the economy are forcing us to rethink the way we go to market” or  “Absenteeism is a major driver of poor productivity in our department”) without any evidence.  It’s as if people treat these contextual remarks as throw-away statements that are used to ease people into the presentation.  But contextual statements are important.  They set the premise upon which an argument will be built. 

Proving that there are changes in the economy doesn’t automatically mean that your company has to rethink the way it does business.  Showing a high level of absenteeism, by itself, does not prove that you have a productivity problem (or that your productivity problem is due to the absenteeism).  Both assertions require data that demonstrate that these situations (change and absenteeism) drive an undesired outcome. 

In some cases, like with absenteeism, providing data might seem like overkill.  After all, doesn’t everyone know that absenteeism hurts business?  That’s a risky premise.  Too often such wide-sweeping generalizations are used without proper due diligence.  I’m surprised at how many leaders dig a mile deep questioning the data on how the business is performing but take these sweeping, introductory comments at face value.

Supporting your recommendations (back-end)

I’m not sure if people just run out of steam by the time they finish an analysis, but for some reason recommendations often aren’t supported by data.

For example, suppose that one of the root causes of the engagement problem is that employees do not feel that their contributions are recognized.  A common recommendation in such a case is some type of “instant recognition” program.  Such programs allow leaders to provide ad-hoc monetary or other types of rewards in the moment as opposed to through formal performance and compensation processes.

On the surface, that sounds like a data-driven recommendation.  The data says that engagement is a problem.  The root cause is recognition and therefore, the solution is a recognition program.  But from a data-driven perspective it’s missing something.  What evidence is there that the instant recognition program will solve the problem?  Sure, it’s supposed to.  It may be designed to.  But will it?

Why would the managers do this?  Has there been success with other ad-hoc programs in the past?  Are managers incented and do they have the band-width to take on such a program?  Is this the type of recognition that employees want?  Are there some leaders or departments who already do similar things with success?  Is there data from outside the organization that shows that such programs work in other places?  Are those other places similar enough from a structure, culture, etc. standpoint to use as a benchmark?

Of course, we can never know for sure if a recommendation will solve a problem.  But, we should at least have some evidence that it has a chance.  As you can see, when speculating about a recommendation, sometimes the data aren’t as robust or “hard” as those describing the problem.  However, that doesn’t mean they should be ignored.  Every recommendation should have some evidence as to why you believe it will work.  Otherwise, why did you select it in the first place?

Being data-driven throughout the entire analysis process

In my work over the past few years, I’ve been impressed with how leaders are becoming more sophisticated at using data.  More seem to be willing to roll up their sleeves and dig into the numbers.  However, there is an opportunity for many leaders to expand their view.  Data shouldn’t just support the problem, it needs to support the context in which we think the problem exists and the recommendations for resolving that problem.

Take a look at your presentations.  Do you provide data to support the assertions that you make in the introduction?  Do you provide evidence as to why you think your recommendations will work? If not, you may need to do some more digging.

Brad Kolar is the President of Kolar Associates, a leadership consulting and workforce productivity consulting firm.  He can be reached at brad.kolar@kolarassociates.com.