HomeLeadership

Silo metrics

Like Tweet Pin it Share Share Email

Where exactly did the term “silo” come from, anyway?

Organizational silos are Bad Things. They create barriers to getting work done. But why silo? What does a building used to store grain or a nuclear missile have to do with branches of the organizational chart? But then, I wonder how agribusiness executives respond to the idea of breaking down their silos. For that matter, I worry about using “lowest common denominator” when we should be saying “greatest common factor,” so what’s that tell you?

Speaking of the relationship between mathematics and organizational silos, let’s talk about dashboards, business metrics, and how they should and shouldn’t fit together.

“Metric” is ConsultantSpeak for “measure.” Some use “metric” to refer to the formula and “measure” to the result of each act of measurement. Since the ontological battle against “metric” is long since lost, let’s agree to accept this distinction.

Good metrics start with goals and end with fine tuning, and not, as some consultants lazily suggest, with industry benchmarks or other forms of meaningless tradition. Figure out what you’re trying to achieve, develop an observational way to determine whether you’re making progress toward it — preferably in numeric terms — and then make sure there’s no way to manipulate the measures so they improve while the actual situation deteriorates.

A popular addition to metrics lore is the dashboard. Unlike “silo,” “dashboard” is a useful metaphor, which is to say it nicely illustrates the point. When you want to know how your car is doing, the dashboard tells you, at a glance, whether your car is healthy and progressing at the right speed toward your destination. A well-designed business dashboard helps you understand how healthy your organization is, and whether it’s progressing at a fast enough pace toward its destination.

So far, so good. But when designing dashboards, most consultants, and as a result many managers, fall into a trap: They think the point of metrics is to Hold People Accountable, and so they design a business dashboard whose gauges are each tied to a branch of the organizational chart, or where individual manager results roll up to the whole organization’s results. Since you get what you measure, the inevitable happens — each manager does whatever it takes to move his or her measures, almost always hampering the ability of other managers to achieve their metrical responsibilities. Bad dashboards, that is, cause silos (which, if you have a bizarre and twisted mind, means the bad use of a good metaphor causes a bad metaphor).

Criticizing other consultants is fun, and possibly good for business, but knowing how to build a bad dashboard doesn’t do much to help you build a good one.

When our company works with clients on this subject we start with our handy-dandy IT Effectiveness Framework, which enumerates four major factors that drive IT organizational effectiveness: Business Alignment, Process Maturity, Technical Architecture, and Human Performance. The CIO establishes a clear goal for each, based on what most needs to be addressed in his or her particular situation, and formulates one or more metrics for each goal, so as to assess progress.

Each of these factors has a number of sub-factors that make it work. For example, technical architecture depends on the platform (IT infrastructure) architecture, information architecture, and applications architecture. The CIO often defines goals and metrics for this level as well. (So far, nobody has wanted to develop goals and measures for all of the 138 factors we’ve identified that drive IT performance, but hey — if you’re willing, we’re willing to help.)

At the dashboard level of analysis, no one manager is logically accountable for how well the measures come out. The director of Application Support can’t, for example, improve business alignment single-handedly, nor will averaging the business alignment scores for Application Support, Operations, and the rest of IT result in a meaningful number. What Application Support can do is define its goals in ways that support the organizational strategy, including its business alignment goals, and then one or more metrics to assess progress toward the Application Support goals.

It’s a simple principle. If your goal is teamwork, define organizational goals that require interdependent effort. If, on the other hand, your goal is to Hold People Accountable, establish independent goals. And metrics.

Oh, and while you’re at it, you might as well add a siloization meter to your dashboard, because that will be the most visible outcome.

Comments (1)

Comments are closed.