Stop the train, I want to get off

Shawn has just posted an interesting article at Anecdote about the problem with Melbourne’s train system.  With holidays, and other interruptions to my normal commute, I haven’t been using our train service much since before Christmas.  I’m not looking forward to riding the rails again this Friday!

As Shawn has explained, this seems to be more than a mechanical problem, even if a very complicated one.  As soon as you have people involved, it potentially becomes complex.

Back when I worked it the pure IT space (on a system called “EDG”), I had an interesting problem-solving experience.  The problem – and the ultimate solution – ended up being fairly simple, but actually finding the cause was a little more complicated.  However, the whole situation became more complex, due to people being involved.

I was fairly new to the team at the time, but had already become fairly familiar with the system.  However, I was still being treated as the “junior”.  Wiser heads than mine had already solved major problems on EDG; they could solve this one too. 

The unusual aspect of this particular issue was that two different things started going wrong at about the same time.  The senior people set to work, going through the usual fault diagnosis procedures.  Some were addressing one of the symptoms; some were working on the other.  I wasn’t called upon for my (fairly limited) experience.

Given that no-one was asking me to do much else at the time, I had a brief think about the problems.  They seemed to be totally unrelated, but both did eventuate at about the same time.  “If it just so happened that these two symptoms were in fact caused by the one underlying problem,” I thought, “then where would the problem be?”  I very quickly realised that the only possible link was the system console.  This was a component that apparently virtually never failed. 

I managed to grab somebody else’s attention long enough to mention my idea, and was brushed off with a brief lecture on following correct diagnostic procedures.  “If you jump to conclusions like this, you could waste hours on a wild goose chase!” 

Nevertheless, as I was once again left to my own devices, I went and had a look at the system console.  Can you guess what happened?  Yes, there is a happy ending!  The problem was in the system console, and I had it fixed within minutes, while everybody else was still busy running diagnostics on two other, unrelated parts of the system.  I do not remember receiving a lot of praise for solving the problem, however…

Of course, there could well be other cases where my approach may not have worked; but it would not necessarily mean wasting time if it didn’t. 

This reflects the complexity introduced into an otherwise simple fault repair by the unquestioning use of accepted processes.  Sometimes we need to think outside the box – or to at least check that we are following a useful train of thought…


  1. Nicola – Thanks for the comment. It is true that our accumulated knowledge can cloud our judgement in new situations. This does not have to be a bad thing – another good reason for continual learning. It has been said that any pioneer in a field will eventually become an impediment to its advancement if he or she continues to work in that field! We should not throw out our knowledge (otherwise we could easily re-invent the wheel), but we need to continually adapt as our environment changes.

  2. I think this highlight how actually sometimes knowledge as old time expertise can just keep you away from problem solving! This is scary!

  3. Yes, I believe that Connex have made things quite complex for themselves and subsequently not resolving the issue quickly. I must say though, prior to the train brakes issue, they were still canceling trains anyway.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.