Buzzwords Without Action Can Become Empty Promises

From an Omdia analyst, here are some suggestions for ways we can put action behind those memo-headline catchphrases.

We are all strategic-buzzword compliant: “Change is the only constant,” “The speed of change is increasing,” “We have to be agile,” and “Core competencies define our strategy”. But what does all that mean in practice?

If change were the only constant, we would not have three-year strategies. If the speed of change is increasing, we would scan the environment regularly, do monthly SWOT studies, and have a three-month horizon for our strategic review and renewal. If we were agile, we wouldn’t budget in annual cycles and we would have cross-functional teams everywhere. We’d dismantle bureaucracy, devolve decision-making, and have self-managed teams. And if we had core competencies, we’d also have Centers of Excellence, strategic capabilities, and matrix management. Besides, basing a strategy on core competencies is an inward-looking approach when you should be outward-focused.

Let’s next tackle the three-year (or even one-year) strategy. Constant change, disruptions, geopolitical instability, earthquakes, floods, fires, migration, pandemics, and technological change suggest that any year will differ from the last.

The problem with strategies is that they plan for a fixed future, which is fine if you’re building a bridge, but not good if you meet customer and supplier requirements. I’m not saying strategizing is pointless; it is essential. But any strategy must be formulated within a context. And the context is constant change and disruption.

So how do we strategize in context? Wise organizations develop scenarios within which a multitude of possible strategies will fit. Most scenario planning identifies the two primary drivers of change that will affect the enterprise. They then develop a matrix with a driver on each axis.

Here’s an example: For this hypothetical business, driver one is the rate of technological change (low or high), and driver two is the rate of technology adoption by our customers (slow or fast).

If you have a low rate of technological change and a slow rate of adoption, your customers wouldn’t be expecting new digital products and wouldn’t use them if you had them. Your strategy in this scenario, then, is to improve your internal efficiencies and increase customer satisfaction.

Next year, a new technological frontier opens up, but your customers are slow to adopt. The strategy here is to educate customers and introduce prototype products using the new technology. In the space of a year, you’ve switched strategies – that’s agility.

The two other scenarios require different strategies: A low rate of tech change and fast adoption by customers (leading to a saturation market); and rapid tech change and fast adoption by customers, which may lead to contagion and chaos if not managed strategically.

These four scenarios require four different strategies – and if you have a three-year strategy based on one scenario, you’ll probably miss the boat, even if you know there is one.

If the speed of change is increasing, how do we identify meaningful changes that will affect the organization? Most enterprises I know leave the environmental scanning and trend analysis to their executives or, in rare cases, their R&D teams. R&D teams are a better option because it’s their job, and the average executive scans the environment part time or periodically. However, neither party is actually in the business environment, dealing with customers, suppliers, and the competition.

If you really believe that the speed of change is increasing, you would have everyone in the organization scanning for change and opportunities. Many organizations may respond: “But we do. Our employees are free to approach their manager if they see something that needs attention.”

That’s so wrong on many levels. The apparent “command and control” mindset here means that decisions will be slow, and managers will filter (or steal) ideas. By filtering ideas through a management layer, you’re setting yourself up for groupthink, politics, bias, and inactivity.

Instead, have a portal where ideas are shared and can be expanded. Many systems are available for the ideation, organization, and development of ideas. Then, everyone in the organization scans for changes, challenges, and opportunities.

Next, let’s tackle organizational agility. Most enterprises have agile teams, but their implementation is patchy, and risks are involved in islands of agility. Instead, enterprises should look into organization-wide agility, including in the finance and HR departments notorious for bureaucracy.

An agile organization would focus on value streams, not departments, where customer outcomes drive the organization. Each value stream would be cross-functional, utilizing the resources they need to deliver the outcome. There would be Centers of Excellence to handle and grow specific skills, and they would advise the value stream teams.

See where I’m going here? An agile organization would not be a command-and-control hierarchy, but instead a fluid matrix. An agile enterprise would match its budgeting to value streams, not departments, and allocate funding based on required outcomes.

Finally, let’s look at the concept of core competencies. They are theoretically the differentiators in an enterprise. I say “theoretically” because if you ask most people in an organization, they have no idea what the differentiators are. They might know the target markets, what must be done well, and where the organization wants to be in five years, but not the differentiators. Besides, core competencies muddy the water.

Instead, let’s call what we need differentiators. Competencies get confused with skills. Instead of core competencies, companies should identify their differentiators and develop the capabilities to accomplish them.

For example, suppose the company wants to differentiate on its unique products and personalized customer experiences. In that case, it must develop the capabilities of proficiency in developing digital products, pivoting quickly, or attracting new customers.

And capabilities are not skills or competencies. They are the sum of skills, knowledge, resources, and capacity. Skills are people with the expertise and abilities to execute a plan. Knowledge is the context and understanding of the capability – why it exists, where it’s going, and what can be done with technologies in the capability area. Resources are the assets, systems, and financing available to the capability. And capacity includes the time, will (or determination), and authority to use that capability properly. You don’t have the capability if you don’t have all four elements.

You should strategize and then develop or strengthen the capabilities to implement the strategy. For example, you’d need different capabilities for each strategy in the scenario example above. Capabilities for improving internal efficiencies differ significantly from those required for expansion and product development. You may need both, but at least know what you need.

Be intentional about buzzwords. Know why you’re using them, what they mean, and what needs to be done to give effect to them. Otherwise, buzzwords are just empty promises.