The Regulators are Coming

The Chinese are willing to bring the hammer down. The Americans and the Europeans, not so much. Draconian fines are theoretically possible for data privacy violations in the EU, California, and elsewhere in the West but are not imposed. In China, on the other hand, ride-hailing giant DiDi was hit with a $1.2 billion fine, close to the cap of 5% of annual revenue. Not that DiDi didn’t deserve it – regulators have identified 64 BILLION separate data collection violations.

Are you still looking at the puny fines handed out to everybody who is not a vilified American tech giant? Sooner or later, the regulators will start using their power. So you might as well get on top of any problematic data collection habits now.

Pick the Right Place for Each Task

Peak employee effectiveness and wellbeing depends on finding the optimal balance between working alone and working with others. Microsoft does big studies of their many thousand employees. They found that disengaged employees complained about too little collaboration. Overworked employees complained about too much collaboration.

Now that both office and home are valid work locations, it is a leadership responsibility to make the most of each of them. Collaboration needs to be in the office. We survived two years of Zoom meetings, but at the cost of massive Zoom fatigue. Focused work should happen at home where the employee is in full control of their time. Leaders need to set the rules and clearly delineate what happens where.

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…

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?

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?