So, why did I leave a rather comfortable salary job at a large computer/IT company to work independently?

My Goal: 

Mathews Technologies exists to fix your technical problems with lean, high-value, high-quality engineering solutions.  

Career Highlights:

Over the last 25 years I've had a lot of very interesting projects.  Most of the time I've made my customers very happy people.  Here are a few of the highlights.  (If you're a former customer of mine, I hope you recognize some of these projects... although I may describe them a little differently than you'd expect).

 

Walmart Shopping

High-value is usually not rocket science.  I spent a good bit of my career making radical improvements to one customer's test engineering practice.  At some point they had resigned to inventing entire computer and IO systems in-house.  I can't say whether that was a good decision at the start, but they became so entrenched in their legacy that they forgot to include emerging technologies.  I worked within their system for a while designing circuit boards.  While I enjoyed the work (a lot), it wasn't profitable for my customer. 

Honestly, I didn't bring them tremendous innovation. I only convinced them that other off-the-shelf technologies (in both hardware and software) would actually do the job.  The first project grew into a series of projects that grew in to a team of engineers.  Our hunt to simplify the technologies became so fervent that one of the team slogans was "buy it at Walmart"; meaning, look for solutions and components that we could easily buy instead of invent.  By the time I left that account the tests were simplified... radically.  In rough numbers, delivery time was cut by 60%, design complexity cut 90% (as measured by both wire count and design prints).  And the real pay-off... equipment down-time was cut 90%.  Repairs which previously required engineering support were routinely handled by the skilled trades shop.  At the same time we added onboard diagnostics, statistical monitoring, extremely powerful signal analysis, and more flexible test scripting.   

 

Strange Accolades

A machine with flakey memory plagued an assembly line causing frequent trouble tickets to reload its program.  Each ticket took a couple hours to complete, which had both electricians and supervisors equally frustrated.  The principal electrician for that line was told by the resident engineering staff that nothing could be done.

I wasn't in a position to replace the ailing machine, but I was working on an adjacent processor that connected to it.  I spent a few hours adding a feature to my machine that monitored the health of flakey machine and emulated the loading process automatically as needed.  I've had some strange accolades in my career, but one of the tops occurred a month later when I revisited the plant.  As I walked down a nearby aisle, I was accosted by that electrician with a drive-by hugging.

 

Not My Problem

Simply owning a problem can be the fastest way to help a customers, even when it's not necessarily my expertise.  One of my earlier jobs in manufacturing was to install a new test cabinet on a line that was falsely rejecting between 5% and 30% of the products going down the line.  In the middle of commissioning this machine, I discovered that the old test cabinet was not the problem at all.  Seven months earlier the original engineer on this project had assessed it to be the problem, when in fact the root cause was just the tooling connector that hooked up to the parts.  It wasn't designed to make a reliable connection.  This problem had plagued the line since it was first built.  I'm not a mechanical designer by trade, but with the help of a pretty sharp tool maker, we adjusted the design, re-tooled the connector and had a fix in-place by the next morning.  The false rejects virtually disappeared.  The customer saved more than $5M per year off of that change alone.

 

Ok, Partly My Problem

I visited a facility in an Indiana corn field that was getting ready to shut down because they couldn't find a vendor to replace a machine that was nearing obsolescence.  It was late spring when I visited, and for some highly technical reasons they were going to be out of business on Labor Day if they didn't get a retrofit for that machine's controls.  Every instinct in my brain declared that this project was a blood-bath and that I should no-quote the business.  Instead, I counter offered with a bid of essential things we could deliver by Labor Day, followed by a series of improvements that would meet their long-term needs.  The plant stayed open; my team didn't take a beating, and it turned out to be a great, long-term relationship.

 

Good People are Easy to Come By

I didn't do most of this stuff on my own.  I've been blessed to work with a lot of very bright people.  The good news is that I've discovered that they are the rule, not the exception.  Most people wake up in the morning wanting to do a good job; the trick is helping them find a job they're good at.  If you're one of the people who have work with or for me, "Thank You". 

 

Details, Details

I wish every problem had a simple solution, but it's not always so.  Working in an OEM's product design team, I was given the task of doing the failure analysis on one of the more complex sub-systems.  It was a very mechanical beast that could conceivably take on upwards of 25,000 unique states.  The internal mechanisms had some very sophisticated on-board diagnostics which one may believe would help my job.  As a member  of the diagnostics team I took the burden of considering every possible condition.  That wasn't easy, but it's a good thing I stayed awake for the whole project.  It turned out that there were 3 states in the system in which the diagnostics were flying blind.  A particular failure in each of those 3 states would have exposed the end user to bodily harm.  It wasn't fun, but saving people from injury (not to mention my customer from liability) made my personal highlight reel.  The pain from that effort prompted my first solo patent to automate a method of state machine analysis and risk mitigation.

 

Fun, But Not Recommended

I've also done a few strange projects.  They were fun and illustrate niches that sometimes need to be filled... but I wouldn't recommend these without some unusual business needs.

- Programmed test system to double as PC-based machine controller for a 4-station dial.

- Re-programmed the firmware on DSP boards to make smart signal generators and high-speed signal capture.

- Designed circuit boards to do signal isolation and analysis.

 

I.T. S.W.A.T.

My first passion is in engineering, but I've had a number of projects in IT that required a general-purpose problem solver who could adapt a mix of standard technologies and custom tools to fulfill a non-standard role.  The most recent was a SharePoint farm migration that included very specialized strategies for site structures and permissions.  Normal migration tools could handle the heavy lifting but this project needed more.  The complexity of the task combined with the sheer size of the farm required customized migration planning for each individual site collection.  Good project planning alone wasn't enough, we had to develop a custom toolset to minimize error-prone manual operations while simultaneously gaining efficiency.  We also had to control costs by using a remote, low-cost resource pool, so the overall process had to be optimized and tested and aggressively managed.  It finished two weeks ahead of schedule with almost no trouble tickets.

 

Under-Cover Engineering

Really.  One customer had a dispute between 4 vendors that spanned 3 new assembly lines in their central Mexico plant.  The lines were nearing a production readiness deadline and their state-of-the-art controllers were rebooting randomly.  The software vendor blamed it on the contractors, one contractor blamed it on the computers, another contractor blamed it on the software, and the computer company blamed it on the contractors and the software.  I was sent in under assumed credentials so I would carry the weight of the corporate headquarters with everyone involved.  I had two handlers and not even the plant manager knew I was another contractor.  My mission (and I chose to accept it) was to isolate the root cause of the erratic behavior and get the responsible vendor to acknowledge it.

There's no moral to this story, it was just a very fun and strange project. 

P.S. Choose your own ending:

     a) The computers were spec'd to perform at much higher temperatures than their consumer-grade chipset.

     b) The butler did it.