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
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 - bickn...@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ pgpRx0IPosuTU.pgp Description: PGP signature
RE: common time-management mistake: rack stack
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:lo...@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
Re: common time-management mistake: rack stack
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 stillsome 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 bickn...@ufp.org To: Dan Golding dgold...@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
RE: common time-management mistake: rack stack
-Original Message- From: Leo Bicknell [mailto:bickn...@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
Re: common time-management mistake: rack stack
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 :-)
Re: common time-management mistake: rack stack
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. 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. Imagine if the CFO of a bank spent a big chunk of his time filling up ATMs. That'd be a good idea, it's too easy to become remote from reality. obviously you need the right balance - s/big// brandon
RE: common time-management mistake: rack stack
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
Re: common time-management mistake: rack stack
+1 I picked up ram from a supplier today. Could have used a courier, but getting out of the office is vital. A CTO who's lost touch because they haven't been to a remote site in half a decade is a business risk, more so than the CTO being away from their desk. If there is business risk from having the CTO out of touch for a week or even a month then there's a bigger problem. D On 17/02/2012 9:17 p.m., Brandon Butterworth wrote: 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. 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. Imagine if the CFO of a bank spent a big chunk of his time filling up ATMs. That'd be a good idea, it's too easy to become remote from reality. obviously you need the right balance - s/big// brandon -- Don Gould 31 Acheson Ave Mairehau Christchurch, New Zealand Ph: + 64 3 348 7235 Mobile: + 64 21 114 0699
Re: common time-management mistake: rack stack
On Feb 17, 2012, at 3:17 AM, Brandon Butterworth wrote: 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. 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. +1 I find this myself, it's useful to do this, as it is to sit in with the operations team and other groups (even finance) to understand what other groups need/require. I've often found that someone is working around a problem they didn't know you could solve (easily), or is doing a large amount of manual labor when there is an API, etc. Perspective is good. I also do other work that certainly isn't a complete use of my talents that benefits others (e.g.: chaperone a field-trip at school). These are not without merits, but I do know I have my faults in perhaps reading (and responding) to NANOG too much when I should be engaged in more worthwhile tasks. Imagine if the CFO of a bank spent a big chunk of his time filling up ATMs. That'd be a good idea, it's too easy to become remote from reality. obviously you need the right balance - s/big// - Jared
RE: common time-management mistake: rack stack
I think it was Miagi in Karate Kid that stressed balance. The CTO who is NEVER out of his cage is dangerous, likewise the one that is never available is also. It is keeping in touch with what is happening at all levels that makes him valuable. If there is one thing that American Management misses, it is that. The GROWING companies almost always have management that is active, visible and accessible - top to bottom. The ones that are dying are not. The same goes for union leaders who are really pseudo-management. The senior technicians are no different than management, they need broad focus but they must also be able to take the magnifying glass and look at the current situation. A network engineer who cannot do both is not living up to his job description. Ralph Brandt Communications Engineer HP Enterprise Services Telephone +1 717.506.0802 FAX +1 717.506.4358 Email ralph.bra...@pateam.com 5095 Ritter Rd Mechanicsburg PA 17055 -Original Message- From: Jared Mauch [mailto:ja...@puck.nether.net] Sent: Friday, February 17, 2012 8:36 AM To: Brandon Butterworth Cc: nanog@nanog.org Subject: Re: common time-management mistake: rack stack On Feb 17, 2012, at 3:17 AM, Brandon Butterworth wrote: 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. 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. +1 I find this myself, it's useful to do this, as it is to sit in with the operations team and other groups (even finance) to understand what other groups need/require. I've often found that someone is working around a problem they didn't know you could solve (easily), or is doing a large amount of manual labor when there is an API, etc. Perspective is good. I also do other work that certainly isn't a complete use of my talents that benefits others (e.g.: chaperone a field-trip at school). These are not without merits, but I do know I have my faults in perhaps reading (and responding) to NANOG too much when I should be engaged in more worthwhile tasks. Imagine if the CFO of a bank spent a big chunk of his time filling up ATMs. That'd be a good idea, it's too easy to become remote from reality. obviously you need the right balance - s/big// - Jared
Re: common time-management mistake: rack stack
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
Re: common time-management mistake: rack stack
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 Hebertaheb...@pubnix.net PubNIX Inc. 50 boul. St-Charles P.O. Box 26770 Beaconsfield, Quebec H9W 6G7 Tel: 514-990-5911 http://www.pubnix.netFax: 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.
Re: common time-management mistake: rack stack
On Fri, 17 Feb 2012, Brandon Butterworth 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. Definite +1 here. I got my start in this profession 15-ish years ago at a mid-sized regional ISP. The company was small enough, in terms of its work force, that that I interviewed with the CEO for what was largely an IT position. As a result, many people in the organization wore lots of different hats. It wasn't to the point of having accountants pull cable or IT guys doing the books, but I did spend a lot of time doing rack-and-stack work. I didn't (and still don't) mind rack-and-stack, pulling cable, etc. As others have said, it's a good, therapeutic diversion from staring at a screen and attending meetings ;) Another good reason for getting out into the field. When you're the person who defines technical deployment standards for an organization, it gives you an opportunity to verify that work is being done to those standards. That'd be a good idea, it's too easy to become remote from reality. obviously you need the right balance - s/big// I'm sure if the ISP I got my start with 15-ish years ago was much bigger, I would not have interviewed with the CEO, but at that time, it was the right fit for that organization. jms
Re: common time-management mistake: rack stack
Hrm. On Fri, Feb 17, 2012 at 3:17 AM, Brandon Butterworth bran...@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. One of the reasons I love my job so much is that I don't need to be stuck at a keyboard all the time. I usually volunteer to help rack and stack new hardware that I haven't had a chance to touch yet. For humans, touch can connect you to an object in a very personal way, make it seem more real. : ) -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/
Re: common time-management mistake: rack stack
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 BERLINPhone: +31/(0)87-8747479 Germany GSM: +49/(0)152-26410799 RIPE:CBSK1-RIPEe-Mail: s...@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 Hebertaheb...@pubnix.net PubNIX Inc. 50 boul. St-Charles P.O. Box 26770 Beaconsfield, Quebec H9W 6G7 Tel: 514-990-5911 http://www.pubnix.netFax: 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.
Re: common time-management mistake: rack stack
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
Re: common time-management mistake: rack stack
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 - bickn...@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ pgpAFTnus5s74.pgp Description: PGP signature
RE: common time-management mistake: rack stack
-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.
Re: common time-management mistake: rack stack
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/
RE: common time-management mistake: rack stack
-Original Message- From: Leo Bicknell [mailto:bickn...@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
Re: common time-management mistake: rack stack
would have been good to know to whom you were replying, not in To: or in pre-quote text. 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. 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. Imagine if the CFO of a bank spent a big chunk of his time filling up ATMs. That'd be a good idea, it's too easy to become remote from reality. obviously you need the right balance - s/big// i configure routers, admin servers, and occasionally rack and stack in my own research racks [0]. aside from giving me a base in reality instead of all research papers and power point (a major benefit), it's like housework or doing the dishes, shut up and do your part. it's also damned useful to maintain layer zero skills. once upon a time, when i was playing at vp eng, a london routing hub was supposed to be turned up. the equipment sat in co-lo receiving for weeks, and no respose from the london techs (i am sure they had ccnas, whetever the hell that is). so i grabbed my toolkit and got on a plane and walked into redbus and started turning it all up. the local techs appeared pretty damed quickly and started doing their jobs. of course, a few weeks later they were told to get jobs elsewhere. maintain your skills, you may need them again some day. randy --- [0] - deep thanks to (in alpha order) cisco, equinix, google, juniper, nsf, and others for contributions.
Re: common time-management mistake: rack stack
On Fri, Feb 17, 2012 at 11:15 AM, George Bonser gbon...@seven.com wrote: -Original Message- From: Leo Bicknell [mailto:bickn...@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
Re: common time-management mistake: rack stack
Jeff Wheeler j...@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: jensl...@guug.de | --- | -
Re: common time-management mistake: rack stack
On Thu, Feb 16, 2012 at 23:29, Jeff Wheeler j...@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.)
Re: common time-management mistake: rack stack
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 j...@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
RE: common time-management mistake: rack stack
From: Gary Buhrmaster [mailto:gary.buhrmas...@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 j...@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.
Re: common time-management mistake: rack stack
- Original Message - From: Leo Bicknell bickn...@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 j...@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
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? -- Mike Andrews, W5EGO mi...@mikea.ath.cx Tired old sysadmin
RE: common time-management mistake: rack stack
From: Mike Andrews [mailto:mi...@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.
Re: common time-management mistake: rack stack
--- gary.buhrmas...@gmail.com wrote: There is a theory of management that says a good manager needs to know nothing about the staff or the jobs he is managing, - neck hair == raised :-) From empirical data, this is not a good thing for companies. They constantly make bad choices because they not only don't understand the concepts, but can't even grasp the consequences of their decision. For example, I had four GigEs each to several upstreams. I pointed the BGP session to the loopback at the provider's router, so the traffic would load share across the four GigEs. I was told my one of those managers who needs to know nothing about the staff or the jobs he is managing that was not redundant and that I had to do one BGP session per GigE, so four BGP sessions to each upstream. After some heated discussions with the manager about why that was not a good design decision, I warmed up my resume and started looking for a new job. scott
