Done being a noc monkey

2»

Comments

  • networker050184networker050184 Mod Posts: 11,962 Mod
    The people that design networks well know all the pitfalls. They learn those from living through them. Troubleshooting is an essential part of learning to architect/design in my opinion.
    An expert is a man who has made all the mistakes which can be made.
  • bpennbpenn Member Posts: 499
    The people that design networks well know all the pitfalls. They learn those from living through them. Troubleshooting is an essential part of learning to architect/design in my opinion.

    Troubleshooting seems to be essential in nearly all forms of IT, to a certain degree. I consider it a skill worth developing. Hell, its helped me quite a bit at home. I have the "troubleshooting" thought process going and it allows me to focus and figure what the problem is.
    "If your dreams dont scare you - they ain't big enough" - Life of Dillon
  • ImThe0neImThe0ne Member Posts: 143
    slee335 wrote: »
    to be honest i think i learn more about networking at my last job the networks guys were a lot more friendlier and willing to teach and show me and shadow. this data center job the network guys think there the best and look down on us and when **** goes wrong blames us. NOC at my place gets no respect they way to set it up we watch and notify and don't touch and let the neteng handle it. they could throw in a secretary to do it at my place.

    Something you guys all need to understand, from an engineering standpoint, is that most of us (or IT in general) are overworked, understaffed and busy 150% of the time. It is very difficult to find an engineering team that has the time to "mentor" if you will, the lower level guys. Most of us are so swamped with projects, trouble tickets, and meetings/conference calls, that we are lucky to stop and breath for a second.

    You guys keep studying, get your certs and try to move into the JR. Admin positions. You are more likely to find someone to take you under their wing in that position, as you are on their team and vital to their operations success.

    With that being said, try not to take anything too personal. Everyone at some point or another has to pay dues, whether that be Helpdesk, NOC, Desktop support, cable tech, etc. While it isn't right for them to have a "holier than thou" attitude, they are the engineers and it does royally suck when you have multiple people touching important equipment that may or may not know what they are doing with.

    Just be patient, pay your dues, get your certs and move on!
  • UnixGuyUnixGuy Mod Posts: 4,570 Mod
    ImThe0ne wrote: »
    Something you guys all need to understand, from an engineering standpoint, is that most of us (or IT in general) are overworked, understaffed and busy 150% of the time. It is very difficult to find an engineering team that has the time to "mentor" if you will,...


    I'm gonna have to (sorry) STRONGLY disagree with this statement...From my experience, if an engineering team is overworked, this tells me few things

    1) It's either inefficiency. Simply put, the engineering team taking way too long to do tasks - There is a room for improvement.

    2) Bad management decisions, like unreasonable requests to implement stuff that don't work or under-staffing the team (again, refer to number 1, sometimes 'engineering' team isn't as busy as they think they are but sometimes it's management being cheap).

    3) Not to go over point #1 again, but it comes down to personality. Some IT professionals believe that their job is much harder than it really is. They want to make it seem like they're too busy establishing world peace and solving global warming.



    Again, I'm not trying to start an argument, but this is for the professionals in NOCs, if the engineering team isn't giving you work, from my experience; it's most probably NOT because they're busy; it's usually because they don't want to.

    I was once in this position where I was implementing a change with the NOC person who kept asking me questions DURING the change, most of those questions could be be answered from Google, I found it annoying a bit (even though I'm a very calm/patient person by nature). Don't expect to be spoon fed, but don't think that engineering work is oh so demanding that they don't have time to teach you. Most of the time they just don't want to.
    Certs: GSTRT, GPEN, GCFA, CISM, CRISC, RHCE

    Learn GRC! GRC Mastery : https://grcmastery.com 

  • jimisrvroxjimisrvrox Member Posts: 14 ■□□□□□□□□□
    UnixGuy wrote: »
    I'm gonna have to (sorry) STRONGLY disagree with this statement...From my experience, if an engineering team is overworked, this tells me few things

    1) It's either inefficiency. Simply put, the engineering team taking way too long to do tasks - There is a room for improvement.

    2) Bad management decisions, like unreasonable requests to implement stuff that don't work or under-staffing the team (again, refer to number 1, sometimes 'engineering' team isn't as busy as they think they are but sometimes it's management being cheap).

    3) Not to go over point #1 again, but it comes down to personality. Some IT professionals believe that their job is much harder than it really is. They want to make it seem like they're too busy establishing world peace and solving global warming.



    Again, I'm not trying to start an argument, but this is for the professionals in NOCs, if the engineering team isn't giving you work, from my experience; it's most probably NOT because they're busy; it's usually because they don't want to.

    I was once in this position where I was implementing a change with the NOC person who kept asking me questions DURING the change, most of those questions could be be answered from Google, I found it annoying a bit (even though I'm a very calm/patient person by nature). Don't expect to be spoon fed, but don't think that engineering work is oh so demanding that they don't have time to teach you. Most of the time they just don't want to.

    So, just an update here: I decided to be proactive and started pulling email tickets and asking the engineer to do a webex w me while they were working the issue. That has been valuable learning. #2 Instead of immediately transferring a call over I have tried to do TS myself with the customer... (Eye opening experience that says gh **** how much has the Cisco memory eroded from lack of both study and just doing it all the time) 3. Decided that I wanted to look into Datacenter and started reading my vSphere 5 book and asking questions. Thus far, doing these things has ended up gaining me a more solid relationship w the DC team lead (like dont worry we'll take care of you kinda thing) and telling my sup that I wanted to move up (having already established that relationship) has gained me the (ill recommend you verbage) so when the time is right, it appears the transistion will be a good one. One major thing that is very true in these latest posts from yall is we are definitely understaffed and consequently our engineers are overworked. Now, luckly I work with some people who I will approach and say hey im interested in learning this stuff do you think you could work the ticket w me and usually thats gotten me results. To me, Googling for answers is much more inefficient use of time when you have a human eyes n brain that can ID stuff much quicker. I understand the idea but dont necessarily agree with it unless youre on your own and then you dont really have much of a choice.
  • UnixGuyUnixGuy Mod Posts: 4,570 Mod
    @ jimisrvrox : good work!! That's a good attitude. Do what you can on your own and keep studying. Good luck!
    Certs: GSTRT, GPEN, GCFA, CISM, CRISC, RHCE

    Learn GRC! GRC Mastery : https://grcmastery.com 

Sign In or Register to comment.