The first case was the so-called “Red Bird,” which actually begins with another bird: the “Blue Bird.” This Blue Bird is none other than the F15 plane that the United States ordered from a warplane manufacturer. In this case, the manufacturing company exceeded the U.S. government’s requirements, and yet some people were not satisfied with the final result.

These people were Harry Hillaker, John Boyd, and Pierre Spray. Boyd was familiar with fighter planes because he was a pilot, and he was one of those who proposed that another plane should be made: the Red Bird. Boyd stated that the design should be agile and cost-efficient. Therefore, following these guidelines, they achieved an aircraft that was significantly smaller than the previous one and that didn’t even have all the advanced systems of the F15.

Except for one thing: the command control. On the Red Bird the control resembled a joystick, and the reason was that it meant less weight for the plane than previous controls. This is one case, as Mr. Jodal pointed out, where technology was used because it was required, not because they wanted to use the latest development.

Finally, more than five thousand units were produced of this plane -which later became the F16- when the previous one did not exceed 700. Simplicity and agility prevailed. From here Mr. Jodal drew three lessons: you have to be clear about what you want, that is, design; you have to use high technology when you need it, not when you want to.

The second case also has to do with aviation: nine dollars an hour. Jodal reminded the public that a few years ago there had been a couple of accidents with commercial aircraft manufactured by Boeing: the 737 Max.

In both cases it was discovered that the planes, shortly after taking off, made an oscillatory flight that caused their fall. After the investigations, the inspectors realized that this was due to the aircraft software. What had happened? Boeing had installed software on the aircraft because it needed pilots trained on an earlier version of the 737 to be able to fly the new Max. The software made the Max behave as if it were the previous version of the aircraft, so it was not necessary to train the pilots in the new features of the new aircraft.
However, the software wasn’t perfect. It had errors that caused the computer to believe that the plane was going up when it was actually going down, and vice versa. The oscillatory movements later detected by the accident investigators were, in fact, the result of the pilots' struggle against the software to stabilize the plane. When they couldn't make it, the plane went down.

Boeing didn’t use software, so they commissioned that work from a company that was able to do it quickly and at an affordable cost: nine dollars an hour.

The lessons drawn by Mr. Jodal from this example are the following: you have to bet on software as soon as possible; Boeing was late and therefore had to hurry and hire a third party. A second lesson is that making software is not easy; and the third lesson is that nine dollars an hour can be very expensive.

The third case is the one he called Everything for the 2% and it takes place in the finance world. First, he provided some background.
Everything is based on trust, including money. When we pay with a certain currency, indirectly we are stating that we trust the solvency of the government that issued that currency. But with the economy’s development, other means of payment appeared, such as the check. When we receive a check, indirectly we are stating that we trust the bank that issues it.

The means of payment continued to evolve up to the credit card. And here, Mr. Jodal makes a distinction: when we accept a credit card payment we are not implicitly accepting that we rely on Visa, MasterCard or the firm that issued the card. We trust the bank that gave us the card, that is, the card issuers have been built on the trust you have in the banks.

Something similar happens with big techs (Google, Apple, Samsung) when they launch their means of payment. They build on your trust in credit cards and banks. And people accept them because paying with the modern payment methods proposed by these companies reduces commissions and friction in payment.

In addition, Facebook also wants to enter this world and has done so through a crypto currency: Libra.
But Libra has an issue: will people trust Facebook?
To overcome this 'challenge,' Libra is not just Facebook, it is actually a crypto currency based on the prestige of a group of companies - and to be part of this group they needed a market capitalization of at least one billion dollars - which, for now, totals 28 but is estimated to reach 100 by 2020.
These firms include Facebook Calibra - a company that claims not to share data with Facebook-, Visa and MasterCard, Mercado Pago, PayPal, Stripe, Lyft, Uber, eBay, among others.
There are many companies and the interesting thing about them is that none of them is a bank, the entity that generally charges 2% for a payment transaction. Will this be good for the project? That remains to be seen.

Some conclusions or lessons can also be drawn from this. First, Facebook preferred to yield control over the crypto currency to encourage its use; and it has also used technology (Blockchain) because it needed it, not because it is fashionable.
What do these stories have in common? They teach us that agility is more important than speed, and that culture change is necessary in organizations for them to fully realize that we are in the age of software, APIs and platforms. In addition, we can also follow the path of Facebook, i.e. yield control in the best interest of a proposed initiative.




*Thank you CIO Perú for the coverage.