Why IT people get angry with bad business decisions

I’m going to use an incident from my past to illustrate why bad business decisions drive IT people crazy. And if you work in IT and you don’t get involved in business decisions then you should – this example will show you why. This is possibly the single worst business decision I have personally been involved with in my entire IT career.

I’ve never been involved in some massive multinational company where the decisions involved billions of dollars and affected thousands of people. This story also isn’t about the collapse of a company. It might not be as sexy as some stories but it does highlight a typical, fundamental disconnect that occurs all too often between business and IT.  Or between business and any sort of rationality and common sense.  Some of the identifying elements have been changed to protect the guilty but the core aspects of the decision as I’m going to relate it are true.

I was working in a large logistics company that leased a large range of assets to companies all over the country. Everything from furniture to computers to vehicles were managed via the corporate leasing system. When leases expired on the assets (after 6 months to 3 years) my company took them back and usually sold them via auction (through 3rd party auction houses) to recoup the residual value. Each year, tens of millions of dollars worth of stock was sold this way. Here’s a tip: find out how end-of-lease merchandise is sold in your town – you can save a fortune buying this way.

I was the analyst on the development of an IT system to handle these auction transactions. The existing process was paper based – a list of inventory was distributed, auction houses nominated what items they wanted to sell, the items in question were delivered to the auction houses, they were sold at auction, the auction house took a commission and paid my company the remainder of the sale price.

I was given some high-level business requirements (essentially revolving around tracking and reporting on progress of the transactions) and had to develop some detailed specifications that the programmers could use to develop the system. A key part of the development cycle was that a pilot was going to be run with the single biggest auction house. This one outlet handled about 40% of all our inventory and the remainder was split among about 10 other auction houses. If the software worked with the big outlet, it would then be rolled out to the others.

Upon analysing the rather sketchy Business Requirements document (filled mostly with ill-defined jargon and waffling), one half-sentence stood out as essentially being the whole requirement for the project. After transactions were processed “an exception report is required.” This made sense – tens of millions of dollars in inventory was going out to external parties every year. It would be nice if you knew the sales they were reporting matched what you had sent them to sell.

I spent some time with the primary business user (who was much more switched on than the bodgy BR document suggested – it turns out he had very little to do with its creation.) He agreed that identifying any discrepancies between the items we sent out and the items reported as sold was the single most important requirement. After some discussion we identified a way to track discrepancies far more accurately than simply “we sent you something to sell and you didn’t give us any money for it.”

Because my company bought and sold such huge volumes we had a very detailed cost history in a database. We could say quite accurately what something should be worth new, after one year, after two years and so on. The system could be programmed to check sale prices against historical averages and if the deviation was too big (say, more than 20%) you could follow up with the auction house to find out why they’d sold it for such a low price. The whole thing could be managed much more efficiently because instead of having to check every transaction, the business user would only have to check out of the ordinary sales that triggered the exception rule.

So we had an elegant solution that wasn’t particularly difficult to implement. I was feeling pretty good. I submitted the specification to my manager for approval. And received a rather unexpected response:

Manager: “We don’t need to check the dollar amounts they report.”

Me: “Why not?”

Manager: “We trust them to get the numbers right.”

Remember, this was for transactions worth tens of millions if not hundreds of millions every year. My manager was suggesting the amount of oversight required for external parties handling these transactions was zero. I was stunned. I thought maybe I hadn’t explained the solution clearly.

Me: “We’re not talking about manual checking of figures. We already have all the information required to automate this sales audit. We can make the threshold as generous as you like – maybe a 25% deviation. Maybe only apply the check to transactions worth more than $10,000. If they never get the number wrong then nothing will ever happen – we’ll only be notified if a transaction looks wrong.”

Manager: “We trust them so there’s no need to check the figures.”

Me: “What exactly do we trust them to do? Do we trust them to never, ever make a mistake when they enter a value? Do we trust them to never dishonestly manipulate the auction and sell our stuff to a friend of theirs for far less than its fair value? Do we trust them to never falsely report a low sales price and pocket the difference?”

Manager: “Of course, that’s exactly what we trust them to do.”

Me: “That’s crazy!” (note to self: stop telling business people their ideas are crazy) “You trust every single person that works for that company? You trust people who might work there in the future, people we’ve never met? And even if you trust our major partner, this will be rolled out to a dozen other companies. Do you trust everyone who works for them and everyone who will ever work for them?”

Manager: “I’ve answered your question, stop trying to make things more complicated than they need to be.”

Me: “I’ve already talked to the programmers and this check is relatively trivial to put in place. Maybe two days of programming and testing. It won’t affect our overall delivery schedule and it will result in a much better system.”

Manager: “We don’t need to use even those two days because we trust them.”

Me: “So you’re going to consciously put into place a system that would allow massive errors to pass through undetected. A system that would allow large scale fraud to go undetected. When there’s a really simple solution already defined?”

Manager: “Yes. It isn’t required because we trust our partners.”

I think it would have hurt my head less to bash it against an actual brick wall rather than to continue to butt up against this figurative one. Here’s why business decisions like this make IT people so angry: it’s illogical, it allows bad data to enter the systems and it’s easily solvable. And here’s why IT people should care about decisions like this: you just know when the inevitable happens and some huge amount of money goes astray, IT are going to be blamed for building a system that “allowed” it to happen.

So what did I do? I circulated an email to everyone who could possibly be affected that this decision had been made. I made it clear that it was possible to have this check in place but it had been declared unnecessary. I included the same information in the specification. And at the first opportunity I found a job somewhere else because I wasn’t going to be subjected to that lunacy if I could avoid it.

Any suggestion that I took a job processing payments at one of the auction houses is unfounded conjecture. The fact that I have an early retirement planned at an offshore tax haven where I have a secret bank account is purely coincidental.



Filed under Work

16 responses to “Why IT people get angry with bad business decisions

  1. John

    I’ve become a complete cynic.

    Was your Manager on the take?

  2. Workerdrone

    You really need to wonder if these people ever visit reality. Must be nice to have a fantasy world that you can actually live in.

  3. Anonymous

    IT will not only be the ones blamed when something goes wrong, but they will also be the ones to have to work around the clock to fix the problem. That manager guy will be at home over the weekend having a BBQ and drinking beer while IT is back at the office coding a fix for Monday morning.

  4. Anonymous

    Sounds like your manager was involved in fraud already. Maybe you’ll meet him in Tahiti. 🙂

  5. What a tosser. I have to say, if I knew him, I’d assume he had more ego than sense. Not knowing him, I assume he was on the take.

    Cheers Mr Angry.


  6. Assholes are everywhere, be careful or you’ll be working for one. What am I saying!

    We are all working for assholes!

  7. Thou shall not write bad code.

  8. I want to be the person that asshole trusts!

  9. Andy K

    Sadly, this story sounds completely unexceptional.

    In my experience, in any large organisation, as time goes by, the probability that someone without the necessary skills and knowledge will be put in a position where they are able to make important decisions on things they do not understand approaches 1.

    Sometimes, just sometimes, these people are not too arrogant to listen to advice, rational arguments, and consider alternative view points.

    The other 99% of the time, these people are either too arrogant or too insecure to ever lose an argument.

  10. John: I had my suspicions at the time but there was certainly no evidence.

    Workerdrone: Yes, some people do live in a reality-challenged environment

    Anon: sad but true

    Aphra: I knew him – it was definitely the former, who know about the latter.

    Range: That’s true more often than not

    Sandra: Yeah, you could get away with murder, couldn’t you?

    Andy: As you say, it’s unexceptional. And that’s sad.

  11. Leigh

    Smells like money laundering

  12. dracula

    how soon after the email circulated did they fire you?

  13. Leigh: I clearly wasn’t suspicious enough at the time. Everyone seems to be thinking along similar lines after reading this post.

    dracula: Actually, they pretty much ignored it – typical of the dysfunction in that place. I left before I could find out if there was any serious blowback.

  14. Randy

    Should try telling people what they want to hear, then rolling the feature into the project anyway.

  15. The trouble with that is sometimes they remember what you said. And what you said to shut them up may be impractical or impossible to implement.

  16. Shenpen

    Never attribute something to stupidity when it can be adequately explained by conflicts of interests. That manager probably had a personal interest on not getting those transactions checked – likely, fat kickbacks.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s