How NOT to make decisions

I should probably explain.



I work as a Test Engineer at a company that manufactures printed circuit boards (PCB's) for its clients. Part of the service we provide is the ability to generate test systems in-house to verify that the PCB's we assemble are working properly before they ship to the customer.



One particular customer that has a large volume of business with us has sponsored a combination of test benches, test fixtures, and test modules. Wait here while I draw a picture to define my terms.
.
.
.
.
...Drawing...
.
.

Ok, back.






As you can hopefully read from my masterpiece, the test bench is kind of a table that holds a bunch of really expensive electronic instrumentation that is controlled by the invisible computer. The key here is the test bench is fairly generic and the interface can be used to test a whole family of different products.

On top of the test bench is the test fixture. The fixture contains a number of components such as transformers, relays, filters, and communication circuits. The purpose of the fixture is to group together some related functions that are common to a particular subset of the product family.

The test modules fit in the test fixture. Each module is machined to be specific to exactly one product, and is basically a direct electrical transfer from the fixture to the specific test points on the circuit board that need to be contacted.

To review: One bench supports multiple fixtures. One fixture supports multiple modules. One bench tests an entire product family. One fixture tests a subset of the product family. One module tests exactly one product.

Back to the picture at the top of this post.

What is shown is a closeup of the interface between a test fixture and a test module. The fixture is on the bottom, and the module is on the top. The interface has a bunch of spring-loaded pins on the bottom side that push against a bunch of metal pads on the top side and conduct all the electrical signals that need to be transferred.

The reason I'm showing this to you is not to bore you to tears (as my wife believes). I'm interested in the conductor in the center foreground of the photograph, which has a red and a yellow wire soldered to it.

We use a fairly standard code for wire colors in test fixtures. Red is a voltage supply, black is a ground, green is communication, etc... yellow is a measurement. What we have here is a voltage supply and a measurement tied together, in the fixture. Is this a big deal? Let's see.

This group of products has a test sequence in which the system applies 28VDC to the device under test (DUT) and then takes a number of measurements that depend on the 28V actually being applied to the DUT. As a general rule, we design test systems to verify that the voltage being applied is actually on the DUT before progressing through the test, to simplify troubleshooting in the event of test failure. The simple way to do this is to apply the 28V to one test point on the PCB, and then measure it from a separate point on the PCB. It appears that for one particular product, there is only one good 28V test point on the PCB. That makes this test irrelevant because the supply and measurement wires are going to be attached together when they both try to hit the same point. We can verify that the power supply is on, but not that the energy is actually reaching the circuit board.

So what's the problem? These wires were going to have to be connected together, and they are.

The problem is where they are connected. Remember that the fixture is capable of testing multiple products depending on the module installed. In fact, new modules are being created to test new products on existing fixtures. Most of these products have plenty of 28V test points, and they should be making use of them.

What I have described is a breach of encapsulation. I'll make up my own definition here: encapsulation is the idea that decisions should be made at the place where there is the most information available relevant to the decision. In my long-winded example, it was a no-no for the test fixture to make the decision not to perform a true 28V measurement because that decision could have been made closer to the DUT. The fixture reduced the effectiveness of any test module placed in it, and no amount of wiring in the module could compensate.

What can we learn from this?

The principal function of the test bench is to supply resources to the test fixture. The principal function of the test fixture is to supply resources to the test module. The function of the test module is to direct the resources where they need to go. Any deviation from this pattern reduces the effectiveness and efficiency of the overall system.


Watch me now as I gently rotate the discussion toward what I'm really thinking: Leadership is a lot like a test system. The function of support roles is to enable decision-makers to make decisions. It is to provide a platform to maximize progress, not hinder it. The ultimate goal of leadership should be to create through sheer rubbing-off people who will make decisions at least as well as the person they learned from.

As the title of this post suggests, decisions are best made closest to the work they affect. If you are one of those people who is a step removed from the work that needs to be done, or if you plan to be one of those people, please please please remember that your job is to trust the people you have hired or recruited to make wise decisions. Yes, they will screw up and need direction. Yes, you could do it better sometimes. But if you want to get the most from them, eventually they have to have ownership of what they do and that means you providing resources and removing obstacles and otherwise staying out of the way.

Disclaimer: This opinion is not a reflection of my past or present employers. It is
based on observation of the industry I'm a part of and human organizations in general.
People tend to be dysfunctional. I'm not talking about you.