I’ve been reading about Technology Leadership and thinking about my own experience in this area.
Some years ago I started a new job with my first “big” company – 50,000 employees, a household name in the aviation industry.
One of first tasks was to prepare a report on the Crew Management System. Should we develop the existing system further or was it better to start afresh? Our analysis suggested that the costs for both were very similar, somewhere between £1.5 and £2 million. Both approaches were perfectly feasible but that the risks and impacts on the various departments involved were different in each case.
Our deliverable was a report and presentation to a meeting of the heads of all the departments involved. I was, perhaps naïvely, looking forward to the event. We knew our stuff, we had confidence in our estimates and plans and I expected a reasoned debate, weighing the various options to gain the maximum benefit for the organisation overall. (I did say I was naïve…)
Well, the meeting was awful. Each department head’s position could be summed in a single sentence – “Obviously my department is critical to the operation and so we cannot accept any risk whatsoever”. The final outcome was that we were sent away to “provide more detail on the costs”.
Afterwards, fuming I regretted not jumping up and screaming, “Look! Both options work, if I said that each one would cost £1,712,340 precisely, which one one would you want us to do?”
Later, I calmed down and came to realise that actually the request for more precise costs was simply a cover for NOT making a decision. After all, if you don’t make a decision then no one can accuse you of making a wrong one. And what’s more, you can blame the insufficiently precise cost estimates as the reason for your inability to come to a decision. What I felt was particularly unfortunate was that both options were viable, and something needed to be done, the existing system was increasingly under strain as the demands on it grew. Probably the riskiest decision was not to make a decision at all. Quite possibly, the course of events would drive us all down one particular path, one that was not so well mapped or understand. Although of course, since that wouldn’t need anyone to actually come to a decision it may have suited some people quite well!
Perhaps I should have made the need more forcibly, but then I was simply an Analyst and thought my role was just to present the information as it was known and let my elders and betters decide the best course of action!
——-
A couple of months later we were back, to present essentially the same information, with more figures after the decimal points. This time however the Director of Crewing (a member of the executive team was present).
We presented our information, stressing now the urgency. The department heads reiterated their earlier statements, ignoring the extra detail we had provided.
At this point the Crewing Director made his first, and only contribution. He said, “Clearly we are all in agreement that the development of a new system is the better option, so we’ll go for that one. Thank you ladies and gentlemen.” Then he left.
What particularly impressed me was the brazen use of “clearly” and “all in agreement” when the actual substance of the discussion contained nothing of the sort!
Subsequent experience has shown me again and again that often any decision is better than no decision. Especially in such a malleable medium as software development. Very rarely are we ever proved wholly “wrong” or wholly “right”, most projects are a mix of outcomes. Everyone, developers, customers, management learns more from doing from doing than analysing and perhaps one of the many requirements for a true leader is the courage to take a decision, any decision!
