Fault Follows Leverage

From Zanecorpwiki

AKA: Shit rolls downhill.

One of my products is a fraud detection system for financial institutions (FIs). On of the features of this system is the ability to call out to external servers in order to retrieve a check image. Most FIs have such a server that will respond to a query like codeserial=123date=01/01/2009/code with the image of a check.

The only interesting thing about this feature is that all the image servers have different ways of accessing the check, so we developed a little format string so that you say something like codeserial=%serial%date=%effective date%/code, which would generate something like the query example given earlier.

We got a report from one of the FIs that the images were not being pulled up for some images. A guy--I'll call him M.--at one of the FI's service provider figured it out. Turns out that when a parameter was not available for an image (usually due to OCR problems) our system would produce something like codeserial=123date=/code but the image server would only produce an image for codeserial=123/code.

Now, the second style of string is arguably better, but in this context they both would be interpreted the same way. In fact, the reason we put an empty parameter in the string--as opposed to omitting the parameter entirely--was due to the fact that a different bank's image server requires it that way. In other words, some image servers want it one way, some want it the other.

To be fair to image server coders, I'm sure some, if not many, would actually work with both strings. This is clearly what the image server should do. Thus the underlying is actually with an unnecessary narrowness in what the image servers will accept and has nothing at all to do with my code.ref group=notesI'm implicitly discounting another alternative that the problem lies with the URI specification. A full understanding of the specification, it's goals, and how parameters are parsed and used makes it clear in my mind that the spec is fine. Furthermore, as a matter of practicality, we pretty much have to accept the spec as a starting point given who is involved and the timescale of the problem./ref

The point of all this is that the real problem doesn't often matter much. The FI had less leverage over the image server people that they did over me, so the problem became defined not by engineering, design, aesthetic, or business considerations, but by the one simple question of who was easier to whip. The FI/service provide had more leverage over me than they did over the image processing company so the fault flowed to me.

This means people and businesses often get blamed for the wrong things. Sometimes, the way this is done is completely cynical; the party assigning the blame knows full well that the scape goat is just that--an innocent cynically sacrificed to shift blame from others.

Often, it's just a kind of laziness. We know at some level that it'll just be easier to get that one guy to fix it, even if he didn't do it.

In some cases, the assignment of blame is completely innocent even if ultimately misplaced. In my own example, the guy that found the problem is one of the sharper banking IT guys I've worked with and he wasn't trying to blame or bully me in any way. I believe he was being perfectly polite.

What instead occurred was perhaps the most frequent way in which fault follows leverage truism manifests: it was purely definitional. There are all sorts of things which can go wrong in our lives for which we are not responsible--meaning both that we didn't cause it and we have no power to fix it. At these times, we naturally look to get things fixed as quickly as possible and with as little personal effort because, in fact, it wasn't our fault so why should be spend time on it? Perfectly valid and reasonable.

The problem is that we implicitly think of fault itself in terms of our hierarchy of leverage. The people that we can get to fix the problem are by this definition the one's who are responsible for it. Because most of us are not so subtle, we don't bother to think about whether this responsibility means the one who should fix the problem or the ones who caused the problem. In a sense, it doesn't matter and we don't care.

As a person in with say in assigning responsibility, it is therefore important to keep a few things in mind. First, don't abuse your leverage. This usually is not a problem unless one is cynically assigning blame to CYA, in which case their unlikely to be swayed by my assertions here because they know what they do and choose to do it anyway. These have deeper problem than superficial ignorance; they have deceived themselves deeply.

Second, don't be lazy in your assumptions about who is to blame. This also mean that one must be careful about implying blame by assigning responsibility. You can usually get away with doing so because, by definition, you have the leverage, but that can always change. Even if you foolishly believe that power is static, there is little point in souring a relationship and poisoning a resource.

Those in positions of power--by definition--assume the greatest responsibility and so therefore bear the brunt of assuring that correct communication and relations are maintained in these situations. At the same time, those who may receive blame are not blameless if they do not push back and provide clarification. Finally, those that are truly blameworthy, though and because they are the least pressured in these situations, take it upon themselves to own the problems which most properly belong to them.ref group=notesI believe that some companies and individuals do take this stand. It is difficult, however, to convince customers to exert the effort to communicate potential problems to all stakeholders when the customer knows they can just leverage another party to take care of it./ref

Notes

references group=notes /