Last week I wrote this post titled; Software, Hacks Upon Hacks. I am going to dive a little deeper into the psychology of this.
Quick and dirty changes to IT systems, without adequate documentation or guidance will leave your IT infrastructure in a state that I call brittle. And by brittle. I mean susceptible to breakage, which causes downtime which costs money.
This is an issue that all IT teams need to deal with, but it can be an extra challenge for CFOs, CEOs or other general business management that are responsible for managing IT to realize or visualize. It is challenging because you need to ensure that IT teams are truly understanding and responsible for what goes on ‘under the hood’ of IT systems and development.
Complexity…
Your IT systems are complex. hardware, software, all tied up into systems and services. And complex systems rarely have a single cause that initiates a failure. Multiple small and seemingly unrelated events can all add up to producing failure within particular circumstances.
And Outcomes…
Within the fields of psychology and behavior. There is a term called outcome bias.Which Wikipedia defines as;
(to) judge a past decision by its ultimate outcome instead of based on the quality of the decision at the time it was made
Or to put it bluntly, “Hey it worked! just leave it like that!”
So your IT team says the problem is fixed, the outcome? hey it works right? But truly- was the quality of decision making in the how it was fixed worth giving kudos to that team?
What outcome bias means to us is that as long as it worked, all must be good! So in this case at least, the outcome worked and we don’t ask further questions.
It can be tough for non-technology managers responsible for IT to understand if your technology teams are making these undocumented shortcuts that may have an immediate outcome that works, but leads to fragility and brittleness within your IT systems that will increase the chances of failure down the road.
For a CFO or other general manager managing IT, the only way I personally know of to reduce the risk, is to ensure that there is open and accurate communications on any deviation, incident or problem that affects IT services. This communication must include how it was resolved, and some simple questions asking; is that the best way?
As an example, if your software development team solves a particular problem, was this a good method? is it one that can be used in similar situations? is this method documented as a good practice?
The alternative is that all future issues are handled differently. In other words five different solutions to the same problem. So if something goes wrong? Finding where in those five different solutions the problem occurred will be difficult.
Ask Questions
If there has been an IT service failure is IT telling you that it is fixed? have they said that the issue is closed? Have they identified why the issue occurred? Is the way that the issue was resolved considered a good practice?
The SMB Takeaway
Just because an outcome was successful in fixing an IT service failure, there is no guarantee that it was fixed in a fashion that will ensure that it does not happen again.
Ensuring that there are guidelines and good practices for maintaining and repairing your IT systems and services over the long term will reduce outages, unscheduled downtime and costs and also provides opportunities for improvement and learning.
Avoiding outcome bias means we need to dig deeper than a blanket statement such as; ‘it is working’ and understanding that underlying causes need to be addressed.
Photo Credit Jack Zalium via flickr