All Posts in Strategy and Tactics

|In: Industry Commentary|Last Updated:

Should executives receive incentive pay? Should anyone?

Last week’s KJR explored the logic behind incentive pay, and concluded it doesn’t hold up to scrutiny (I nearly said “close scrutiny,” which contrasts with the distant scrutiny that’s so popular these days).

Incentive pay shares a characteristic with at least four other well-established business practices — recruiting, performance appraisals, outsourcing, and software development — namely, the widespread certainty that when they don’t work, the problem is with the details of execution, not the fundamental concept:

Recruiting: As my friend Nick Corcodilos of Ask The Headhunter fame has been pointing out for years, the industry-standard recruiting practice of posting a position description, screening resumes based on skill-to-task matching, and so on fills fewer than one out of every ten open positions. And yet, most companies continue to pretend it works, even though, based on the numbers, it’s obviously broken.

Performance appraisals: Okay, I don’t have any documented numbers to back this opinion. Based on what I’ve seen, over the past few decades the performance appraisal process (really, practice) has become increasingly bulky and time-consuming for both managers and those they manage.

The payoff for the additional time and energy diverted to this activity? So far as I can tell, managers hate it, few employees find it valuable, and there’s no evidence that better employee performance correlates with more extensive and intensive performance appraisals.

Outsourcing: As documented in Outsourcing debunked (me, 2011), the only constant in the outsourcing industry is its failure rate. Commonly, three years into most outsourcing deals the contracting company finds itself either renegotiating their contract or terminating it altogether. Overall the numbers seem to show that between 30% and 70% of all outsources fail, depending on whose numbers you’re reading and the type of outsource they’re writing about.

But the numbers you read almost certainly underestimate the failure rate. Here in the Minneapolis/St. Paul metro, for example, it’s widely known that Best Buy is quietly unwinding its high-profile outsource to Accenture, but nobody in either Best Buy or Accenture publicly admits the whole venture was a failure.

Software development: For at least two decades, waterfall development wasn’t a way to develop software. It was the way, even though the way that preceded it (or at least one of the ways) — frequent informal conversations between business managers and programmers, with programmers showing business managers their results as soon as there was something to show and the business managers providing feedback that led to quick course-corrections — demonstrably worked.

I say demonstrably because the near-universal pre-waterfall outcome was stable, tailored-to-the-business, feature-rich applications, unlike waterfall, with its notorious 70% across-the-board failure rate.

Isn’t it interesting that when you read the Agile Manifesto, it sounds a whole lot like nostalgia for the pre-waterfall days?

At least with software development, as an industry we finally acknowledged that waterfall doesn’t work, although we needed a couple of decades dominated by dismal failure to accept this.

Too bad the Agile Manifesto hasn’t kept up with the times. It’s about software delivery to customers at a time when (1) there are no internal customers, and (2) the point isn’t software delivery, it’s successful, designed, planned business change.

Incentive pay, recruiting, performance appraisals, outsourcing, and software development. Five very different concepts. In all five cases, the business community has spent decades assuming the problem was with execution, not in fundamentally flawed concepts.

Here’s the irony: If an assumption was to be made, flawed execution was the right one. It’s the Edison Ratio in action.

Edison, you’ll recall, explained genius as being one percent inspiration and ninety-nine percent perspiration. Given this 99:1 ratio, logic dictates that when something goes wrong, it’s 99 times more likely to have been with the sweat than with the idea … with the execution, not the concept.

So the issue isn’t that business leaders, faced with failures, focused their attention on execution. Quite the opposite, this was admirable. It means they recognized that there’s no substitute for sweating the details.

No, the issue is how long it should take to figure out that the problem is the core concept after all.

In this, business leaders would do well to accept the advice of the source of so much wisdom, W.C. Fields: “If at first you don’t succeed, try, try again. Then give up. There’s no use in being a damn fool about it.”

Comments

|In: Architecture|Last Updated:

The Leaning Tower of Pisa, an otherwise unremarkable building, is famous for its bad foundation.

Some CIOs build their reputations on bad foundations, too. They insist on engineering shortcuts in the name of “business value” and “we don’t build technology for technology’s sake.” Some fail to understand that bad architecture creates a debt that will have to be paid off in the future, some do understand, and also understand that debt will be Someone Else’s Problem.

Others understand an important point about enterprise technical architecture management (ETAM) … one we’ll get to next week. But first …

The ETAM business case is that, as the first figure depicts, investing in engineering excellence and consistency now will pay dividends by reducing the cost of future projects.

It’s a perfectly reasonable premise.

If you’ve bought into the mirror-image concepts of federated architecture and buy-if-you-can/build-if-you-have-to application engineering, ETAM is a particularly big deal, because without it you won’t avoid the standard system interface progression — from “we need one,” to the familiar spiderweb, to the inevitable decent into the land of the hairball, where most of the effort in every applications-related project goes into making sure you don’t break anything.

“Federated architecture” sounds like an impressive solution. Sadly, though, while supporting technologies like EAI abound, no one has created an actual organized methodology for designing and managing system interfaces, with or without an EAI tool. If you’ve settled on a federated architecture, a large part of ETAM will be rolling your own.

The alternative to a federated architecture is building everything around a central software suite, usually ERP, that serves as the “source of truth.” Here, a lot of ETAM’s day-to-day impact will be making sure nobody touches the source code … that developers customize through either the configuration tools the ERP vendor has provided for that purpose, or through building satellite systems that hook into the core system through its defined APIs.

ETAM is like CapEx. Both are a matter of investing now to get a payoff in the future. In both cases what you invest in has to last long enough for its benefits to pay off the investment.

In the case of information technology, a lot of it does. “A lot,” though, is very different from “everything.”

Businesses don’t operate on a single timescale. In fact, they operate in four. As the second figure shows, they are:

  • Marketing time, where change in a slow-paced company might be on a scale of about a year, and in most companies ranges somewhere from a season to next month.
  • Product/service time: In many industries successful companies figure any product that’s been around more than three years is pointless; many operate as automobile manufacturers do, delivering new models every year.
  • Strategy time; which lasts as long as a reasonable business planning horizon. Unless you have a better crystal ball or operate in a more stable marketplace than most of us, three to five years is about it — beyond that there’s no real point in planning. Or even hoping.
  • Infrastructure time: Because most businesses have to invest significant amounts of capital in infrastructure … the physical plant, knowledge of the marketplace in which they operate, employee knowledge about how things really work (as opposed to managers’ knowledge about how they’re supposed to work), and its core information systems, their infrastructure has to last longer than their strategies. Much longer; ten years or more isn’t uncommon, as a look at your own legacy systems is likely to reveal.

Infrastructure creates an uncomfortable challenge for business planners. Those who create it have to make design decisions. These decisions will support some business strategies while placing significant constraints on others.

And because infrastructure lasts quite a lot longer than most business strategies, their design decisions cannot be “business-driven” in any serious way, no matter what platitudes business pundits like to utter about such matters.

Two more points about infrastructure and we’re done for the week. The first: Many additions to the infrastructure are unintentional.

Often, those who build these things expect them to be short-term improvisations intended to handle temporary situations. Then, temporary becomes business as usual, or they adapt and extend the improvisation for other, less temporary uses because that’s more expedient than the available alternatives.

The second: Even if you acquired every element of your infrastructure for free, that doesn’t make abandoning it for something else free, any more than moving out of a house someone gifted you to a better one is free.

Changing the infrastructure is always a costly proposition.

Comments