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 sten@vesterli.com

In this episode of Beneficial Intelligence, I discuss the people shortage. It isn't real. 

Complaining about a lack of people is what is known as a "half argument." You say what you want, but not what you are willing to give up. That's like a politician promising to build a new public hospital but won't say where the money will come from. 

The full argument for missing people is "we cannot get the people we want at the conditions we are willing to offer."  If you had a crucial project that will make the business millions of dollars, you would be able to find the resources you need. You could simply offer three times the market rate, full benefits, and a 40-hour workweek with no overtime. 

Allocating resources is a basic leadership task. You rank your tasks and projects in order of descending business value and allocate available resources to the most valuable. It doesn't make sense for a CIO to say that the organization is "missing" a hundred programmers. A full argument would be that if we had a hundred extra programmers, we could build a specific IT system that is less valuable than all the current projects.

There might be a real shortage of money or copper or clean water. But there is no shortage of people.

 ---

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 sten@vesterli.com

In this episode of Beneficial Intelligence, I discuss data hoarding. Gathering too much data costs money and doesn't add value.  We think we need all this data to train our AI, but hoarding data is the wrong place to start. 

Using a counterproductive metaphor, some say that "data is the new oil." That is a dangerous metaphor with no less than four problems:

• First, data is not fungible like oil is. One barrel of oil is just as valuable as the next barrel. But one data record does not have the same value as another data record.  
• Second, data hoarding shows diminishing returns. The value of 100 million barrels of oil is 100 times the value of 1 million barrels. But the value of 100 million transaction records is not 100 times the value of  1 million transaction records. 
• Third, the process of refining data into valuable business insight is not repeatable. Anybody can build an oil refinery. That's just a question of money. But extracting value from data is more art than science, and even with the best data scientists, you might still not be able to extract any value from your data. 
• Fourth, the value density in data is very low. Everything in a barrel of oil becomes a useful product. But most data records do not provide any business insight. 

Gathering data in the hope of extracting value is putting the cart in front of the horse. The right way to work with data is to start with a business goal and a hypothesis about which data might provide insight. Gather the data, run the experiment and evaluate. Don't just hoard data.

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 sten@vesterli.com

In this episode of Beneficial Intelligence, I discuss monoculture. Just like in farming, monoculture is efficient and dangerous.

Modern farmers will plan hundreds or thousands of acres with the same crop. That gives efficiency because the entire crop will respond identically to fertilizer and pesticides. It also means that the entire harvest will be lost if some new pest or disease suddenly appears. Monoculture cost more than a million lives in Ireland in the Great Famine of the 1850s. 

There is also monoculture in your IT landscape. If all your systems have the same hardware and run the same software, they will all be vulnerable to the same bugs and malware. 

Your servers are probably many different types because they have been added over the years. But if you run the same virtualization software on most of them, your entire infrastructure is vulnerable to a bug in your virtualization.

Your workstations are monoculture, and if something takes out Microsoft Windows, you are dead in the water.

But the really dangerous monoculture is found in your network equipment. You probably buy all your gear from one vendor so your network people only need one skill stack. But that means that a vulnerability will expose your entire network. 

You don't want to put all your eggs in one basket. If you are concerned with robustness and business continuity, beware of monoculture. 

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 sten@vesterli.com

In this episode of Beneficial Intelligence, I discuss trusting your vendors. You trust them to make their best effort at producing bug-free code. You probably trust that their software will perform at least 50% of what they promise. You might trust them to eventually build at least some of the features on their roadmap. But can you trust them to not build secret backdoors into the software they give you?

Snowdon showed we cannot trust any large American tech company because they send our data straight into the databases of the National Security Agency. Apparently, you cannot trust Chinese smartphone vendor Xiaomi. The Lithuanian National Cyber Security Centre just published the results of their investigation, and they recommend that people with such phones replace them with non-Xiaomi phones "as fast as reasonably possible."  

It turns out these phones send some kind of encrypted data to a server in Singapore, and that it has censorship built in. Phrases such as "Free Tibet" simply cannot be rendered by the browser or any other app. Right now, that feature is not active in Europe, but it might be enabled at any time.  

During the nuclear disarmament discussions between the United States and the Soviet Union in the 1980s, Ronald Reagan was fond of quoting a Russian proverb: Doveryay, no proveryay - Trust, but verify. The ability for both parties to verify what the other was doing became a defining feature of the eventual agreement. 

In software, we can verify Open Source. If you cannot find open source software that does what you need, many enterprise software vendors will make their source code available to you under reasonable non-disclosure provisions. 

In your organization, there should be both trust and verification. Don't simply trust your software vendors. Trust, but verify. 

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 sten@vesterli.com

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 sten@vesterli.com

In this episode of Beneficial Intelligence, I discuss goal fixation. Richard Branson almost didn't make it back from space. His pilots had a problem and flew very close to the limit. They should have aborted. But the future of commercial spaceflight was resting on their shoulders. They were fixated on the goal, and that causes problems. 

The reason we are finding out is that authorities noticed the flight was outside its designated airspace because stronger winds than expected caused the flight to have a different profile. The pilots got a red light ENTRY GLIDE CONE WARN. That means the spacecraft is so far from the planned course that it might not reach the place it has to be to glide to the landing site. The correct checklist approach is to abort the mission. But this was a highly-billed first commercial flight with the founder on board. The pilots pressed on. They managed to go to space and return safely. But they were dangerously close to the edge. 

People die because they get fixated on the goal and push on. Mountaineers continue towards the summit after the safe turnaround time, and pilots fly into bad weather. Some of the well-known people we've lost to pilot goal fixation include basketball legend Kobe Bryant and Polish President Lech Kaczyński. 

We see the same thing in failed IT projects. Multi-year, million-dollar projects keep collapsing ignominiously without anything to show for all the effort. This happens due to goal fixation. 

Tragically, the problem is completely invisible to project sponsors who feel part of their reputation is on the line as sponsors of the project. It is also invisible to the program management and project leaders inside the project.  

There are two solutions. One is to listen to the people on the ground. The programmers and testers know that a project will fail. The other is to get an independent outside opinion. That's what I provide to my customers. If you don't have a process for gathering in-the-trenches information, or an outside advisor, or preferably both, you are likely to fall prey to goal fixation.
 

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 sten@vesterli.com

In this episode of Beneficial Intelligence, I discuss the narrow focus of IT professionals. This is an unavoidable consequence of the complexity of the technology we use. We've had to learn to give our computers very exact instructions, and that informs our thinking. 

The app from my local supermarket is obviously built by people with a narrow focus. If I search for "sugar," the first hit is "pickled cucumber (sugar-free)." The Amazon app, on the other hand, is built by people with a wider focus. Whatever you search for, Amazon will always give you a suggestion. 

When IT organizations try to hire, they will come up with a long list of technologies and programming languages. Unfortunately, nobody matches the entire list, and no one is hired. Successful organizations instead ask for recommendations and interviews to find people with energy and willingness to learn. 

In the IT industry, we call something Artificial Intelligence if it can succeed at some very narrow task like recognizing cats in videos. Unfortunately, the word "intelligence" means something much wider to everyone else. When Tesla talks about "autopilot," they mean something that can stay on the road at a constant speed. In a narrow sense, a Tesla has an autopilot. In the wider sense, drivers expect that word to mean a car that drives itself. 

A narrow focus is a quality in an IT professional. There is no need to change them, and they do not get a wider focus by being sent on a User Experience (UX) boot camp or a three-day Product Owner course. Your teams need people with a wider focus. That's something that UX professionals and real product owners from the business can give you. That's why the best IT organizations employ anthropologists to study users. It is your job as an IT leader to ensure you have people with both narrow and broad focus. 

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 sten@vesterli.com