top of page

About marginalX

Help teams bring complex systems from proven concept to production

JLewisPhotoTransparent.jpg

Jay Lewis, the principle consultant, taught himself computer programing in high school and was fascinated by the book "Cheaper by the Dozen" about growing up with efficiency expert parents Frank and Ernestine Gilbreath.  After graduating with an electrical engineering degree he helped redesign aircraft electronic systems using Value Engineering(VE) principles. He then became a Design For Six Sigma (DFSS) Black Belt teaching and coaching dozens of engineers across many disciplines to use statistics and other tools to solve hard problems faster. From there he helped develop medical device manufacturing processes to improve reliability and yields. After that he was the system engineer for to develop utility scale solar power using sterling engines and giant mirrors. His last role before becoming a consultant was helping develop and manufacture the VS3 communication satellite called the "Mythical Beast" by competitors that said it would be impossible to do so much with so little.

marginalX was founded to help small technology companies do more with less. The name refers to three kinds of margins. Eventually investors expect there to be a profit margin, even if it is slim that can be reinvested to exponentially grow.  Engineers seek design margin to ensure everything works as intended even in borderline cases.  Program Managers have schedule margin to handle contingencies. Rather than see the saying "Time, cost and quality – Pick two." as a constraint, what if we view technology innovation development as a process that can also be optimized?

For example one tool for risk management is the FMEA. This is a systematic technique for a team to identify risks and brainstorm ways to mitigate them.  In practice it can get bogged down into a long, time consuming, tedious process that leads to no improvements if started too late. When used at the earliest opportunity many issues can be eliminated before causing a cascade of extra expenses, delays, and customer impacts.  

A core value is to reduce every kind of waste. Over engineering is as bad as under engineering because it drives up development costs and delays shipping to customers.  The optimal program delivers a marginally acceptable product barely on time and almost out of funds. Realistically the more innovative aspects of new technologies are also the least predictable so it is be prudent to aim for more than the minimal margin in some areas.

Clients and Employers

Current, past, and recurring

iSpace

Lunar robotic spacecraft

11-50 Employees

<stealth startup>

Space resource harvesting

11-50 employees

Mainspring Energy

Linear power generation from renewable fuels

101-250 Employees

Zero Mass Water

Extract drinking water from the atmosphere with solar power

11-50 Employees

Viasat

Satellite communications

1001-5000 Employees

Stirling Energy Systems

Grid quality concentrated solar-thermal power

51-100 Employees

Honeywell

Avionics design and manufacturing

10001+ Employees

US Air Force

Global military air superiority

10001+ Employees

mFMEA

The marginal X FMEA story

When Honeywell embraced Six Sigma I was a value engineer managing several projects at a time.  This made me a natural choice to pioneer the Black belt program in "wave 0".  There were several tools we all had to use and demonstrate competency to the Master Black belt.  One of these was the "Failure Modes and Effects Analysis (FMEA)", which could be applied to design or process improvements.  It was the only tool I hated. The people I worked with didn't like it either, but after a week of meetings we had a list of things to focus on.  We then took a few months to knock those out and estimated the benefits. This was unlike most of the other tools.  All of the benefits were hypothetical since most of the changes were eliminating issues that had yet to happen.  For most Six Sigma projects there is some baseline problem such as "90% yield, with 9% rework and 1% scrap".  The rework almost doubles the labor and the scrap for expensive aerospace computers is pure loss.

Once I was a certified Design for Six Sigma Black Belt.  I taught classes to 100s of engineers and engineering managers.  FMEA was one of the tools I taught.  Explaining it to others and answering questions and objectives quickly helped me understand its strengths and limitations. I then helped over 50 engineers get Green Belt Certifications, with FMEA as one of the tools some used.  As a proactive tool it was good for new processes, perhaps 9 cases, maybe 3 times for a new design.  

From there I went on to being a Continuous Improvement Engineer at a Medical Device Company.  We developed a new manufacturing method to make implantable Defibrillators more reliable, faster and lower cost. Most steps of this process were innovative and we did an FMEA on each. The company had an established method that met met ISO14971.  Naturally as someone improving processes as a way of life, and asking engineers and managers to rethink how they do things, I applied this to my own work and streamlined the FMEA process.  As a result the Director of Reliability Engineering was unhappy with how I did it. When I walked him through the thought process and showed how it got the same (or better) results despite taking a fraction of the time he, he became excited.  

My role was a Senior System Engineer for a renewable energy startup. The System Engineering Director owned the design FMEA and followed a standard process. We applied this at the system level and for every electrical and mechanical subsystem.  An innovative use I learned from him was to treat the lowest ranked risks as opportunities to simplify the design. In many cases there is a tendency to over engineer to mitigate every possible risk, but sometimes the risk being mitigated is smaller than the cost of mitigating 100% of the units. Perhaps that non fatal rare event that is only another minor repair can be tolerated to eliminate an entire mitigation sub system.  My addition to the process was to make it the foundation for software requirements.  As software makes hardware ever smarter it becomes more integrated, both for mitigating risks and introducing new ways things can go wrong. 

My next role was Lead System Reliability Engineer for a Geostationary Satellite.  The other space program FMEA examples were somewhat primitive and reflected the legacy space reputation for being stalled in the 1970s. We had the mandate to design faster than anyone in the industry thought possible and I embraced this opportunity streamline even further to cover the system and payload subsystems.

I later realized this method could benefit far more startups that may be avoiding it from having experienced the tedious unproductive versions often found in larger companies.  

bottom of page