« Needs Are Not Requirements - A Failed Romance | Main | Defining Competency »

November 13, 2005

Competency: the Organization's Inner Self

We know a lot about automating processes, and we do it to improve performance. But performance is all about behavior, the best of which is the competency that drives performance. While processes represent ideal behaviors, do we really expect to automate behavior?

The painful lessons learned from earlier efforts such as "sales force automation" may never be appreciated by today's innovators in knowledge management, operational performance management and social networking -- business's new power rock trio -- unless they recognize the secret: technology works when people want to work, and it doesn't when people don't. This gives technology two jobs: one, make people want to work; and two, make the work fit the people.

That looks like something automation can do. The easiest and most prominent example is found in great automobiles. And amazingly, a lot of great automobiles are now fairly cheap. Yes, mileage may vary with the driver, but the drivers nonetheless do what they intend to do more confidently, as they interact with the car, the road, and other drivers.

In the particular context of improving an organization's performance, this precedent tells us how to open and unpack the phrase "automating behavior", sidestepping its hype. Expanded, it means, "automating the support of desirable dynamics." Usually there are two ways of doing this, used in combination. One is to implement design-level support (of behavior) as "structure". The other is to implement design-level support as "programming". Both efforts are aimed at injecting "regularity" (predictability) into the dynamics -- which is why in both the structural and programming designs we tend to search for, or even create, "rules".

Example: while trying to assess organizations in a "performance" perspective, the notion of "behavior patterns" becomes critical. A behavior pattern is at minimum taken as a symptom of the underlying structure and programming in the behavior. Discovering the pattern, especially an unexpected one, is exciting because it gives a persistent reference point for deciding what (if anything) to change. Basically, we want either more of the symptom, or less. For undesirable aspects, we refer to the pattern for exploring underlying modifications; with desirable aspects, we refer to it for exploring underlying automation. Either way, we expect to find that general rules underlie the occurrence of the pattern. We'll then have our "improvement" programming use (i.e. exploit) the rules.

Because of that, the most critical issue is whether we have discovered the rules or merely invented them. The importance of the rules is to set priorities and consistency to the actual activity. In supporting improvement with rules, programming holds our attention first and longer, perhaps because it is easier to manipulate than structure. But the specific importance of programming is to set limits and methods to the potential activity otherwise inherent in the dynamics.

In that approach, automation is just a programming alternative. Normally, maximizing and fortifying the persistence of desirable behavior is covered by training. Still, in large or decentralized organizations there's the idea that process automation somehow directly manipulates what otherwise would have been unmanaged behavior, and that it does so more certainly for our outward intentions.

In fact, thinking in terms of behavior versus process, the typical expectations are as if behavior's "innate" programming and structure is natural, while process is synthetic on both counts. But then, if we see behavior exhibiting the characteristics of processes, we think we can manage behavior through automation just as we would improve a process.

What competes with this is the idea of self-organization -- of behavior that, without other programming, manages itself.

As the pattern that is discovered, self-organization seems to be the tacit or latent organization. Managers are cautioned about it, about the "shadow enterprise" or the "backchannel organization" stealthily constraining or dictating success or change... Predictably, our new performance improvement frontier is in using programming to manage that -- to manage the inner organization towards the outward performance intentions. If this is going to pan out at all, the first thing to attend to is ensuring that we don't set out to solve the wrong problem.

Accordingly, there needs to be a way to distinguish the key components of the organization's performance make-up -- the "what is" of the organization that builds up the "how to" that it exhibits...

So, you're sitting in the coaches office, looking at the videos of the team that just beat your pants off. You're trying to codify what they do, and you're trying to figure out what makes them tick. Play by play, you can see how they do something, but you're seeing it after the fact... You struggle to come to grips with the apparent spontaneity that they used to beat you -- the stuff you didn't see coming. You keep asking yourself, how did they know, during the play, to do that, then?

Deconstructing the opponent's execution requires understanding how their organization gets its capability both from its formations (structure) and from its routines (programming). But no less important is understanding the real difference between what seems to be ad hoc or natural, versus what is planned or synthetic. This much segmentation pulls up discrete factors that are clearly subject to independent changes but will continually interact to produce the observed results. They're the same factors that will describe the organization you are or want to be.

In attending to those factors, improving and leveraging them towards more effectiveness in their interactions, the definitive programming approach emerges -- that we should think first of cultivation, not automation.

Overall, that target effectiveness is, in real-time demand, the competency of the organization. Cultivating competency becomes the label for an objective that might otherwise be presented as "maturing capability" or "automating process".

In general, these different efforts should be complementary, as seen below.

But this model clearly allows for three ways to tackle a single thing. That is, the whole model could be applied to improving a capability in three ways, or a process in three ways, etc. This leaves us to think about why, for example, a process is different enough from a capability or from a competency to result in them being usually associated with different parts of the improvement model.

Meanwhle, as companies begin to look at social networking to discover and leverage their "inner organization", these companies will need to temper their excitement at the discovery of those behavior patterns with a reasoned approach to making use of them. The most obvious challenge is to first understand the communications protocol that is embedded in the social network, which is of course a behavior issue. Moves from behavior to process may or may not prove to be actual, agreed, consistent or preferred. Additionally, exposing a network may provoke it to change or discontinue before it can be engaged in any pragmatic fashion or agenda other than its own. It is therefore very unclear as to whether automation or maturity are even relevant formal management concerns until after cultivation of the network has been identified as a desirable opportunity.

Posted by Malcolm Ryder at November 13, 2005 8:02 AM

Trackback Pings

TrackBack URL for this entry:
http://www.malcolmryder.com/cgi-bin/mt-tb.cgi/160

Comments

Post a comment