Are you Dependent on Freelancers?

Using freelancers is dangerous. It starts innocently enough with just a single developer experienced in your chosen tool. But soon, you’ll be hiring a few more freelancers to fill positions you couldn’t hire anyone to do. Suddenly you wake up to the fact that the only people who know how to use half of the cloud services in your product are freelancers, who will be gone next time there is a funding squeeze.

I’m in favor of temporarily using freelancers to augment your team – I’ve been an external consultant most of my working life. But use them responsibly. Freelancer.com showed a 40-50% increase on a year-over-year basis last quarter for various categories, while postings for permanent employees on other sites grew only 12%. That sounds like many organizations are becoming dependent on freelancers. So ask yourself if you can maintain and run your systems without freelancers.

What Sicily can teach you about IT architecture

I’m back from Sicily, and it has been Greek, Roman, Arab, Norman, French, German, and Spanish before becoming Italian. Each civilization re-used whatever was bequeathed to it by its predecessors. That’s why you find a Baroque church incorporating columns taken from a ruined Greek theater and a Palazzo built partially from lava stones taken from a Roman villa.

I remembered a quote from Ellen Ullman: “We build our computer systems the way we build our cities: over time, without a plan, on top of ruins.”

We cannot see through the layers beneath our buildings in the physical world. That makes it hard to figure out if you can safely build higher. In IT, we can see the foundation. That allows us to know what changes we can make. As long as we have the source code and the people to understand it…

Letting a System Give Ridiculous Answers

Here is another example of a computer giving a ridiculous answer. When I book a hotel, Booking.com will automatically suggest an airport transfer. OK, but not when the airport is 200 kilometers and a long ferry ride away. Providing meaningless answers to your users is not a trivial problem that you can brush off. It undermines the confidence your users have in a system, usage drops, and shadow systems in excel proliferate. Do you have a policy to build sanity checks into your systems?

Are You Afraid Robots Will Take Your Job?

Robots are not taking our jobs. It’s a good story to create eye-catching headlines and generate clicks, but the numbers do not support it in any way.  Michael Handel of the U.S. Bureau of Labor Statistics has published a paper where he carefully analyzes job losses across many professions. He finds that job losses follow long-term trends, and there is no hint of the dramatic changes predicted by people who make a living from predicting that the sky will shortly fall.

That matches what I see in the organizations I work with. Traditional IT projects regularly fail, and AI projects have an even higher failure rate. They might deliver something, but too often, it turns out to be impossible to move an AI experiment out of the lab and into productive use.

Additionally, in the cases where AI does provide real business benefits, it handles one specific task and not a whole job. All of our AI today is very narrowly trained for one task. That frees up workers to do more useful things with their time, making them more productive.

For example, the illustration for this post is made by me and the Midjourney AI. It was told to illustrate “the robots are not taking our jobs.” We ran a few iterations where I selected the best of its suggestions until we came up with this image.

Well-led Employees Don’t Leave

When a company changes hands, the tree is shaken. Some of the employees that weren’t really attached to the company leaves. That’s what is happening at Twitter right now, and that will happen whenever there is uncertainty in your organization.

But have you noticed that some teams experience a lot of turnover in turbulent times, and some teams are solid as a rock? The difference is leadership. Members of a well-led team will continue to do their job through whatever tsunami of social media opprobrium, whereas members of badly led team will jump ship at the first sign of trouble.

Are you tracking the turnover in each part of your organization? It will tell you something important about the leaders.

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.

Who is in Charge of Outside-the-Box Thinking?

Everyone can track your license plate – not just the cops. A Belgian security researcher noticed that most parking apps do not validate that you actually own the license plate you add to your app. That means a stalker can add his victim’s license plate to his app and immediately be notified whenever that person parks anywhere…

This is another example of the inside-the-box thinking that developers are prone to. The developers of the Kryptonite bike lock had made it out of extra reinforced steel. Too bad a weakness in the lock allowed a hacker to open it with half of a ballpoint pen.

Finding holes in a system is not just securing the login and checking the encryption. It involves examining the system and its environment and users. That is a skill most developers lack. You need a “red team” who can find the holes before you roll out something embarrassingly insecure.

Do You Still Need an IT Department?

Is it time to get rid of the IT department? Some people advocate that IT should be fully distributed in individual business units. Dr. Joe Peppard argued this case, and I just read his reply in the Wall Street Journal to the various objections he received.

I find the binary “IT department yes/no” discussion to be a useless polemic. Every organization has some mix of central and decentralized IT. The question is whether each IT capability is correctly placed.

Systems of record make up the foundation of your business and do not provide a competitive advantage. That’s things like email, accounting, and HR. Those fit well in a centralized IT function. You want to focus on reliability, and you don’t want each department or country running its own accounting or email server.

Systems of engagement that provide you with competitive advantage need to be closer to the business and the customers and move faster. That requires a different mindset with more risk-taking. That’s why these systems are often a poor fit in centralized IT. But letting each department roam free means you end up with a dozen incompatible cloud services without synergy.

Conundrums like this cannot be solved at the organizational level where they occur. Because the choice pits the agenda of the CIO/CTO against the CFO, CMO, and CSO, the final arbiter has to be the CEO. He or she is impervious to technical arguments. If you are a CIO or CTO, you owe it to your organization to be able to speak the language of the CEO.

Patching is Your Responsibility, not Your Customer’s

Face it, you are not even fully patching your own systems. Assuming that your customers or users will try to patch their systems is unrealistic.

If you are delivering any product that contains software, you need to think about how you will patch the thing. Tesla just discovered a problem with the pinch protection in their power windows. Cars with electric windows must have an “automatic window reversal system” that detects if it is about to pinch a finger or worse. Tesla found its system would not always be within the required parameters and pushed out an over-the-air update to more than a million vehicles. Elon Musk took to Twitter to fume about the fact that such a fix is technically a “recall.”

On the other hand, more than a year after the vulnerability was discovered, there are still more than 80,000 vulnerable Hikvision cameras connected to the internet. Besides the fact that everybody can view their footage, the built-in Linux server is probably also mining crypto and sending spam. The owners could not be bothered to pull the thing down from the wall, connect it with a cable, install updated firmware and mount it again.

Be like Tesla, not like Hikvision.