Beneficial Intelligence

In this episode of Beneficial Intelligence, I discuss irrational optimism. IT people are too optimistic. It is a natural consequence of our ability to build something from nothing. Our creations are not subject to gravity or other laws of physics. A builder cannot decide halfway through a construction project that he wants to swap out the foundation, but IT regularly changes the framework in mid-project.

Similar optimism informs our project plans. For some reason, we assume that everything will go the way we plan it. Fred Brooks first wrote about programmer optimism in his classic "The Mythical Man-Month" back in 1975. He points out that there is indeed a certain probability that each task will be completed on schedule. But because modern IT projects consist of hundreds of tasks, the probability of every one going right is low. Even with an unrealistic 99% chance of success, having only 100 tasks reduces the overall probability of all tasks to finish on schedule to 37%.

Sadly, our irrational optimism also extends to the business cases we present to management for our projects. I am regularly presented with drafts of investor presentations that hopeful startups want to pitch. The optimism is palpable, but there is never any realistic consideration of all the things that can go wrong.

As a CIO or CTO, you need to make sure you have some pessimists on your team. Not the kind of pessimists you find in Legal and Compliance, who are fighting tooth and nail to ensure no new project ever gets off the ground. But a kind of pragmatic pessimist who can look at your projects and business plans and tell you what might go wrong. These people are rather rare in IT organization, which is why this is one of the things I'm helping my customers with. Unless you add a counterweight to your IT organization, your projects will continue to fail due to irrational optimism.

------

Beneficial Intelligence is a weekly podcast with stories and pragmatic advice for CIOs, CTOs, and other IT leaders. To get in touch, please contact me at [email protected]

In this episode of Beneficial Intelligence, I discuss competition. Billionaires Jeff Bezos and Richard Branson are competing who gets to space first, with both likely to blast off within the next two weeks.

Competition is one of the great forces propelling the world forward. Richard Branson's Virgin Galactic spacecraft is based on SpaceShipOne that won the Ansari X Prize back in 2004. That prize was for a private spacecraft that could go to the edge of space twice in two weeks. It seemed impossible, but aerospace genius Burt Rutan with funding from Microsoft billionaire Paul Allen claimed the prize.

In the early part of the 20th century, the Schneider Prize similarly spurred innovation in aviation. The 1931 winner became the basis of the Spitfire fighter aircraft that won the Battle of Britain in 1940.

Self-driving cars come from the DARPA Grand Challenge. In 2004, no car could autonomously drive more than 7 miles. The next year, competition between especially Stanford University and Carnegie Mellon University resulted in their two cars completing the 150 miles route within 9 minutes of each other.

If you have clear competitors in your space, identify them. Have someone examine your competitors' products, and share that knowledge with the entire team. Making sure that everyone knows what the bar is can release energy and creativity that will allow you to leapfrog the competition.

If you don't have a good external competitor to benchmark yourself against, commission two competing products inside your organization. That costs more money, but it releases energy and gives you speed and creativity. Once a winner has been declared, incorporate the best ideas from the losing project in the winning one.

Competition has been a great force for progress all through human history. Use it in your organization for increased creativity, energy, and speed.

Beneficial Intelligence is a weekly podcast with stories and pragmatic advice for CIOs, CTOs, and other IT leaders. To get in touch, please contact me at [email protected]

In this episode of Beneficial Intelligence, I discuss doing the right thing. Google started out with a motto of "Don't be evil," but that has fallen by the wayside. Occasionally, employees remind Google of the old motto as when they forced Google to stop working on AI for the Pentagon. But they don't seem terribly committed, and their highly touted Ethical AI Team is falling apart after they fired the head researcher.

Amazon never promised not to be evil, and they are forcing their delivery drivers to do 10-hour graveyard shifts starting before sunrise and going until mid-day. They are trying to avoid tired drivers causing accidents by installing cameras and AI in the vans so the computer can detect when the worker is falling asleep behind the wheel and can wake him up.

Consulting giant McKinsey don't consider themselves evil either. They are just good at increasing profits for companies. While they claim no wrongdoing, they just settled a lawsuit paying $600 million for the advice they gave Purdue Pharma about aggressively encouraging doctors to over-prescribe opioids.

As a CIO, you're engaged in a war for talent. But you also need to meet your budget, implement hot new technologies like AI and maintain IT security. There is always an opportunity to cut a corner, roll out inadequately tested technology, or squeeze employees so you can hit your goals this quarter. But if you want to be able to attract and keep top IT talent, you need to do the right thing.

------
Beneficial Intelligence is a weekly podcast with stories and pragmatic advice for CIOs and other IT leaders. To get in touch, please contact me at [email protected]

In this episode of Beneficial Intelligence, I discuss time to recover. The entire network of the justice ministry of South Africa has been disabled by ransomware, and they don't know when they'll be back. Do you know how long it would take you to recover each system your organization is running?
When you have an IT outage, what the business wants most is a realistic timeline for when services will be back. If IT can confidently tell them that it will take 72 hours to restore services, the business knows what they are dealing with. They can inform their stakeholders and make informed decisions about in which areas manual procedures or alternative workflows should be implemented. The worst thing IT can do in such a case is to keep promising "a few hours" for days in a row.

In the 1980s, I was working for Hewlett-Packard. They had a large LED scrolling display mounted over their open-plan office. The only time it was ever used was when their main email and calendar system was unexpectedly down, telling everyone when it would be back up.

In the 1990s, I was doing military service in the Royal Danish Air Force as a Damage Control Officer. After an attack, I had to tell the base commander how much runway we had available. I had planned our reconnaissance and could confidently say that I would know in less than 28 minutes af the all-clear.

In the early 2000s, I was working with database professionals. These people spent much of their time preparing to recover their databases. They had practiced recovery many times and knew exactly how long recovery would take.

As the CIO, take a look at the list of your system. It needs to list the expected time to recover for every system. The technical person for the system should verify that this time has been tested recently, and the business responsible should verify that this time is acceptable. If you don't have a documented time to recover per system, you need to put your people to work to create it.
Beneficial Intelligence is a bi-weekly podcast with stories and pragmatic advice for CIOs, CTOs, and other IT leaders. To get in touch, please contact me at [email protected]

In this episode of Beneficial Intelligence, I discuss other people's failures. They can affect you, as the recent Amazon Web Services outage showed.

Cat owners who had trusted the feeding of their felines to internet-connected devices came home to find their homes shredded by hungry cats. People who had automated their lighting sat in darkness, yelling in vain at their Alexa devices for more light. More serious problems also occurred as students couldn't submit assignments, Ticketmaster couldn't sell Adele tickets and helpless investors watched their stocks tank while being unable to sell.

On a personal level, this dependency is an occasional inconvenience. But for companies, it is a problem.

When you buy cloud services directly from Amazon, Microsoft, or Google, at least you know what you depend on, and can take your own precautions.

But your SaaS vendors depend on one of the big three cloud providers. You will find that most of them consider using two different data centers with the same cloud vendor to be plenty of redundancy. It isn't.

Another problem is your "smart" devices that all communicate via the internet to a server controlled by the device vendor. The vendor is running that server in one of the three big clouds. That means an Amazon outage can lock you out of your building.

Some of your systems are business crucial. For these, you need to find out what your vendors depend on. Otherwise, you will be blindsided by other people's failures.

------

Beneficial Intelligence is a bi-weekly podcast with stories and pragmatic advice for CIOs, CTOs, and other IT leaders. To get in touch, please contact me at [email protected]