On 8/24/10 7:28 AM, James R Grinter wrote:
>
> On 23 Aug 2010, at 20:52, Joe McDonagh<[email protected]>  wrote:
>
>> Forgot to hit send to list, apologies.
>>
>> On 08/23/2010 03:50 PM, Joe McDonagh wrote:
>>>
>>> An assumption I have is that if you are a Systems Administrator you
>>> already have a basic understanding of networking. I would not consider
>>> myself a master of networking or a 'network guy', but I sure do know
>>> enough to make sure some basic things work.
>>>
>
> I too would hope that sysadmins know the basics of TCP/IP networking - these 
> days everything we do involves packets on a network at some point. (Stevens' 
> TCP/IP illustrated vol 1 is my recommended starting point, for those that 
> only have an ad-hoc understanding)
>

I know enough to understand that it's not magic, and to do 
troubleshooting from the systems side of things.  But my goal is to 
learn enough to have coherent conversations with the network person so 
that I understand what she is talking about, beyond "it no worky". Both 
so that I don't end up being the manager who has no clue what their 
staff does, and also so that I can represent her correctly in meetings 
with my management.

I also set the expectation with my group that they learn more about the 
things they are responsible for than "double-click the installer. done". 
I don't expect them to be experts in everything, but I do expect them to 
have an understanding of the field beyond what we've done.  Too often in 
my career I've seen a bunch of "duct-tape" type work done only because 
the responsible parties didn't take the time to see what was possible 
with what they already had.

By setting that expectation for my group I have no choice but to learn 
more about networking than "call this extension and ask for this person".

Am I going to be the default backup person (if I get that far)?  Most 
likely not, and was never my intention. I currently have to focus on too 
many other things during the work day and not sure how far I will get 
with my reading during my free time. But we do need something and soon. 
  My original post was a day after a 20hr network outage, while the 
network person was on vacation and unreachable.

> I would say that one of the most useful things to find out/ get an 
> understanding of is what the reseller/ vendor support escalation path is, 
> what your contracts cover (and what needs to be adjusted when new kit is 
> acquires or old kit decommissioned etc), so that you can support your network 
> specialist that way.
>

Being able to talk networking will also help me avoid using horrible 
vendors.  The one that came in to fix our network issue recently is 
decent, been with us for years, but a few things that he did didn't 
leave me with a warm fuzzy feeling.  But not knowing anything at that 
level I was unable to tell if it was just my lack of knowledge on the 
subject or it really was something to be worried about.


> Also - as this is a new member of staff joining - help them by mapping out 
> what previous decisions were made about networking strategy, why some things 
> were done the way they were (and, equally as important, who made them and 
> still has a vested or emotional interest in them!)
>

Actually, I'm the new guy in the entire equation (as in within the past 
3 months new).  The 'new' group is made up of Lone wolves that have been 
here for 5+ years before I came along.  Previously all IT employees 
(20+) reported directly to the CTO, and everyone went about doing things 
their own way.




_______________________________________________
Discuss mailing list
[email protected]
http://lopsa.org/cgi-bin/mailman/listinfo/discuss
This list provided by the League of Professional System Administrators
 http://lopsa.org/

Reply via email to