Thinking is Better Than Buzzwords

Thinking is hard. That’s why we substitute platitudes whenever possible. I was reminded last week because the election campaign has started here in Denmark. The young politicians on the left don’t know what to do about the increasing grocery prices – nobody does. But they do know that monopolies are bad. IF something bad happens AND monopolies are bad THEN monopolies cause the bad thing. The problem is that Denmark is the country most over-supplied with supermarkets in all of Europe. Calling the six different chains a monopoly means you are substituting critical thinking with a buzzword.

The same thing happens in IT. I keep seeing IT organizations whose strategy is decided by the buzzword of the day instead of actually thinking about your business needs versus the skills and resources available.

Learning from the Mistakes of Others

Learning from your mistakes is good. Learning from the mistakes of others is better. One mistake that often occurs in projects that include any kind of software is the lack of sanity checks.

For example, hackers broke into Yandex Taxi yesterday. They ordered every available car in all of Moscow to the same address. The result was a humongous traffic jam on Kutuzovsky Prospekt that took more than two hours to resolve. A sanity check would limit the number of cars that could be sent to the same address. Many of the recent failures of self-driving cars and trucks would not have happened if the software had sanity checks.

Do you have a process for sharing stories of things that went wrong? Whenever you have a meeting, have someone tell a story about something that went wrong and discuss what you can learn from that in your organization.

What do you incentivize?

You get what you reward. Twitter decided to primarily reward user growth, and things went downhill from there. Recently, their head of security quit. Then he filed a whistleblower complaint with the authorities, complaining that Twitter’s security is bad and not getting better. Now there is likely to be a very interesting congressional hearing.

White-hat hacker Peiter Zatko (aka “Mudge”) was hired after a 2020 security breach but could not implement the changes he felt were necessary to fight spam and automated bots. The reason is the incentive structure at Twitter.

You see, Twitter management bonuses are based on user growth. There is no bonus for reducing spam or automated bots. You get what you reward, with no exception. You can reward with money, perks, promotions, or other recognition, but you have to incentivize the behavior you want. If all your incentives are based on quantity and not quality, you will get ever-increasing quantity and ever-decreasing quality.

Do You Want Fancy, Cheap, or Usable?

Do you prefer fancy, cheap, or useful? Car manufacturers have found that touchscreens look fancy and are cheaper than physical buttons. That’s why modern cars have touchscreens and no buttons. I prefer buttons, and science is on my side. A survey shows that it is almost twice as fast to perform common car tasks with buttons than with a touchscreen.

Unfortunately, a car is not required to be easy to operate. Aircraft cockpits, on the other hand, are full of physical buttons. An aircraft manufacturer accepts the extra cost of physical controls to provide an optimal user experience for the pilot.

Marketing wants fancy. Finance wants cheap. User Experience wants usability. Who has the last word on product design in your organization?

Set Mandatory In-Office Days

It’s back-to-the-office time even in Cupertino. Apple has announce that starting Sept 5, employees are required to be in the office at least three days a week. Tuesday and Thursday are mandatory in-office days.

It is a good idea. The research is piling up that fully remote working has a negative impact on people who used to work in an office. The only organizations that work well fully remote are those that were born that way.

If you are in a leadership position, you should set mandatory in-office days. A minority will complain loudly, but the majority will quietly be thankful that you set clear rules. And despite the claims of the work-from-home zealots, it does improve communication, engagement, and the bottom line.

What is Your Time to Recover?

It wouldn’t take you three to four weeks to rebuild a critical system, would it? But that’s how they do things in the National Health Service in the UK. Doctors and hospitals have been advised that the central patient record system is offline due to a ransomware attack and will not be back until sometime in September. In the meantime, doctors will have no access to their patients’ medical histories and will have to keep notes on paper or in Microsoft Word on their laptops.

As a national health monopoly, the NHS will not be going out of business. But a private company that lost its manufacturing, logistics, or service management system for a month would be finished.

You do everything you can to prevent bad things from happening. But have you also planned contingent action in case something terrible does happen? The NHS hadn’t.

Are you Depending on Luck or Skill?

If you can buy anything in 7-eleven today, count yourself lucky. Here in Denmark, the entire chain is shut down because hackers got into their Point-of-Sale terminals.

Through luck or skill, 7-eleven seems to have managed to limit the damage to Denmark. If they were lucky, each country simply runs its own network and are not interconnected. If they were skillful, they had segmented their network so the malware couldn’t spread. Remember that Maersk Lines had not sufficiently segmented their network, and were laid low when malware targeting Ukrainian companies spread from their Ukrainian subsidiary to their entire global operation.

Is your network appropriately segmented so one hacker cannot kill your entire operation?

How Do You Handle Security Issues?

Over breakfast, the CEO asks you about the latest Atlassian vulnerability that he’s just read about in the Wall Street Journal. Good answers are: “That doesn’t apply to us” or “It has been addressed.” OK answers are: “We’re looking into it” or “It is being mitigated.” The horrible answer is: “What vulnerability?”

Last month, 1,973 new vulnerabilities were published. July 2022 was a quiet month – most months have over 2,000. Many of these don’t apply to you, but you need to evaluate all of them. Do you just have one guy following @CVEnew on Twitter, or do you have a real process able to handle the ever-increasing load?

Somebody Else’s Problem

Things that are Somebody Else’s Problem (SEP) are invisible. Douglas Adams famously joked about this in “The Hitchhiker’s Guide to the Galaxy,” but the effect is serious and real.

For example, local British politicians were falling over each other trying to attract data centers. They were focusing on the cachet of having Google or Facebook in their town, and the half-dozen jobs for the electricians and plumbers maintaining them. Supplying these energy-hungry behemoths with power was Somebody Else’s Problem.

Now they have so many data centers in West London that their electrical grid is overloaded, and they won’t be able to build more housing until they have upgraded their main cables. That’ll be sometime in the 2030s.

As an IT leader, it is your job to ensure that each team knows the problems they might cause for other parts of the organization.

Clueless Developers are Dangerous

A company used by 83% of the Fortune 500 is clueless about security. Scary. I’m talking about Atlassian, whose Confluence product was discovered to have a secret admin account with a hardwired password. It is worrying that any company would hire developers that could simply get the idea. It is more worrying that this got through code review. And it is very worrying that Atlassian doesn’t seem to have anyone who does a separate security review.

If you are an IT leader, take a look at your systems list. Make sure there is a name and a date in the “last security review” column for each and every system. If you have home-built systems without a separate security review by someone outside the development organization, you might be the next Atlassian.