Learn From New People

I’ve been traveling through four countries this week, and every country does some things differently. Some have stupid rules that sensible people would never implement. But others have great ideas that should be implemented more widely. Unfortunately, ideas do not automatically cross borders the way viruses do.

Ideas also don’t cross organizational boundaries easily. As a consultant, I help organizations with good ideas proven in other places. But you also have another source of new ideas: The people you hire. Do you have a formal post-hire process for gathering ideas from new hires? Probably not – few people have. But think about how much you could learn if you had…

Always Measure Two Things

Be careful what you measure. You are going to get exactly that. You remember “Dieselgate,” where Volkswagen installed software in their cars to cheat on emissions tests. Samsung was just caught doing the same thing, programming their TVs to recognize a typical testing scenario and boosting brightness during the test.

A single measurement is easy to cheat on. If anything depends on that measure – bonuses, promotions, reputation – somebody is going to cheat sooner or later.

That’s why every measurement needs a counter-measure. Don’t just measure “Time to close support ticket.” I’ve been working with vendors who clearly had that measure as their main target, as have most people in IT. If you also measure customer satisfaction, it becomes much hard to game the metrics.

The Tolstoy Principle in Action

This is what failure looks like: 50% one-star reviews. The other half is five-star reviews. Assuming these are not all from the app developers themselves, the app apparently can work. It just didn’t work for me, nor for many others.

I call this the Tolstoy principle: All successful apps are alike; each unsuccessful app is unsuccessful in its own way. The end-user does not care that 98% of your back-end infrastructure is running. They care that they can complete their task. And if one critical component fails, your app is a failure. Like this one from my local supermarket chain.

When you build systems, is all the attention lavished on a cool front-end app? Unsexy back-end services are equally important.

You Need On-Site Time

You can work from home as long as you also put in 40 hours at the office. That’s official policy at Tesla, where Elon Musk has thrown down the gauntlet at his executives. The factory workers put in 40+ hours and their managers should, too.

There are some jobs that lend themselves well to remote working, and some that don’t. Elon has a point that managing people involves being visible, and much leadership happens outside official meetings. Nobody has figured out a way to simulate the informal encounters of the workplace in Zoom. That is why some on-site time is necessary for everyone inside the organization. We are seeing that fully remote workers never assimilate the culture of the organization, don’t feel a sense of belonging, and quit much faster than people who still have an in-person connection to the organization. People who are 100% remote should be contractors, not employees.

Are You Making a Fool of Yourself?

You’d think that an official digital ID project would be subject to a careful security review. Not in Australia. The government of New South Wales in Australia has rolled out a digital driver’s license that contains no less than five different security issues. Together, these make it trivially easy to alter any data on your ID, effectively creating a fake ID. That is good news to Australian identity thieves and underage would-be drinkers. The official response is “it’s illegal to make changes to your ID.”

Are there any embarrassing security oversights in the products you roll out? How would you know?

Don’t Use Illegal Defaults

You would never implement a system programmed to break the law, would you? The municipalities in Denmark did. If you get social security in Denmark, you are supposed to work at least 225 hours per year if you can. Those who can, and don’t, get less money. Those who cannot work are exempt from this deduction rule. The IT system has been programmed to automatically start reducing benefits unless a caseworker remembers to manually keep pushing the deduction date into the future. This means the municipalities save money by illegally reducing benefits for those citizens who do not have the energy to complain.

When you automate a process, your users will quickly come to accept the decision of the system. Make sure you have good defaults. At the very least, make sure they are in accordance with the law.

Control Your Tools

Do you know which tools your developers are using? Many of them are using low-code/no-code (LCNC) tools, whether officially sanctioned or not. The latest State of the Developer Nation report from SlashData delves into LCNC tool usage and finds that 46% of developers are using them. 12% of professional developers use them for more than half of their work, but developers with 10+ years of experience shun them.

Developers can pick up cloud-based low-code/no-code tools without anybody noticing and deploy production applications using free-tier functionality. By the time IT management figures out what is happening, you might have dozens of small and medium-sized applications running.

You cannot prevent these tools from being used. You can get your developers to decide on one tool and make that the officially sanctioned low-code/no-code platform. That means you can manage all the applications on one platform, and developers can help each other use the tool. Trying to ignore these tools does not make them go away.

(image source: SlashData State of the Developer Nation, 22nd edition)

Are Security Issues Ignored in your Organization?

Delete production database, go to jail, do not pass GO, do not collect $200.

A disgruntled Chinese sysadmin wiped his company’s servers after feeling ignored. He had complained about a lack of basic IT security, but found no understanding from his boss. He then wiped out most of their infrastructure, paralyzing a $6 billion company with 120,000 real estate brokers. He did prove his point. He was rewarded with a 7-year jail sentence.

The person with the most detailed knowledge of the vulnerabilities in your IT landscape is not the CISO. It is the database administrator or the network engineer. Do you have a process to ensure that potential security issues can be raised anonymously and will come to the attention of the CIO?

Are You Still Building Things That Don’t Scale Automatically?

There is no excuse for a modern system to be slow. I’m at a 5,000-people conference this week, and their official networking app is totally overloaded and almost unresponsive.

You might still have legacy systems with scalability issues, but everything you build today should be cloud-native. As a first-class citizen of the cloud, a modern app has access to automatic scaling, monitoring, robustness, and many other features.

Ask the architects building new systems in your organization about how the application will scale. If the answer is that it will scale automatically, good. If the answer is that somebody has to notice response time increasing and manually do anything, you are still building to the old paradigm.

Do You Understand What You are Running?

Don’t run systems you don’t understand. Some people had placed billions of dollars into a cryptocurrency called TerraUSD. They were told this was a “stablecoin” that would keep a value of $1. Underlying this claim was a clever algorithm that interacted with investors and another cryptocurrency in complex ways. Until its magic no longer worked and the supposedly stable TerraUSD dropped 80%. Trading in it is now halted.

In the global financial crisis of 2008, people had invested in complex financial instruments that they didn’t understand. Many billions were lost and large institutions went bankrupt. The banks who came out of the crisis unscathed were those who had stuck to simple banking products that everyone could understand.

Take a look at your IT landscape. Can you find somebody who understands your operating infrastructure? Or have generations of DevOps engineers just googled problems and tweaked your Kafka and Kubernetes configuration until it somehow seemed to work?