How things change. Two of my blogs from last March need updating.

Arkansas Medicaid Work Requirements

I wrote about how Arkansas’ implementation of work requirements for Medicaid was designed so poorly that it disenfranchised 18,000 recipients. Obviously, it was designed with little to no concern for the recipients, but instead was designed simply to save money for the state. Last Friday, the New York Times reported that “a three-judge panel of the United States Court of Appeals for the District of Columbia Circuit found that approval of the Arkansas work requirement by the health and human services secretary, Alex M. Azar, was ‘arbitrary and capricious’ because it did not address how the program would promote the objective of Medicaid as defined under federal law: providing health coverage to the poor.” The article continued, “even many Medicaid recipients who had jobs there were either unaware of the rule or confused about how to report their work hours to the state every month.” Oops.

Boeing . . .

If you read my blogs, you know that I’m a bit of an aviation geek and a big fan of Boeing, which has delivered incredibly reliable airplanes for decades. So in the wake of the 737 Max disaster, one has to ask, “What went wrong at Boeing?” Hard to say without being an insider, but parsing through the news reports, I get the impression that the longstanding culture of safety and quality first was compromised in order to rush the 737 Max to market. Boeing was feeling threatened by rivals in the single-aisle jet category and needed an update to the 737. They replaced the existing engines with newer, more fuel-efficient engines. This was obviously a big selling point, but it changed the aerodynamics of takeoff and landing. The software (which, along with a key sensor, proved faulty in the end) was designed to compensate for that.

Two lessons here, I think: First, we all know that product development is all about tradeoffs. Quality and time to market are often opposed to each other. In this case, Boeing felt pressured on time to market and dropped its longstanding safety and quality first approach to product development. The consequences were fatal, and the damage to the company is substantial.

Secondly, we all face choices about when to rearchitect an old product vs. doing a short term fix. The latter is faster in getting to market but tends to lead to problems in the field. This is not only a hardware problem; it happens all the time with software as well. Companies struggle with this decision all the time. It’s worth taking a long-term view when making a tradeoff analysis.