Infinite Solutions
Answers to problems abound, but the questions are elusive.
High-tech companies pride themselves on their ability to deliver solutions. Firms feel useful – and justified – by doing so, thereby serving humanity. They want you to know that. The effort, or the splashy publicity emanating therefrom, ennobles them, so they think. This satisfies a certain insecure technocentric mindset, needing frequent validation. Touting solutions drives tech companies’ marketing; it trumpets, for all to hear, their reason for being. Quite an impressive spectrum, those solutions. Just sample the advertising. The magic word isn’t hard to find; in fact, it can be overwhelming in its ubiquity, in multiple languages: “Offering cost-effective solutions to the EMS industry since 1984.” “Your solution partner.” “Complete inspection solution.” “Produktloesungen.” “Innovative solutions at your fingertips.” “Soluciones Integradas.” “Creating solutions.” “Cleanroom and containment solutions.” “X-ray inspection solutions.” “Optimale systemloesungen.” “Advanced switching solutions.” “Bespoke solutions.” “Providing today’s solutions for tomorrow’s products.” “Custom NDT solutions.” “Your partner in embedded solution.” “Reliable climate solutions.” “Network connectivity solutions.” “Integrated boundary scan test solution.” “The solution to America’s problems is a big, beautiful wall.” “Customized solutions.” “Integrated test solutions.” That last one’s catchy. Bottle it.
Good heavens. Who knew there were so many problems requiring solutions?
The engineering mind, being well-ordered, when confronted with a problem, naturally seeks a solution. The more elegant the solution, the more celebrated. In certain quarters, if you are a hammer, you go looking, metaphorically if not literally, for a nail. Pity the nail. Better to be on the delivering end rather than the receiving end. This is not so much a solution as an obliteration. Think Bomb, Atomic. It’s not the assault that convicts; rather, it’s the battery, but at least there’s a resolution (there’s that word again, hiding in a bigger word), even if the resolution is more uniformity and less independence. Pay no attention to the bloodstains.
Breaking eggs is justified because a solution is reached, squeamishness notwithstanding, and wisdom, if not equilibrium, is achieved. We have an abundance of such ends-justifying-the-means-style individuals within 50 miles of San Francisco. We of the region are so blessed.
Offering a solution, it must be added, presupposes there’s a problem to be solved. Or invented (self-driving cars come quickly to mind). By the geeks. Because they can. People who are predisposed and (so they think) uniquely qualified to solve problems. That’s why the Predisposed are visionaries. Many of the rest don’t have the technical chops to contradict their wisdom. Of course, many solutions also go in search of a problem. The marketing buzz highlighted earlier suggests this.
Except, we no longer have problems. Problems have taken an enforced hiatus.
We now have “issues.”
We don’t solve problems anymore. We address “issues.”
Why do we have “issues?” Undoubtedly because it’s an easier word to spell and pronounce than “euphemism.”
And because there is more to an engineering organization than engineers, and those people fill up space and, especially, time, administering stuff.
These specialists need something to do with their, ahem, abundant skills.
Perhaps it also has something to do with our all-too-human, non-engineering tendency to avoid tackling problems head-on. We’re mini-politicians that way. It may also owe something to the wish among many to avoid direct confrontation when it comes to controversy. “Admiral Kimmel, the Naval Review Board has several issues with your decision to play golf the morning of Dec. 7 at Pearl Harbor Country Club.” “President Lincoln, it has come to our attention that Mr. Booth may have had an issue or two with your treatment of the South. That little disagreement notwithstanding, it was a splendid play, wasn’t it?”
Program managers are one non-engineering subspecies offering solutions. They are supposed to know what’s where on the production floor. We test engineers are privileged to deal with EMS program managers daily. They often are our first point of contact in routine activity. They are also, and usually, the point person with their own OEM customer, so they have information coming and going. It is the responsibility of every program manager to know the exact status of every order in their charge. Always. No excuses. Not that the MRP system is down. Not that distribution just pushed out 14 weeks on the hard-to-get FPGA. Where is the order? Walk out on the damn floor and open your eyes. Hewlett and Packard used to call it MBWA (Management by Walking Around). Otherwise they shouldn’t be considered competent program managers, much less problem-solvers. So why are so many program managers pathologically incapable of telling us the inbound status of a test job? Because they are preoccupied fielding “issues.”
Until it hits our back door, with no notice. Not even so much as a heads-up. Program managers we’re acquainted with recognize this telepathically, because eight nanoseconds later, the program manager, or their surrogate, is on the line, anxiously demanding to know when it will be completed and available for pickup. (This assumes their driver hasn’t already grabbed a cup of coffee and made himself comfortable, deftly scanning the sports section in the lunchroom until the moment of deliverance.) Some get indignant when told it isn’t done. (Such impudence!) Mind you, no prior warning it was incoming. Now the fate of Western Civilization, clean water, proper hygiene, and perfect pitch hangs in the balance with its timely completion. Timely defined by them. That’s their solution to this problem: Move faster. Until then, and until completion, we who do the testing are the “issue.” See how responsibility is delegated? It ceases to be the program manager’s problem.
We need to know the status of incoming jobs. So why can’t many program managers slow down, sit still for a moment, answer a quick email, so we know exactly what they want? It’s tough to offer a solution when you don’t know the requirement (especially when you aren’t paying attention). It’s hard to commit to them when they won’t commit to you. But we test guys remain the issue just the same, until we’ve finally finished the incoming job whose status between them and us we don’t know. But you can be sure it’s hot. About that there is no issue.
It’s also challenging to offer a constructive solution when either the customer doesn’t want to hear it, or the salesforce doesn’t want to deliver the unwelcome message. Bad news has an immediate impact. All it takes is one 26-week lead-time part to grind a $200,000 build to a complete halt, meanwhile burning a hole in corporate cash flow. I know a career operations manager whose sales team would not let him come anywhere near a customer in the flesh because he had the disquieting habit of telling the truth. He did so to avoid burying issues (pardon the expression) like the one described in the previous sentence. The sales guys preferred using shovels and assisting with the burying.
It’s also cumbersome when your job is being scrapped, repeatedly. Each wipeout was caused by “issues.” I’ll say. Sometimes it starts simply with the low bidder getting the job. That’s an issue. Take the case of the aerospace board that was quoted for flying probe programming and testing in September; purchase order in October; boards promised in November; again in December; scrapped in January; restarted in February; put on hold in March; restarted in April; finished in May (four different ship dates and times from the assembler). Then the blessed and much-anticipated bundle arrives on our dock, followed by that inevitable telepathic call: “You will have it done by the end of the month, won’t you?” Right before we discover the entire board has been covered in conformal coating, most distressingly those pads and solder joints to which our test probes are supposed to make intimate electrical contact. Another issue.
“Management has met and decided that, in view of the unique issues accompanying this build, testing will be waived. The customer has been kept fully informed.
Please return the boards to us for disposition.”
Eight months. Nothing accomplished. Funded by Mr. and Mrs. America’s hard-earned tax dollars, without their permission or even knowledge. You bet there are issues.
Let’s get one thing straight: Issues are for politicians to debate. “Issues” at the EMS level conveniently mask screw-ups, misunderstandings, bad information, poor coordination, insufficient knowledge, process shortcomings, basic cowardice or plain old incompetence. Call them what they are.
It’s a truism to say we often get what we pay for. Sometimes we get it, good and hard, issues or no issues. We get every problem we deserve, with a lesson thrown in for good measure.
One lesson is this: Obfuscation, the deliberate intent, notably in business settings, to advantageously obscure the true state of affairs, is a problem in desperate need of a solution.
I have no issue with that.
is president of Datest Corp. (datest.com); rboguski@datest.com. His column runs bimonthly.
