You Don’t Want a Sam Altman

You don’t want a Sam Altman in your organization. If you have, you’re not running an IT organization. You are just administering a cult.

I’m all for having brilliant and charismatic performers in the organization. However, having individuals perceived internally and externally as indispensable is not good. Mr. Altman admitted as much back in June when he said, “No one person should be trusted here. The board can fire me, I think that’s important.”

It turns out that the board couldn’t fire him. He had carefully maneuvered himself into a position where investors and almost everyone on the team believed that OpenAI would come crashing down around their ears if he left, costing them the billions of dollars of profit and stock options they were looking forward to.

Make a short list of your organization’s 3-5 star performers. For each of them, ask yourself what would happen if they were let go or decided to leave. If any of them are in a Sam Altman-like position, you have a serious risk to mitigate.

The Guard Rail Pattern

There is a simple way to prevent many IT disasters, and it is sadly underused. It’s not on the standard lists of design patterns, but I call it the “Guard Rail” pattern.

It would have prevented the IT disaster that dominates the news cycle in Denmark these days. Techno-optimists have forced a new digital building valuation on the long-suffering Danes, and it is an unmitigated catastrophe. The point is to replace the professional appraisers who determine the value of a property for tax purposes with a computer system. And many of the results from the computer are way off. Implementing a Guard Rail pattern would mean that the output from the new system would be compared to the old one, and those valuations that are, for example, 3x higher would be stopped and manually processed.

A colleague just shared a video of the latest iteration of the Tesla Full Self Driving mode. This version seems to be fully based on Machine Learning. Previous versions used ML to detect objects and traditional algorithmic programming to determine how to drive. As always infatuated with his own cleverness, Elon Musk does not seem to think that guard rails are necessary. Never mind that the FSD Tesla would have run a red light had the driver not stopped it. Implementing the Guard Rail pattern would mean that a completely separate system gets to evaluate the output from the ML driver before it gets passed to the steering, accelerator, and brakes.

When I attach a computer to my (traditional) car to read the log, I can see many “unreasonable value from sensor” warnings. This indicates that traditional car manufacturers are implementing the Guard Rail pattern, doing a reasonableness check on inputs before it passes the values to the adaptive cruise control, lane assist, and other systems. But the Boeing 737 MAX8 flight control software was missing a crucial Guard Rail, allowing the computer to override the pilot and fly two aircraft into the ground.

In your IT organization, discuss where it makes sense to implement the Guard Rail pattern. Your experienced developers can probably remember several examples where Guard Rails would have saved you from embarrassing failures. There is no need to keep making these mistakes when there is an easy fix.

AI Will Not Destroy Humanity

AI doesn’t pose an extinction risk. And it has already created brand new jobs in the catastrophizing industry.

The only reason AI industry leaders like Sam Altman and Demis Hassabis jump on that bandwagon is to encourage more government red tape. If you are a powerful incumbent, asking for as many constraints to your industry as possible makes sense. The EU, ever happy to regulate industries originating elsewhere, is delighted to oblige. With compliance departments of thousands, these massive organizations can handle any amount of regulation thrown at them. But a lean startup will get regulated out of business.

The most fascinating part of AI is local, small-scale AI. We currently have massive, centralized AI running in enormous data centers. But since LLaMA escaped from the Facebook lab, tinkerers and hobbyists have already built Large Language Models on their local computers. But, of course, OpenAI, Microsoft, and Google would like small competitors to be regulated away.

Offering Alternatives

Are you building critical software? Then you know to offer a fallback option if something – despite all your testing – does not work. That is often not a concern in organizations that can simply force users to suffer their app. Like the public sector in Denmark, where every parent of a schoolchild in Denmark must use the “Aula” app. Unfortunately, a botched upgrade means that many cannot log in.

Having only smartphone apps makes you vulnerable. The app stores do not older versions, so once you have rolled out a defective version, you (and your users) are up the creek. The mitigation for this risk is to also offer a responsive web application with only the most crucial features.

Take a look at the smartphone apps your organization offers to its customers. Are any of them critical? If so, do you have an alternative ready?

Cloud Means Aomeone Else is in Control

Cloud services mean you are at the mercy of someone else. It is bad enough that hackers broke into Western Digital’s My Cloud service and encrypted their customer’s data. But many private customers are now learning what it means to use WD’s cloud-based login service. It means that even though your data is stored on your own NAS device in your own basement, you still cannot get at it when WD is down.

If you are using any cloud-based login service in your organization, ask your CISO how people would log in and access ressources if that service is down.

Who Thinks About Risk?

A “Silicon Valley Bank Risk Management Department” T-shirt is the latest in ironic workwear. Not that SVB seems to have much risk management – their Chief Risk Officer stepped down in April last year, and the position was vacant for eight months.

Does anybody have the Risk Manager position in your IT organization? Every project creates a risk matrix and mitigates the worst risks, but once the project is complete, risk management evaporates in many organizations. The CISO does some risk management, but many IT risks are outside her remit. And risk management falls squarely in the “important, not urgent” category that always gets pushed to the back of the task list…

Beware of Asymmetric Risk/Reward Profiles

Would you continue to sell a lock based on technology that has been known for 14 years to be trivially easy to hack? Of course not! But Scantron in Denmark has merrily been foisting insecure locks on unsuspecting Danish apartment administrators. Even after a worried renter told them about the problem in several emails and even physical letters (!), they ignored the problem. It took a media shitstorm to make them realize the errors of their ways.

Digital locks have an asymmetric risk/reward profile. The reward is small – you save a little by not having to administer physical keys and re-key locks. The risk is huge – someone might copy a key, turn it into a master key, and rob hundreds of apartments.

When you are evaluating digitalization projects, be very careful about those with such an asymmetric profile. Almost every organization has digitalization projects with a better risk/reward balance than digital locks…

Good Intentions are not Enough

“We have the ambition to test disaster recovery twice a year.” That’s not something anybody in a professional IT organization would say, is it? Ambition? I have the ambition to create a spam- and hate-speech-free Twitter alternative powered by unicorns and rainbows, but unless I act on my ambition, nothing will happen.

Nevertheless, critical Danish infrastructure was operated on that principle. The common login system that everything from banks to tax authorities to municipalities uses is operated by a company called Nets. They apparently got to write their contract with the state themselves because it contains the ridiculous “ambition” instead of an actual requirement.

They did run a test on May 28, 2020. They did not run a test in November 2020, as was their ambition. Nor in May or November 2021. Not even in May 2022 did they test it. So when they crashed the system in June 2022 due to undocumented changes and other unprofessional shenanigans, the disaster recovery unsurprisingly failed.

Please tell everyone this story. When you are done laughing at the incompetence of central Danish authorities and their vendors, make sure you are testing your own disaster recovery…

It’s Expensive to Try to Get By With the Cheapest Resources

Talent is expensive. Not paying for talent is more expensive. Microsoft gets that. The U.S. Department of Defence doesn’t.

The Microsoft bug hunting program has a maximum payout of $250,000, and they did pay out $200,000 this year. You would think a crucial national defence vulnerability would merit a bigger bounty that finding a flaw in the Microsoft hypervisor, wouldn’t you? The DoD pays out $500 for a high-severity bug, and a whopping $1,000 for a critical issue.

Your developers are rewarded for shipping functionality. They don’t have the mindset to find the vulnerabilities. To build secure systems, you need to offer a bug bounty, or hire outside experts to do security review, or create your own internal white-hat hacker team. It does cost money. But security breaches cost much more.

Why Projects Without Business Cases are Shot Down

I just had a customer attempt to start a project without a business case. Such projects are usually driven by the desire to use a specific technology and with a vague idea that this would somehow benefit the end user.

If the IT department is strong, some of these orphan projects get started. They might be successful. However, since the organization has no idea of the business benefit, it is blind luck if the benefits exceed the cost.

If the business prevention department (compliance/legal) is strongest, they are shot down. There is always a reason not to make any changes. A project without a business case can be mortally wounded by any objections about compliance, GDPR, security, etc.

That is why every project needs a business case. It prevents IT from wasting money on something that will not add value, and it prevents compliance & legal from killing projects with a positive business impact.

Do your projects have solid business cases? If not, get in touch, and I’ll help you.