The Flight To Safety
No one ever got fired for buying IBM... or have they?
"No one ever got fired for buying IBM."
That was a common saying decades ago. It represented a safe choice. If you needed to find a software vendor, which is rife with challenges, pick the option everyone else picks. If things go well, great! If things don't go well? Well, you can't be blamed for picking something everyone else did!
On the other hand, the outcomes are different if you pick something no one is using. Things are still great for you if the vendor works well. This time however, you can get blamed and/or fired if it doesn't go well.
Set against those odds, what would most people do? What do you think you would do? What would you really do when tested?
There are definitely strategic reasons for safety, especially on the business side of things. Being able to say "it wasn't my fault" is important when dealing with customers. Say you’re service is affected because of a vendor. Your customers are less likely to switch to a competitor if they are also affected by the same vendor. I’d be surprised if anyone lost a significant number of customers because of an AWS outage.
The problem is when we look for safety internally. Say you need to go pick a vendor. Do you pick the vendor you think has the best product/service or the one that everyone else uses? The latter is certainly the safer choice. Yet, vendors know when they're the safe choice. They don't need to spend as much on product development and they can charge you more. Picking these vendors doesn't make the company safe, it makes certain individuals at the company safe. The business overall suffers.
Think about your own workplace. You probably use a piece of software that everyone you know hates. Yet, at your current company and every company before that, this piece of software is used. Why is that?
It can be hard for the makers of that software to innovate though as they also suffer from a flight to safety. How often have you used a piece of software that hasn't changed much in 10 years? Don't you wish it had some impactful improvements? The problem here is that every change in a product risks angering some subset of users. The safe option is to make really small minute changes so that no one is upset. The cost is a complete lack of innovation. (Ironic that I made this statement after writing about how not every product needs to innovate. I stand by both statements.)
Sometimes the vendor isn't a piece of software. Sometimes that "vendor" is a process. Take "Agile". True agile software development involves adapting your process over time based on the results you have with your team. Is a piece of documentation helpful? Keep doing it. Is it not helpful? Stop doing it. Are estimates better with story points? Use them. Is everyone struggling with story points? Please, stop. Stop using them. The goal here is to slowly develop a process that works with the people you have, not to shove a cookie cutter process onto people.
That's really hard though. It means every process is bespoke and the person driving those changes can be blamed for everything that goes wrong. This model works, but there is no safety in it for any of the managers involved.
The result? A well defined process is taken from some consultant or bigger company and forced onto development teams. Instead of adapting, round pegs are shoved into square holes.
Everyone is struggling with story points? Well our company policy is to use them, so make them not struggle. Somehow.
No one likes two week sprints? Too bad. The consultants told us two weeks is best.
No one likes JIRA? Too bad. It makes it easy to show the executives that we’re making progress.
The flight to safety results in entire orgs struggling to make a process work with little return on that investment.
Safety also includes the avoidance of throwing away... anything. I've spent hours every week sorting through hundreds of JIRA tickets in meetings with other managers. Most of those tickets were never going to be worked on and should have been deleted. Instead, we just talked about them week after week. No one can be blamed for keeping things around. What happens if you delete something someone with a fancy title has strong feelings about though? The flight to safety here results in countless hours being wasted maintaining things that don't matter.
One of the things I love about the game of poker is the concept of bleeding out. The idea is that if you only make small bets and run away if someone makes a big bet, everyone else is going to start making bigger bets. Playing it safe means you'll never lose all your money in one hand, but you will lose all your money eventually. It'll just take longer.
Business is not a zero sum game over the long term, but that just hides all the fact that many companies are bleeding out. They may be able to retain some number of customers for a time and could take decades to fade into irrelevance. By then, most of the decision makers who put those companies on that path will have left, while the people still there take the blame. It takes a crisis for a company bleeding out to finally adapt and change. Look at Microsoft. Most people had already considered it a relic for a time and it wasn't even included in the FAANG acronym. People view it very differently now, but only because the company started taking some bigger risks with its business model.
The blame for a flight to safety isn't on a handful of individuals looking to keep their jobs. I think the blame lies with all of us. We have a culture that looks down on failure. And sure, consistent and prolonged failure is not great. At some point we want to see successful results. But I think it is helpful to start looking at people who *never* fail not as paragons, but as failures in a different way. They failed to take a chance on creating real longlasting successes. Changing our view of failure in this way will go a long way to getting better decisions made.