On The Daily WTF, there’s a great story about a network-oriented coder at the (name changed) “AQ&V.”
Here’s a quick summary:
“Mike” takes a job with AQ&V, and finds that the “network health” team, tasked with finding out about outages and performance problems before the customer, was not actually spending any time resolving issues, because each member of the team was spending all their time using internal apps to enter tickets and generate reports.
No one on the team actually solved the problems.
Mike then decided to code a kludge of a script which would automate most of the repetitive tasks that the network team was doing, freeing them up to actually fix some of the problems. But when he tried to implement it, he found that the password to the development machine had been changed and that management had decided that they didn’t want him to actually solve problems – they just hired him to throw more manpower at entering trouble tickets… without solving them.
In the anecdote, as presented, it’s clear that AQ&V has a lot of problems with network performance – obviously, if you’re not fixing problems, problems will remain unresolved.
But it’s unsurprising that Mike wasn’t able to make headway in solving the problem – the problem wasn’t just that nothing was actually getting fixed, but that management didn’t care that nothing was getting fixed.
It’s not just that management blocked Mike’s kludge of a solution – but that they refused to acknowledge that there was a problem to begin with. What Mike should have done was try to get management on board first, before writing a single line of code. The first step in trying to improve any process in IT is convincing the people with the power to make decisions that the current process is flawed.
If Mike was unable to convince management that the process needed to be solved, he would have been no worse off than he was at the end of the story; if he was able to convince management that there was a problem, then he might have been able to bring more resources to bear and instead of writing a kludge, actually spend time and effort on improving the process with a more stable solution to the problem.
We’re technical people and because of that, we tend to think that the solutions to problems are often technical. The right code, the right script, and the problems are solved. The problem is that enterprise computing isn’t just technical knowledge, it’s also social interaction – meeting needs, and convincing people that needs exist and should be met. Because of this, tools that help you take information from your network and present them in a simple, easy to understand way can be just as important as tools which directly solve problems – the former to convince management of the need for the latter.
This story reminds me of rudimentary ITIL principals and the requirement for the “people” part to participate in the process change. Incident Management may be the first step most organizations get under control – but that’s not just entering tickets. It’s also finding the quickest way to restore service. Problem management—solving problems—is much easier when Incident Management is done right because you’ll have priorities and begin to see patterns, but “AQ&V” wasn’t even scratching the surface on Incident Management, so there was little chance to evolve. The situation was like a bad sitcom.
No comments yet.