So you probably presume I am entering some tirade in which explain the story of someone insisting that there is a network issue, and after days or weeks the issue is finally found out to not be a network issue, leaving me the unsung hero. Well, this is not that story, if you have been in the network business for any period of time you have this happen many times, and my story is no more unique then yours. While it does help to to relieve some of that frustration, not much to be gained from it.
So instead I am here to say, that it is really a network problem until the problem is resolved, at which point, unless it is going to cost you a job, it doesn’t matter who’s fault it is anyway. Perhaps your thinking, easier said then done, but the way I have tackled these situations is two fold.
TLDR: First I use this as an opportunity to work with another organization, and the other is I use it to learn about another aspect of IT.
In my experience people have the disposition that they didn’t change anything, so there must be something wrong with the network. I truly believe that the network is blamed more than any other aspect of the environment, fair or unfair, it doesn’t really matter. It is easy to say it’s not a network issues and walk away with your facts, but it’s helpful to include yourself in the discussion. Building the relationship’s with people in different organizations, allows you to be seen in a positive light, and if you do this often enough you become, “the guy” which is worth it’s weight in gold come review time. Do this often enough, and you have an nice a group of people who are willing to help you out, and not looking to burn you if in fact it was your issue. The other avenue is to fuel your ego, proclaim to anyone listening how right you were from the beginning and be shocked why people don’t want to work with you after a few years.
Second, it is impossible to know every aspect of your environment, but it helps to know as much as you can. Learning architecture issues by understanding how applications and services work will help you out. Taking the time to understand the issues people are having, require you to understand the flow of traffic and thus the architecture of the app. Grab the application owners who are having issues, and let them brain dump everything they know. Do this enough, and you end up with institutional knowledge that is not many others will have.
There is a way to be self-serving (you gain knowledge and build relationships) and helping people you work with in identifying issues. If it is truly not your issue, show them how you know, if you are unable to convince them good chances you are not articulating yourself well enough.
One quick disclaimer, obviously there can be some situations where this tactic won’t work, like a volatile environment or when other’s are using you to fix their issues. Use your judgement, but assuming the issue is your own, will keep you the most open minded possible, not want people to throw you under the bus and help you move forward. You will be burned at least once when you are sure it is not your issue, but some obscure issue/bug turns out to be your fault.
Ultimately this is all an exercise in communication, most people just want to be heard, I won’t go deeper into that, as I have another post I am planning on the topic. If you keep yourself available, listen to what they have to say, and that should alleviate the blame game and contention.
0 Comments.