common time-management mistake: rack & stack
Randy's P-Touch thread brings up an issue I think is worth some discussion. I have noticed that a lot of very well-paid, sometimes well-qualified, networking folks spend some of their time on "rack & stack" tasks, which I feel is a very unwise use of time and talent. Imagine if the CFO of a bank spent a big chunk of his time filling up ATMs. Flying a sharp router jockey around to far-flung POPs to install gear is just as foolish. Not only does the router jockey cost a lot more to employ than a CCNA, but if your senior-level talent is wasting time in airports and IBXes, that is time they can't be doing things CCNAs can't. I was once advising a client on a transit purchasing decision, and a fairly-large, now-defunct tier-2 ISP was being considered. We needed a few questions about their IPv6 plans answered before we were comfortable. The CTO of that org was the only guy who was able to answer these questions. After waiting four days for him to return our message, he reached out to us from an airplane phone, telling us that he had been busy racking new routers in several east-coast cities (his office was not east-coast) and that's why he hadn't got back to us yet. As you might imagine, the client quickly realized that they didn't want to deal with a vendor whose CTO spent his time doing rack & stack instead of engineering his network or engaging with customers. If he had simply said he was on vacation, we would never have known how poorly the senior people at that ISP managed their time. With apologies to Randy, let the CCNAs fight with label makers. -- Jeff S Wheeler <jsw@inconcepts.biz> Sr Network Operator / Innovative Network Concepts
With apologies to Randy, let the CCNAs fight with label makers.
No, your CTO shouldn't be racking and stacking routers all the time. The fundamental concept of an organizational hierarchy dictates that. But a CTO who has lost touch with the challenges inherent in racking and stacking a router can't effectively support his team. See the TV series 'undercover boss' for a (possibly trite and clichéd) example of this. "Your position never gives you the right to command. It only imposes on you the duty of so living your life that others can receive your orders without being humiliated." --Dag Hammarskjold
On Fri, Feb 17, 2012 at 3:34 AM, Nathan Eisenberg <nathan@atlasnetworks.us> wrote:
No, your CTO shouldn't be racking and stacking routers all the time. The fundamental concept of an organizational hierarchy dictates that. But a CTO who has lost touch with the challenges inherent in racking and stacking a router can't effectively support his team. See the TV series 'undercover boss' for a (possibly trite and clichéd) example of this.
I'm not suggesting it's a crime for the CTO to put his eyes and hands on a POP local to his office once in a while, or pay a visit to his gear in a city where he happens to be in to conduct business that requires the presence of the CTO, not a CCNA. On Fri, Feb 17, 2012 at 3:17 AM, Brandon Butterworth <brandon@rd.bbc.co.uk> wrote:
It's not a waste, it's therapeutic, breaks the monotony of a desk job, you get a bit of exercise. Doing something mindless can help clear your thoughts, engineering yoga.
This, however, is exactly the kind of thinking that produces bad managers. Yes, it can be boring sitting at a desk all day. If that is your job, don't ignore it so you can play site tech while to-do's pile up in your absence. If your are a senior decision-maker, don't set a bad example for everyone else in your org by blowing off your senior-level duties to fly around the globe doing something that you have CCNAs for. The "my desk-job is boring so I spent the day racking gear" message is fine if you are not blowing off real work to push boxes through the co-lo. If that's your hobby, fine, but rack & stack is not part of the CTO, network engineer, or whatever, job. It's a hobby and you shouldn't ignore your actual duties to go do it. It's no better than spending the workday at the movie theater or playing world of warcraft at the office. On Fri, Feb 17, 2012 at 3:14 AM, Justin Twiss <Justin.Twiss@bekkers.com.au> wrote:
Unfortuantely, some of us work for companies with limited numbers of staff so in effect, the CTO does whatever work is necessary to get the job done and keep the client happy, whether that be rack & stack, decommission, BGP peering or even disaster mitigation...
If you don't have any junior-level employees to do the junior-level work, yes, this is certainly true. But as soon as that "CTO," who is also wearing a bunch of other hats, finds himself with a long to-do list, the first thing he ought to do is delegate tasks like rack & stack to inexpensive workers so he can use his most valuable strengths. Obviously we are throwing around the term "CTO" at this point in reference to pretty small businesses, but the basic concept here is, don't let mundane tasks get in the way of work you are specially qualified to do. Definitely don't go out of your way to do mundane tasks so you can play IBX tourist on your company's dime! -- Jeff S Wheeler <jsw@inconcepts.biz> Sr Network Operator / Innovative Network Concepts
I was once advising a client on a transit purchasing decision, and a fairly-large, now-defunct tier-2 ISP was being considered. We needed a few questions about their IPv6 plans answered before we were comfortable. The CTO of that org was the only guy who was able to answer these questions. After waiting four days for him to return our message, he reached out to us from an airplane phone, telling us that he had been busy racking new routers in several east-coast cities (his office was not east-coast) and that's why he hadn't got back to us yet.
As you might imagine, the client quickly realized that they didn't want to deal with a vendor whose CTO spent his time doing rack & stack instead of engineering his network or engaging with customers. If he had simply said he was on vacation, we would never have known how poorly the senior people at that ISP managed their time.
on the contrary, we'd PREFER if CEO's and CTO's of our trading partners know what their company is doing and how their core network actually works. (Rather than just giving one of those stupid flyers with a world map and some lines representing their network to potential customers ;) no "startrek questions pls". :P. (and rack & stack with "routers" is something else than rack & stack with serverfarms, as for servers, you can just as well have an installation company or the vendor do it for you ("clearance" issues set aside ;).. with routers its a bit more touchy which wire goes where exactly, and furthermore, they have to be individually configured during install, so its better to just be there, CTO or not CTO :P you might be confusing the CTO for the sales manager :P
Hi, Or sometimes you don't let a hazardous task like handling a Carrier Class Router to your CCNA in case they injure themself. Or worst... drop it =D ( From an actual experience ) ----- Alain Hebert ahebert@pubnix.net PubNIX Inc. 50 boul. St-Charles P.O. Box 26770 Beaconsfield, Quebec H9W 6G7 Tel: 514-990-5911 http://www.pubnix.net Fax: 514-990-9443 On 02/17/12 02:29, Jeff Wheeler wrote:
Randy's P-Touch thread brings up an issue I think is worth some discussion. I have noticed that a lot of very well-paid, sometimes well-qualified, networking folks spend some of their time on "rack& stack" tasks, which I feel is a very unwise use of time and talent.
Imagine if the CFO of a bank spent a big chunk of his time filling up ATMs. Flying a sharp router jockey around to far-flung POPs to install gear is just as foolish.
Not only does the router jockey cost a lot more to employ than a CCNA, but if your senior-level talent is wasting time in airports and IBXes, that is time they can't be doing things CCNAs can't.
I was once advising a client on a transit purchasing decision, and a fairly-large, now-defunct tier-2 ISP was being considered. We needed a few questions about their IPv6 plans answered before we were comfortable. The CTO of that org was the only guy who was able to answer these questions. After waiting four days for him to return our message, he reached out to us from an airplane phone, telling us that he had been busy racking new routers in several east-coast cities (his office was not east-coast) and that's why he hadn't got back to us yet.
As you might imagine, the client quickly realized that they didn't want to deal with a vendor whose CTO spent his time doing rack& stack instead of engineering his network or engaging with customers. If he had simply said he was on vacation, we would never have known how poorly the senior people at that ISP managed their time.
With apologies to Randy, let the CCNAs fight with label makers.
actually most west european countries have laws against having your employees lift up stuff heavier than 20 kilos :P you generally don't have insurance on your network-dude to handle such things *grin* if it drops on his foot, you're screwed. (or worse, on his hand ;) looking at the latest models we found units weighing 110 kilos *grin* i'm not lifting -that- up. -- Greetings, Sven Olaf Kamphuis, CB3ROB Ltd. & Co. KG ========================================================================= Address: Koloniestrasse 34 VAT Tax ID: DE267268209 D-13359 Registration: HRA 42834 B BERLIN Phone: +31/(0)87-8747479 Germany GSM: +49/(0)152-26410799 RIPE: CBSK1-RIPE e-Mail: sven@cb3rob.net ========================================================================= <penpen> C3P0, der elektrische Westerwelle http://www.facebook.com/cb3rob ========================================================================= Confidential: Please be advised that the information contained in this email message, including all attached documents or files, is privileged and confidential and is intended only for the use of the individual or individuals addressed. Any other use, dissemination, distribution or copying of this communication is strictly prohibited. On Fri, 17 Feb 2012, Alain Hebert wrote:
Hi,
Or sometimes you don't let a hazardous task like handling a Carrier Class Router to your CCNA in case they injure themself.
Or worst... drop it =D
( From an actual experience )
----- Alain Hebert ahebert@pubnix.net PubNIX Inc. 50 boul. St-Charles P.O. Box 26770 Beaconsfield, Quebec H9W 6G7 Tel: 514-990-5911 http://www.pubnix.net Fax: 514-990-9443
On 02/17/12 02:29, Jeff Wheeler wrote:
Randy's P-Touch thread brings up an issue I think is worth some discussion. I have noticed that a lot of very well-paid, sometimes well-qualified, networking folks spend some of their time on "rack& stack" tasks, which I feel is a very unwise use of time and talent.
Imagine if the CFO of a bank spent a big chunk of his time filling up ATMs. Flying a sharp router jockey around to far-flung POPs to install gear is just as foolish.
Not only does the router jockey cost a lot more to employ than a CCNA, but if your senior-level talent is wasting time in airports and IBXes, that is time they can't be doing things CCNAs can't.
I was once advising a client on a transit purchasing decision, and a fairly-large, now-defunct tier-2 ISP was being considered. We needed a few questions about their IPv6 plans answered before we were comfortable. The CTO of that org was the only guy who was able to answer these questions. After waiting four days for him to return our message, he reached out to us from an airplane phone, telling us that he had been busy racking new routers in several east-coast cities (his office was not east-coast) and that's why he hadn't got back to us yet.
As you might imagine, the client quickly realized that they didn't want to deal with a vendor whose CTO spent his time doing rack& stack instead of engineering his network or engaging with customers. If he had simply said he was on vacation, we would never have known how poorly the senior people at that ISP managed their time.
With apologies to Randy, let the CCNAs fight with label makers.
On Fri, 17 Feb 2012, Sven Olaf Kamphuis wrote:
actually most west european countries have laws against having your employees lift up stuff heavier than 20 kilos :P
IT job postings in the US often include physical qualifiers such as "must be able to lift weights of up to 50 pounds (~22.7 kilos)" and "must be able to use hand tools". The lecture about using safe lifting practices usually waits until after you accept the job and go through your new-employee orientation :) jms
On 2/17/12 06:18 , Sven Olaf Kamphuis wrote:
actually most west european countries have laws against having your employees lift up stuff heavier than 20 kilos :P
you generally don't have insurance on your network-dude to handle such things *grin* if it drops on his foot, you're screwed. (or worse, on his hand ;)
looking at the latest models we found units weighing 110 kilos *grin* i'm not lifting -that- up.
http://www.serverlift.com/solutions/products/sl500x-server-lift/
In a message written on Fri, Feb 17, 2012 at 02:29:36AM -0500, Jeff Wheeler wrote:
Randy's P-Touch thread brings up an issue I think is worth some discussion. I have noticed that a lot of very well-paid, sometimes well-qualified, networking folks spend some of their time on "rack & stack" tasks, which I feel is a very unwise use of time and talent.
At the risk of offending many folks on NANOG, our industry is more like a trade than a profession. In many cases we would do better to treat our people (in terms of how they are managed) like skilled trades, electricians, plumbers, metal fitters, rather than pretend they are white collar professionals. Low level employees should be apprenticed by higher level employees. Many of our skills are learned on the job; just like other trades someone with only book knowledge is darn near useless. Not only do those above need to teach, but they need to supervise, and exercise standards and quality control. To your point, if you look at skilled trades the simpler the task the more likely it will fall to the "new guy". Rack and stack is probably one of simplest jobs in our industry. A two man team, one senior, one junior, showing up at a colo may see the junior guy doing the physical work, while the senior guy works out any issues with the colo provider brings up the interconnection to them, etc. But key to an apprenticeship is that the senior guy does some of the low level work some of the time, and _shows_ the junior guy how to do it right. The senior guy might rack or stack a couple of boxes each colo they visit, and relate concepts like how the screw hole spacing works in the rack rails, how to plan cable management, proper labeling, and so on. It really accomplishes much of what everyone else is talking about, while still being productive. The "old hat" gets the downtime and catharsis of doing a simple, yet productive task. The new guy gets to learn how to do the job properly. The employer knows the work has been done right, as it was overseen by the old hat, and that they will have someone to replace him when the old hat retires. Maybe if we did more apprecenship style learning folks would still know how to wrap cables with wax string. It's simple, fast, and works well. -- Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/
-----Original Message----- From: Leo Bicknell [mailto:bicknell@ufp.org] Sent: Friday, February 17, 2012 6:46 AM To: NANOG Subject: Re: common time-management mistake: rack & stack
Low level employees should be apprenticed by higher level employees. Many of our skills are learned on the job; just like other trades someone with only book knowledge is darn near useless. Not only do those above need to teach, but they need to supervise, and exercise standards and quality control.
+1 I believe that can not be stressed enough. There is also another aspect to it in that about 15% of the population of people are "abstract" thinkers and 85% are "concrete" thinkers. The abstract thinkers are the ones who can come up with a vision in their head of how something should work as a system and then set out and build it. Or when they are faced with a problem, can in their head envision the work around and then apply that vision on site to do things such as rewire a portion of the network in a methodical fashion with no/little downtime. Those people are relatively rare and working with your line staff gives one an opportunity to assess the various talent sets of the people in the organization. The abstract thinkers are the ones good at being able to design a network from scratch and the concrete thinkers are the ones who will be great maintaining that network and keeping everything documented and done according to policy. You need both and it just so happens that you need more of one sort in just about the same proportion that you find them in the general population. The key is to identify which people have which talents and place them where their natural abilities more closely mesh with their job requirements. If you can do that, you can have a very powerful team. If you place people into positions simply based on the number of years in the organization or because of holes punched in the cert ticket, you might end up with people in positions that they don't really like or aren't particularly good at doing. The first step in building such an organization, though, is working closely with your people and attempting to identify whose natural abilities like in which direction. Sometimes it is more about talent than training, more about nature than nurture.
To your point, if you look at skilled trades the simpler the task the more likely it will fall to the "new guy". Rack and stack is probably one of simplest jobs in our industry. A two man team, one senior, one junior, showing up at a colo may see the junior guy doing the physical work, while the senior guy works out any issues with the colo provider brings up the interconnection to them, etc.
But at the same time, if you have a guy who might not be so sharp at troubleshooting a very complex network but is sharp as a tack when it comes to documenting things and keeping paperwork organized, that is a vital skill in the overall effort, too. That person should be given responsibility for maintaining more of the documentation, organizing things so they are easy for other employees to find, etc. and their pay should still continue to increase as they gain wider scope across more of the organization over time. The point is that it often takes many different sorts of skills and attempting to match people's natural talents to the requirements of the organization benefits both parties provided the individual involved doesn't see their position as a dead end. A good person of the sort mentioned above can literally save hours of time for people doing other tasks such as troubleshooting a problem. There is a certain synergy involved and some organizations recognize that, and some don't. Some are better in an architectural role, some are naturally better in a sustaining role, others are better at an organizational support role and (darned) few are good at all of those tasks. Sometimes we don't have the luxury of such specialization of roles, but some organizations do, particularly if they are in a phase of reorganization and downsizing. One thing to look at might not only be "how good is this person in their current role" but also "would this person absolutely kick butt in a different role".
But key to an apprenticeship is that the senior guy does some of the low level work some of the time, and _shows_ the junior guy how to do it right. The senior guy might rack or stack a couple of boxes each colo they visit, and relate concepts like how the screw hole spacing works in the rack rails, how to plan cable management, proper labeling, and so on.
Actually, just having the senior person assist with some tasks such as moving/installing heavy/unwieldy gear does more than just show them how to do it right, it is actually quite an important almost sort of bonding experience between employees. It says "I'm not allergic to work and not above doing the same job you are doing when it needs to get done, we are all important pieces of the big picture." It can give an employee a sense that they are respected and appreciated for the job they do, even if it is fairly low on the corporate org chart. It is still vital to the success of the overall business or they wouldn't be there to begin with. Doing things like this telegraphs that in a tangible way without having to spew a lot of corporate propaganda.
It really accomplishes much of what everyone else is talking about, while still being productive. The "old hat" gets the downtime and catharsis of doing a simple, yet productive task. The new guy gets to learn how to do the job properly. The employer knows the work has been done right, as it was overseen by the old hat, and that they will have someone to replace him when the old hat retires.
The "old hat" still gets job satisfaction from seeing a vision come to physical life and operate as planned. Why deprive them of that? It can re-energize one's love of a particular carrier field and remind them why they are in that field to begin with.
Maybe if we did more apprecenship style learning folks would still know how to wrap cables with wax string. It's simple, fast, and works well.
Leo, in many trades, telecommunications being one of them, the military was one source of new people with some skills and with some hands-on experience. As that scales back these days, it gets harder to find such people. We don't have trade schools and we don't have apprenticeship programs like companies used to have so I agree. People coming out of a community college or a certification program know enough to be extremely dangerous (sort of like a lieutenant with a screwdriver, the most dangerous person in the world aside from a corporal with a clipboard) and need to be mentored as they gain perspective in real world situations. I completely agree that we should be looking more at our employees in the longer term as a nurturing process and identifying where their natural interests and abilities can benefit both sides of the equation. Having that interaction with the senior staff is vital. And that senior staff member should not only be explaining WHAT he is doing, but WHY he is doing it that way.
On Fri, Feb 17, 2012 at 11:15 AM, George Bonser <gbonser@seven.com> wrote:
-----Original Message----- From: Leo Bicknell [mailto:bicknell@ufp.org] Sent: Friday, February 17, 2012 6:46 AM To: NANOG Subject: Re: common time-management mistake: rack & stack
Low level employees should be apprenticed by higher level employees. Many of our skills are learned on the job; just like other trades someone with only book knowledge is darn near useless. Not only do those above need to teach, but they need to supervise, and exercise standards and quality control.
+1 I believe that can not be stressed enough. There is also another aspect to it in that about 15% of the population of people are "abstract" thinkers and 85% are "concrete" thinkers. The abstract thinkers are the ones who can come up with a vision in their head of how something should work as a system and then set out and build it. Or when they are faced with a problem, can in their head envision the work around and then apply that vision on site to do things such as rewire a portion of the network in a methodical fashion with no/little downtime. Those people are relatively rare and working with your line staff gives one an opportunity to assess the various talent sets of the people in the organization. The abstract thinkers are the ones good at being able to design a network from scratch and the concrete thinkers are the ones who will be great maintaining that network and keeping everything documented and done according to policy. You need both and it just so happens that you need more of one sort in just about the same proportion that you find them in the general population. The key is to identify which people have which talents and place them where their natural abilities more closely mesh with their job requirements. If you can do that, you can have a very powerful team. If you place people into positions simply based on the number of years in the organization or because of holes punched in the cert ticket, you might end up with people in positions that they don't really like or aren't particularly good at doing. The first step in building such an organization, though, is working closely with your people and attempting to identify whose natural abilities like in which direction. Sometimes it is more about talent than training, more about nature than nurture.
To your point, if you look at skilled trades the simpler the task the more likely it will fall to the "new guy". Rack and stack is probably one of simplest jobs in our industry. A two man team, one senior, one junior, showing up at a colo may see the junior guy doing the physical work, while the senior guy works out any issues with the colo provider brings up the interconnection to them, etc.
But at the same time, if you have a guy who might not be so sharp at troubleshooting a very complex network but is sharp as a tack when it comes to documenting things and keeping paperwork organized, that is a vital skill in the overall effort, too. That person should be given responsibility for maintaining more of the documentation, organizing things so they are easy for other employees to find, etc. and their pay should still continue to increase as they gain wider scope across more of the organization over time. The point is that it often takes many different sorts of skills and attempting to match people's natural talents to the requirements of the organization benefits both parties provided the individual involved doesn't see their position as a dead end. A good person of the sort mentioned above can literally save hours of time for people doing other tasks such as troubleshooting a problem. There is a certain synergy involved and some organizations recognize that, and some don't. Some are better in an architectural role, some are naturally better in a sustaining role, others are better at an organizational support role and (darned) few are good at all of those tasks. Sometimes we don't have the luxury of such specialization of roles, but some organizations do, particularly if they are in a phase of reorganization and downsizing. One thing to look at might not only be "how good is this person in their current role" but also "would this person absolutely kick butt in a different role".
But key to an apprenticeship is that the senior guy does some of the low level work some of the time, and _shows_ the junior guy how to do it right. The senior guy might rack or stack a couple of boxes each colo they visit, and relate concepts like how the screw hole spacing works in the rack rails, how to plan cable management, proper labeling, and so on.
Actually, just having the senior person assist with some tasks such as moving/installing heavy/unwieldy gear does more than just show them how to do it right, it is actually quite an important almost sort of bonding experience between employees. It says "I'm not allergic to work and not above doing the same job you are doing when it needs to get done, we are all important pieces of the big picture." It can give an employee a sense that they are respected and appreciated for the job they do, even if it is fairly low on the corporate org chart. It is still vital to the success of the overall business or they wouldn't be there to begin with. Doing things like this telegraphs that in a tangible way without having to spew a lot of corporate propaganda.
It really accomplishes much of what everyone else is talking about, while still being productive. The "old hat" gets the downtime and catharsis of doing a simple, yet productive task. The new guy gets to learn how to do the job properly. The employer knows the work has been done right, as it was overseen by the old hat, and that they will have someone to replace him when the old hat retires.
The "old hat" still gets job satisfaction from seeing a vision come to physical life and operate as planned. Why deprive them of that? It can re-energize one's love of a particular carrier field and remind them why they are in that field to begin with.
Maybe if we did more apprecenship style learning folks would still know how to wrap cables with wax string. It's simple, fast, and works well.
Leo, in many trades, telecommunications being one of them, the military was one source of new people with some skills and with some hands-on experience. As that scales back these days, it gets harder to find such people. We don't have trade schools and we don't have apprenticeship programs like companies used to have so I agree. People coming out of a community college or a certification program know enough to be extremely dangerous (sort of like a lieutenant with a screwdriver, the most dangerous person in the world aside from a corporal with a clipboard) and need to be mentored as they gain perspective in real world situations. I completely agree that we should be looking more at our employees in the longer term as a nurturing process and identifying where their natural interests and abilities can benefit both sides of the equation. Having that interaction with the senior staff is vital. And that senior staff member should not only be explaining WHAT he is doing, but WHY he is doing it that way.
Knowledge transfer should also include the very important WHY NOT to do something a certain way. This part is often left out. Considering that most bit-twiddler tasks can be performed a multitude of ways, both sides of the argument should be presented. Perhaps this is obvious to all on the list, but it's certainly not to junior staff.
----- Original Message -----
From: "Leo Bicknell" <bicknell@ufp.org>
Maybe if we did more apprecenship style learning folks would still know how to wrap cables with wax string. It's simple, fast, and works well.
Cue the obligatory cabling porn thread. Cheers, -- jr 'and aren't all the old Bell guys dead now?' a -- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274
-----Original Message----- From: Leo Bicknell [mailto:bicknell@ufp.org]
At the risk of offending many folks on NANOG, our industry is more
like
a trade than a profession. In many cases we would do better to treat our people (in terms of how they are managed) like skilled trades, electricians, plumbers, metal fitters, rather than pretend they are white collar professionals.
Low level employees should be apprenticed by higher level employees. Many of our skills are learned on the job; just like other trades someone with only book knowledge is darn near useless. Not only do those above need to teach, but they need to supervise, and exercise standards and quality control.
I disagree. The best model is - gasp - engineering, a profession which many in "networking" claim to be a part of, but few actually are. In the engineering world (not CS, not development - think ME and EE), there is a strongly defined relationship between junior and senior engineers, and real mentorship. The problem with "networking" is that TOO MANY skills are learned on the job (poorly), rather than folks coming in with solid fundamentals. I blame our higher education system for being ineffectual in this regard. Most of the "book learning" that you refer to is not true theory - it's a mix of vendor prescriptions and overgeneralizations. In "networking", you don't learn real theory until you're very senior - you learn practice, first. The true problem is that most "networking" professionals came out of a CS background or are self-taught. They might be clueful and they might be highly adept, but they lack the structure of an engineering educations and formal mentorship. They also lack real licensing, which is a separate problem.
To your point, if you look at skilled trades the simpler the task the more likely it will fall to the "new guy". Rack and stack is probably one of simplest jobs in our industry. A two man team, one senior, one junior, showing up at a colo may see the junior guy doing the physical work, while the senior guy works out any issues with the colo provider brings up the interconnection to them, etc.
Rack and stack is not a network engineer task, anymore than running a 208/3 phase circuit is an electrical engineer's task. Instead, rack and stack is a task for a skilled telecom tradesman. I have nothing against network engineers getting out of the office to do this, but the quality of their work will never be up to a real telecom guy. Look at the cabling. You can always tell which has been done by a "network engineer" and which has been done by a real tradesman. Guess which one is better? Dan
On Wednesday, February 22, 2012 03:37:57 PM Dan Golding wrote:
I disagree. The best model is - gasp - engineering, a profession which many in "networking" claim to be a part of, but few actually are. In the engineering world (not CS, not development - think ME and EE), there is a strongly defined relationship between junior and senior engineers, and real mentorship.
My degree is in EE, and I spent over a decade in the field as a 'broadcast engineer' Now, a 'broadcast engineer' is not a PE, and is not currently licensed as such, although many of the best consulting broadcast engineers do take the extra step and expense to get the PE license; technically, in many states, you're not even supposed to use the word 'engineer' in your title without having a PE license. By way of background, my specialty was phased array directional AM broadcast systems in the 5-50KW range, doing 'technician' things like phasor rocking, transmitter retubing and retuning, monitor point and radial measurements, transmitter installation, and tower climbing, in addition to more mathematical and engineering sorts of things like initial coverage and protection studies for pattern/power changes, measured radial ground conductivity/dielectric constant curve fitting/prediction contour overlap studies and models, as well as keeping up with FCC regulations and such. I left broadcasting full-time in 2003 for an IT position, as a stress-reducer (and it worked.). So I say this with some experience. Mentoring in broadcast is still practiced by associations like the Society of Broadcast Engineers and others. These days, much of this sort of thing is online with websites like www.thebdr.net and mailing lists like those hosted by broadcast.net; in this regard the network ops community isn't too dissimilar from the broadcast community. Now, while in the broadcast role I had the distinct honor of having three fantastic personal mentors, two of whom still stay in touch, and one who died twenty years ago, a few years after I got started in the field. RIP W4QA. He taught me more in half an hour about phased arrays and the way they worked in practice than ten hours of class time could have. Likewise, I know some old hands here, even if I've not physically met them, whose opinions I trust, even if I don't agree with them.
The problem with "networking" is that TOO MANY skills are learned on the job (poorly), rather than folks coming in with solid fundamentals.
This is not limited to networking. The parallels between broadcast engineering and IT/networking are a little too close for comfort, since there are more potential mentors with weak teaching skills and bad misconceptions that were valid 'back in the day' than there are who will teach practical, working, correct ways of doing things 'today' and why they are done the way they are done (which can involve some history, one of my favorite things). A mentor who will teach how to think about why you are doing what you are doing is priceless. A mentor who will honestly go over the pros and cons of his or her favorite technique and admit that is isn't the single 'correct' way to do something, and a mentor who will teach you how to think sideways, especially when things are broken, are beyond priceless. I especially like it when a mentor has told me 'now, this isn't necessarily the way I'd do it, and I'm not really fond of it, but you *can* do this to get this result if you need to do so...just don't ask me to fix it later.' And the recent thread on common misconceptions has been priceless, in my book. Especially due to some of the respectful disagreements.
I blame our higher education system for being ineffectual in this regard. Most of the "book learning" that you refer to is not true theory - it's a mix of vendor prescriptions and overgeneralizations. In "networking", you don't learn real theory until you're very senior - you learn practice, first.
Vendor-specific certifications don't help much, either, really, in the 'why' department.
They also lack real licensing, which is a separate problem.
Now you've stirred the pot! In the broadcast field, SBE offers some good things in the line of vendor-neutral certification; in the networking field there are some vendor-neutral avenues, such as BiCSI for general stuff and SANS for security stuff. Having said that, and going back to the broadcast example, not too long ago you had to have an FCC 'First Phone' to even be qualified to read a transmitter's meters, and every broadcast licensee (holding the station's operating license, that is) had to employ 'operators' holding an active First Phone to keep an eye on the transmitter during all operating hours, with the First Phone of every operator posted at the site, and even the DJ's had to have a Third Class Permit to run the audio board, and periodic FCC inspections were frequent. So that's the extreme situation in terms of licensing, just for reference....
The problem with using engineering as a model is that computer science networking theory is based upon mathematical logic and formal mathematics (for instance Finite State Machines, Turing Machines), and operates on what are essentially robotic automatons running in real time. Engineering as I have experienced it, operates according to construction time frames using CSI specifications, preliminary design reviews, and various iterations of final design reviews involving engineering drawings and CSI-format specification documents where a 6 year start-to-finish time frame is not unusual. The number of PEs who can operate in real time is but a fraction of all PEs, and those who can plan a project with a 1 week time frame, and implement the project at 3 am in the morning is a yet smaller fraction. ( and don't even think about the number of PEs who can get a 3 am call and must fix a broken network ASAP). Not everyone has the ability to grasp mathematical logic, even though they have been able to get an engineering degree. Engineers have no peers in the ability to build bridges, skyscrapers, and other large construction projects, but this ability does not transfer to computer science, and computer networking. -----Original Message----- From: Lamar Owen [mailto:lowen@pari.edu] Sent: Thursday, February 23, 2012 10:59 AM To: nanog@nanog.org Subject: Re: common time-management mistake: rack & stack On Wednesday, February 22, 2012 03:37:57 PM Dan Golding wrote:
I disagree. The best model is - gasp - engineering, a profession which many in "networking" claim to be a part of, but few actually are. In the engineering world (not CS, not development - think ME and EE), there is a strongly defined relationship between junior and senior engineers, and real mentorship.
My degree is in EE, and I spent over a decade in the field as a 'broadcast engineer' Now, a 'broadcast engineer' is not a PE, and is not currently licensed as such, although many of the best consulting broadcast engineers do take the extra step and expense to get the PE license; technically, in many states, you're not even supposed to use the word 'engineer' in your title without having a PE license. By way of background, my specialty was phased array directional AM broadcast systems in the 5-50KW range, doing 'technician' things like phasor rocking, transmitter retubing and retuning, monitor point and radial measurements, transmitter installation, and tower climbing, in addition to more mathematical and engineering sorts of things like initial coverage and protection studies for pattern/power changes, measured radial ground conductivity/dielectric constant curve fitting/prediction contour overlap studies and models, as well as keeping up with FCC regulations and such. I left broadcasting full-time in 2003 for an IT position, as a stress-reducer (and it worked.). So I say this with some experience. Mentoring in broadcast is still practiced by associations like the Society of Broadcast Engineers and others. These days, much of this sort of thing is online with websites like www.thebdr.net and mailing lists like those hosted by broadcast.net; in this regard the network ops community isn't too dissimilar from the broadcast community. Now, while in the broadcast role I had the distinct honor of having three fantastic personal mentors, two of whom still stay in touch, and one who died twenty years ago, a few years after I got started in the field. RIP W4QA. He taught me more in half an hour about phased arrays and the way they worked in practice than ten hours of class time could have. Likewise, I know some old hands here, even if I've not physically met them, whose opinions I trust, even if I don't agree with them.
The problem with "networking" is that TOO MANY skills are learned on the job (poorly), rather than folks coming in with solid fundamentals.
This is not limited to networking. The parallels between broadcast engineering and IT/networking are a little too close for comfort, since there are more potential mentors with weak teaching skills and bad misconceptions that were valid 'back in the day' than there are who will teach practical, working, correct ways of doing things 'today' and why they are done the way they are done (which can involve some history, one of my favorite things). A mentor who will teach how to think about why you are doing what you are doing is priceless. A mentor who will honestly go over the pros and cons of his or her favorite technique and admit that is isn't the single 'correct' way to do something, and a mentor who will teach you how to think sideways, especially when things are broken, are beyond priceless. I especially like it when a mentor has told me 'now, this isn't necessarily the way I'd do it, and I'm not really fond of it, but you *can* do this to get this result if you need to do so...just don't ask me to fix it later.' And the recent thread on common misconceptions has been priceless, in my book. Especially due to some of the respectful disagreements.
I blame our higher education system for being ineffectual in this regard. Most of the "book learning" that you refer to is not true theory - it's a mix of vendor prescriptions and overgeneralizations. In "networking", you don't learn real theory until you're very senior - you learn practice, first.
Vendor-specific certifications don't help much, either, really, in the 'why' department.
They also lack real licensing, which is a separate problem.
Now you've stirred the pot! In the broadcast field, SBE offers some good things in the line of vendor-neutral certification; in the networking field there are some vendor-neutral avenues, such as BiCSI for general stuff and SANS for security stuff. Having said that, and going back to the broadcast example, not too long ago you had to have an FCC 'First Phone' to even be qualified to read a transmitter's meters, and every broadcast licensee (holding the station's operating license, that is) had to employ 'operators' holding an active First Phone to keep an eye on the transmitter during all operating hours, with the First Phone of every operator posted at the site, and even the DJ's had to have a Third Class Permit to run the audio board, and periodic FCC inspections were frequent. So that's the extreme situation in terms of licensing, just for reference.... This communication, together with any attachments or embedded links, is for the sole use of the intended recipient(s) and may contain information that is confidential or legally protected. If you are not the intended recipient, you are hereby notified that any review, disclosure, copying, dissemination, distribution or use of this communication is strictly prohibited. If you have received this communication in error, please notify the sender immediately by return e-mail message and delete the original and all copies of the communication, along with any attachments or embedded links, from your system.
In a message written on Wed, Feb 22, 2012 at 12:37:57PM -0800, Dan Golding wrote:
I disagree. The best model is - gasp - engineering, a profession which many in "networking" claim to be a part of, but few actually are. In the engineering world (not CS, not development - think ME and EE), there is a strongly defined relationship between junior and senior engineers, and real mentorship. The problem with "networking" is that TOO MANY skills
Actually, the differences are deeper than you suggest, and it's why the model you suggest won't work for networking, yet. I think there's a chance they may in the future, although it's not a given. There are several aspects to licensing, but one of the most important is that the applicant knows basic rules of the profession. In most cases these rules are codified into law, and can be tested in a straitforwad way. An EE doesn't go around saying "run your circits at 80% unless you have a 100% duty breaker" because it's a good idea, or they like it, or their vendor told them do. They do that because it's part of the National Electric Code which everyone (including non-licensed folks) is _required by law_ to follow. Networking does not have "codes". There's nothing to test against. If we wanted to apply a licensed engineer model to the networking field the first thing that would need to be developed is a set of comprehensive codes. Anyone who's experienced PCI (as an example of an IT attempt at something similar to a code) and also worked with a more established one (NEC, NFPA, etc) knows that IT isn't even in the same ballpark yet. I won't go into the reasons here, I think there are many and we could discuss that for hours. But I actually think your analogy is more misplaced because the names do not line up. The networking equivilant of an EE or ME is the "Network Architect". EE's and ME's are designers in their professions. They write up blueprints and plans. This is also what network architects do. Think a CCDA operating as a sales engineer. They draw up a design but never implement it. Network Engineers are the trades people. We come up with really dumb names like Network Enginneer 1, 2, 3 and 4. In a real trade these would be apprentice, journyman, master, supervisor. They take the plans and turn it into something. In a real trade (electrican, plumber, hvac, etc) the supervisor interacts with the apprentice, journeyman and master, who are all working on the same team. The subtasks are divided according to skill. In IT, the Network Engineer 4 thinks he only needs to talk to the Network Engineer 3. Everyone else is "below him". How many companies have Network Engineer 1's that aren't allowed to even log into many of their network devices, or call the engineer level 3's and 4's on the phone? This is absurd. Some companies even put them in different call centers sioled away from each other so they don't even know who call! This is where I think we need more mentorship and teamwork. When a team of electricans shows up the apprentice does a lot of the meanial work, but is also allowed to do some of the higher level work, under strict supervision. I think, in a sense, we agree more than disagree. There are established models for engineering disciplins and IT would probably do better in many ways if it were to fall in line. Licensed folks working in architecture and design. Codes to standardize and provide quality control and safety. Apprenticed skilled trades to implement. What we're arguing over here is some minor semantics of how that structure works in IT. HOWEVER, I am not sure it completely works. Here's why; some colleges have C.S. in the Arts and Sciences college, and treat how to program more like how to write a novel than how to build a bridge. Others have it in the Engineering college, and treat it more like building a bridge than writing an novel. What seems to work is a blend in the real world, treating most IT tasks like classical engineering doesn't work out well, nor does treating it like writing a book. IT isn't governed by the same hard (physical) rules as traditional engineering, but you also can't be freely creative and expect to come up with something that works. I personally would like to see the industry work on the "code" problem, which would be necessary pre-work for licensing. I'd also like to see trade style mentoring. I think those can proceed in parallel. I'm just personally prepared for the eventuality that IT might never fit into as ridgid a framework as EE or ME. -- Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/
1- what do you mean by "Licensed folks working in architecture and design"? 2- You wrote "IT isn't governed by the same hard (physical) rules as traditional engineering, but you also can't be freely creative and expect to come up with something that works." bolox! As far as I'm aware you are not showing any creative work that requires the copywrite/authoring work. Unfortunatly the great majority of us are "users" of the system. There are different levels of users, some more cleaver than others. The one that looks for data sets in databases in in IT and so is into "scripting" and CShell. The sponsor is the issue.He was tasked to do so! have you ever been employed or have been offered employment by someone that has a lower weight than you have? the frameworks seem to be known more and more and still................some face unemployment whereas others are and will always be your sponsors- think about the director of your local post office :-) Have you ever thought the reason why you are doing what you are doing instead of signing a PO? Who's business is this ? do you know why you are required to have at least three A levels? and at least two MSc/MA? Or even maybe a PhD? Where exactly are you based? ________________________________ From: Leo Bicknell <bicknell@ufp.org> To: Dan Golding <dgolding@ragingwire.com> Cc: NANOG <nanog@nanog.org> Sent: Thursday, February 23, 2012 7:35 PM Subject: Re: common time-management mistake: rack & stack In a message written on Wed, Feb 22, 2012 at 12:37:57PM -0800, Dan Golding wrote:
I disagree. The best model is - gasp - engineering, a profession which many in "networking" claim to be a part of, but few actually are. In the engineering world (not CS, not development - think ME and EE), there is a strongly defined relationship between junior and senior engineers, and real mentorship. The problem with "networking" is that TOO MANY skills
Actually, the differences are deeper than you suggest, and it's why the model you suggest won't work for networking, yet. I think there's a chance they may in the future, although it's not a given. There are several aspects to licensing, but one of the most important is that the applicant knows basic rules of the profession. In most cases these rules are codified into law, and can be tested in a straitforwad way. An EE doesn't go around saying "run your circits at 80% unless you have a 100% duty breaker" because it's a good idea, or they like it, or their vendor told them do. They do that because it's part of the National Electric Code which everyone (including non-licensed folks) is _required by law_ to follow. Networking does not have "codes". There's nothing to test against. If we wanted to apply a licensed engineer model to the networking field the first thing that would need to be developed is a set of comprehensive codes. Anyone who's experienced PCI (as an example of an IT attempt at something similar to a code) and also worked with a more established one (NEC, NFPA, etc) knows that IT isn't even in the same ballpark yet. I won't go into the reasons here, I think there are many and we could discuss that for hours. But I actually think your analogy is more misplaced because the names do not line up. The networking equivilant of an EE or ME is the "Network Architect". EE's and ME's are designers in their professions. They write up blueprints and plans. This is also what network architects do. Think a CCDA operating as a sales engineer. They draw up a design but never implement it. Network Engineers are the trades people. We come up with really dumb names like Network Enginneer 1, 2, 3 and 4. In a real trade these would be apprentice, journyman, master, supervisor. They take the plans and turn it into something. In a real trade (electrican, plumber, hvac, etc) the supervisor interacts with the apprentice, journeyman and master, who are all working on the same team. The subtasks are divided according to skill. In IT, the Network Engineer 4 thinks he only needs to talk to the Network Engineer 3. Everyone else is "below him". How many companies have Network Engineer 1's that aren't allowed to even log into many of their network devices, or call the engineer level 3's and 4's on the phone? This is absurd. Some companies even put them in different call centers sioled away from each other so they don't even know who call! This is where I think we need more mentorship and teamwork. When a team of electricans shows up the apprentice does a lot of the meanial work, but is also allowed to do some of the higher level work, under strict supervision. I think, in a sense, we agree more than disagree. There are established models for engineering disciplins and IT would probably do better in many ways if it were to fall in line. Licensed folks working in architecture and design. Codes to standardize and provide quality control and safety. Apprenticed skilled trades to implement. What we're arguing over here is some minor semantics of how that structure works in IT. HOWEVER, I am not sure it completely works. Here's why; some colleges have C.S. in the Arts and Sciences college, and treat how to program more like how to write a novel than how to build a bridge. Others have it in the Engineering college, and treat it more like building a bridge than writing an novel. What seems to work is a blend in the real world, treating most IT tasks like classical engineering doesn't work out well, nor does treating it like writing a book. IT isn't governed by the same hard (physical) rules as traditional engineering, but you also can't be freely creative and expect to come up with something that works. I personally would like to see the industry work on the "code" problem, which would be necessary pre-work for licensing. I'd also like to see trade style mentoring. I think those can proceed in parallel. I'm just personally prepared for the eventuality that IT might never fit into as ridgid a framework as EE or ME. -- Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/
-----Original Message----- From: Jeff Wheeler Sent: Thursday, February 16, 2012 11:30 PM To: NANOG Subject: common time-management mistake: rack & stack
Randy's P-Touch thread brings up an issue I think is worth some discussion. I have noticed that a lot of very well-paid, sometimes well-qualified, networking folks spend some of their time on "rack & stack" tasks, which I feel is a very unwise use of time and talent.
Imagine if the CFO of a bank spent a big chunk of his time filling up ATMs. Flying a sharp router jockey around to far-flung POPs to install gear is just as foolish.
Not only does the router jockey cost a lot more to employ than a CCNA, but if your senior-level talent is wasting time in airports and IBXes, that is time they can't be doing things CCNAs can't.
I see this as a double-edged sword. You don't want your "C" staff out in the field actually installing gear as a general course of operations as that is a great waste of their time/talent unless the "C" role is more "honorary" than anything else. That said, you might want a senior technical person on site overseeing the installation, checking the configuration, interfacing with vendor staff, testing things, etc. And it is good to have this senior staff member present when things go sideways as is often the case with new installations and often these issues are physical and are best solved with someone senior on site who can make decisions on the spot or carry more weight with the provider to get things done quickly. This should be someone that was involved in discussions with the vendor's rep. during the planning phase. If you get too reliant on sending only the cage monkeys (a term I use with fondness) then what happens when problems turn up greatly depend on your corporate culture. Do they simply stop, report the problem and wait for direction? Is there anyone on site that has the trust of the organization to make decisions on the fly and cut through the organizational red tape? Can they authorize a configuration change to work around something unforeseen? Having someone senior enough on site to make these decisions and carries some weight with the vendor can greatly reduce the time it takes to get a data center up and running. Granted, he doesn't need to be there when the initial cables are being laid out but should be there once equipment starts being installed in racks and configured. Having that experience and authority on site at the time of installation can be quite valuable.
Jeff Wheeler <jsw@inconcepts.biz> writes:
With apologies to Randy, let the CCNAs fight with label makers.
Yeah. And you need do be at last CCNP to switch a module in a router. Had this request last year. I first thought that some troubleshooting / configuration was involved but it was just replacing a module. Jens -- ------------------------------------------------------------------------- | Foelderichstr. 40 | 13595 Berlin, Germany | +49-151-18721264 | | http://blog.quux.de | jabber: jenslink@guug.de | ------------------- | -------------------------------------------------------------------------
On Thu, Feb 16, 2012 at 23:29, Jeff Wheeler <jsw@inconcepts.biz> wrote: ...
Imagine if the CFO of a bank spent a big chunk of his time filling up ATMs. Flying a sharp router jockey around to far-flung POPs to install gear is just as foolish.
There is a theory of management that says a good manager needs to know nothing about the staff or the jobs he is managing, because his job is about returning profit to the shareholder, and not about what the company does. AFAIK, these theories are made in the academic halls of the business schools, which churn out MBAs, and, self-selected group that they are, believe in (more) managers, and (more) powerpoint business plans, and (more) theory. I happen to come from a different background, and believe that it has value to understand what the people who are working for you actually do. That does not mean the CEO should spend all day delivering the mail (or flipping burgers), but she had better have done it a few times, and it is a good idea to do it from time to time to see what has changed. It keeps the manager grounded with the reality. (I have been told that the reason that the commanders in the Army are reluctant to send their people to battle is that they have experienced it, and know it is hell. And the reason the people will go to hell for their commander is that the commander has the moral authority of having done it, experienced it, know that they are asking a lot, but it is for the common good. People will follow a leader who has been there, done that, and not so much when it is just an academic business plan on a powerpoint slide.)
From: Gary Buhrmaster [mailto:gary.buhrmaster@gmail.com] Sent: Friday, February 17, 2012 12:54 PM To: Jeff Wheeler Cc: NANOG Subject: Re: common time-management mistake: rack & stack On Thu, Feb 16, 2012 at 23:29, Jeff Wheeler <jsw@inconcepts.biz> wrote: ...
Imagine if the CFO of a bank spent a big chunk of his time filling up ATMs. Flying a sharp router jockey around to far-flung POPs to install gear is just as foolish.
There is a theory of management that says a good manager needs to know nothing about the staff or the jobs he is managing, because his job is about returning profit to the shareholder, and not about what the company does. AFAIK, these theories are made in
the academic halls of the business schools,
which churn out MBAs, and, self-selected group that they are, believe in (more) managers, and (more) powerpoint business plans, and (more) theory.
I happen to come from a different background, and believe that it has value to understand what the people who are working for you actually do. That does not mean the CEO should spend all day delivering the mail (or flipping burgers), but she had better have done it a few times, and it is a good idea to do it from time to time to see what has changed. It keeps the manager grounded with the reality. (I have been told that the reason that the commanders in the Army are reluctant to send their people to battle is that they have experienced it, and know it is hell. And the reason the people will go to hell for their commander is that the commander has the moral authority of having done it, experienced it, know that they are asking a lot, but it is for the common good. People will follow a leader who has been there, done that, and not so much when it is just an academic business plan on a powerpoint slide.)
+1 for Gary's comment. That is the large difference between LEADING and MANAGING. In the context of the military scenario above, Grace Hopper comes to mind because of her nanoseconds etc "In her retirement speech, instead of dwelling on the past, she talked about moving toward the future, stressing the importance of leadership." http://inventors.about.com/od/hstartinventors/a/Grace_Hopper_2.htm I was lucky enough to have heard her speak once at an ACM event. Tony Patti CIO S. Walter Packaging Corp.
On Fri, Feb 17, 2012 at 01:15:09PM -0500, Tony Patti wrote:
In the context of the military scenario above, Grace Hopper comes to mind because of her nanoseconds etc "In her retirement speech, instead of dwelling on the past, she talked about moving toward the future, stressing the importance of leadership." http://inventors.about.com/od/hstartinventors/a/Grace_Hopper_2.htm I was lucky enough to have heard her speak once at an ACM event.
I still have my nanosecond. Did she hand them out to the crowd there? -- Mike Andrews, W5EGO mikea@mikea.ath.cx Tired old sysadmin
From: Mike Andrews [mailto:mikea@mikea.ath.cx] Sent: Friday, February 17, 2012 1:44 PM To: 'NANOG' Subject: Re: common time-management mistake: rack & stack
On Fri, Feb 17, 2012 at 01:15:09PM -0500, Tony Patti wrote:
In the context of the military scenario above, Grace Hopper comes to mind because of her nanoseconds etc "In her retirement speech, instead of dwelling on the past, she talked about moving toward the future, stressing the importance of leadership." http://inventors.about.com/od/hstartinventors/a/Grace_Hopper_2.htm I was lucky enough to have heard her speak once at an ACM event.
I still have my nanosecond. Did she hand them out to the crowd there?
Yes, of course! I remember that she said they were borrowed from a phone closet in the Pentagon... Of course, she is also famous for "It's easier to ask for forgiveness than it is to get permission" Notable Quotation from her Wikipedia page at http://en.wikipedia.org/wiki/Grace_Hopper Tony Patti CIO S. Walter Packaging Corp.
On Feb 16, 2012, at 11:29 PM, Jeff Wheeler wrote:
Randy's P-Touch thread brings up an issue I think is worth some discussion. I have noticed that a lot of very well-paid, sometimes well-qualified, networking folks spend some of their time on "rack & stack" tasks, which I feel is a very unwise use of time and talent.
Imagine if the CFO of a bank spent a big chunk of his time filling up ATMs. Flying a sharp router jockey around to far-flung POPs to install gear is just as foolish.
Not only does the router jockey cost a lot more to employ than a CCNA, but if your senior-level talent is wasting time in airports and IBXes, that is time they can't be doing things CCNAs can't.
I was once advising a client on a transit purchasing decision, and a fairly-large, now-defunct tier-2 ISP was being considered. We needed a few questions about their IPv6 plans answered before we were comfortable. The CTO of that org was the only guy who was able to answer these questions. After waiting four days for him to return our message, he reached out to us from an airplane phone, telling us that he had been busy racking new routers in several east-coast cities (his office was not east-coast) and that's why he hadn't got back to us yet.
As you might imagine, the client quickly realized that they didn't want to deal with a vendor whose CTO spent his time doing rack & stack instead of engineering his network or engaging with customers. If he had simply said he was on vacation, we would never have known how poorly the senior people at that ISP managed their time.
With apologies to Randy, let the CCNAs fight with label makers. -- Jeff S Wheeler <jsw@inconcepts.biz> Sr Network Operator / Innovative Network Concepts
With all due respect, Jeff, I think you are missing several factors that come into the human equation beyond merely the most efficient use of a particular person's time. I would go stark-raving bonkers trapped in a cubicle doing only things that CCNAs can't if I didn't get the occasional break to go out and play with real hardware in the field. Most of the well-paid well-qualified networking folks I know are the same way. I also think that when we spend too many consecutive weeks/months/years behind a desk without going out in the real world, we become progressively more detached from the operational reality where our designs have to operate. On the surface, it might seem an inefficient use of financial/human resources, but, I think that there is value to time in the field that doesn't necessarily show up directly on the balance sheet. Admittedly, in my current position, I'm no longer in an operational role for the most part, but, I'm even more out in the field and spending more time in airports. Owen
On Feb 17, 2012, at 18:55, Owen DeLong wrote:
I also think that when we spend too many consecutive weeks/months/years behind a desk without going out in the real world, we become progressively more detached from the operational reality where our designs have to operate.
In software, this problem is a rather well known "Antipattern": http://c2.com/cgi/wiki?ArchitectsDontCode (This is an "Antipattern", i.e. it actually means "Architects *MUST* write code". But the problems from doing this getting in the way are also discussed there, so Jeff gets some support, too.) Grüße, Carsten PS.: Donald E. Knuth said: "The designer of a new kind of system must participate fully in the implementation." So, the more cookie-cutter your systems become, the less important is the requirement to do this over and over. But having it done once, and recently enough, still is a qualification factor for an architect. PPS.: I'm less sure about the battlefield analogies :-)
participants (20)
-
Alain Hebert -
Carsten Bormann -
Chad Dailey -
Dan Golding -
Gary Buhrmaster -
George Bonser -
Holmes,David A -
isabel dias -
Jay Ashworth -
Jeff Wheeler -
Jens Link -
Joel jaeggli -
Justin M. Streiner -
Lamar Owen -
Leo Bicknell -
Mike Andrews -
Nathan Eisenberg -
Owen DeLong -
Sven Olaf Kamphuis -
Tony Patti