In a previous blog post we considered how to effectively set our goals to reach our “destination address.” However, no matter how well we plan, it seems that occasionally, life gets in the way. That’s the focus of this blog post, how to keep moving forward against the current of life.
Your goals are set, and you’re cruising down that metaphorical road to success when all of a sudden you notice a detour sign, because the road ahead is closed. That’s what seems to happen all too often in our careers. Things are going well, and then some life event happens forcing us to take a detour from our intended path.
Staying with our metaphor of driving down the road of success, let’s imagine that your car has a navigation system. When you veer off your planned route, the navigation system dutifully recomputes your route and tells you how you can still get to your destination, even from the back road you now find yourself on. (As a hopefully interesting side note, navigation systems in cars use the Dijkstra algorithm to find an optimal path between two points. That is the same algorithm used by the Open Shortest Path First (OSPF) routing protocol). So it is with our careers. Even if we get thrown off course, there’s still a way to get from where we are to our ultimate goal.
Some of life’s detours that throw us off course are simply distractions. Maybe we start prioritizing something else over our current career goal. (This sometimes happens to me when a new Star Wars® book is released.) Perhaps we should refuse to take some of these detours and simply plow ahead in pursuit of our goal.
Other detours, however, need to be taken. As a few examples, consider the following:
Is there a way for us to still make progress (albeit slower) to our goal when we find ourselves in the midst of such circumstances? I posit there is. Let’s examine each of the previous examples and see if there is a way to minimize the impact of such events on our career goals.
While a future blog posting, which will be called Time Alchemy, will deal specifically with time management, our current discussion reminds me of one of my favorite time management books. It’s First Things First, by the late Stephen Covey. In that book, Dr. Covey talked about how our activities fall into one of four quadrants: (1) Urgent and Important, (2) Non-urgent and Important, (3) Urgent and Non-important, and (4) Non-urgent and Non-important. The goal is to spend more of our time in the second quadrant (i.e. doing non-urgent yet important activities). By spending more time in the second quadrant, we’ll spend less time in the first quadrant (i.e. doing urgent and important activities). To make this concept of quadrants more relative to us as Cisco networking professionals, let’s consider a couple of activities and classify those activities into quadrants.
The first activity is responding to a report that a WAN router is dropping a high percentage of packets due to the relatively limited WAN bandwidth being oversubscribed. To resolve the issue, you might have had to contact your service provider and had them provision additional bandwidth. Alternately, you might have configured your routing protocol to load balance across two WAN links.
Into which quadrant would you categorize this activity (i.e. the activity of responding to a WAN router dropping a high percentage of packets)? Consider that users were currently experiencing poor network performance, and that needed to be addressed immediately. Let’s also assume that communication across the WAN link was important to the business (as evidenced by the high traffic volume on the WAN link). I suggest that such an activity would fall squarely in the middle of the first quadrant (i.e. an urgent and important activity).
The second activity is configuring network monitoring software to send e-mail alerts when thresholds for various parameters are exceeded. For example, the software might fire off an e-mail to a network engineer if the temperature of a router exceeds 85 degrees Fahrenheit. Another threshold might be triggered with the average bandwidth utilization on a WAN link exceeds 70 percent.
How would you categorize this activity? Unlike responding to an issue that is currently impacting network performance, this activity is not urgent. However, it is important, because this activity could alert appropriate personnel of impending network issues before they actually occur, hopefully allowing network engineers to resolve the situation before any sort of outage happened. Would you agree with me that this would therefore be an activity found in the second quadrant (i.e. non-urgent but important)?
Considering these two activities together, notice, had more time been spent in the second quadrant, less time would have needed to be spent in the first quadrant. Specifically, if a network engineer had taken the time to setup monitoring software to generate an alert when WAN bandwidth utilization exceeded a certain threshold, they could have provisioned additional bandwidth before the link became saturated. As a result, they could have avoided the activity (in the first quadrant) of responding to the issue of packet drops.
What’s the lesson to take from this? Spend more time setting up systems and processes (e.g. configuring network backups and installing monitoring software), to reduce the number of urgencies to which you need to respond.
I’ve already shared with you the genesis of my philosophy of doing the most important thing at every moment. Now, allow me to share with you some specific examples.
The biggest impact illness has had on my career was back in the year 2000. I was a network designer for Walt Disney World in Florida. My mother, who lived in Kentucky, became very ill. She was diagnosed with Myasthenia Gravis, a neuromuscular disorder. My wife, daughters, and I made multiple trips back and forth between Florida and Kentucky to be with her while she was in the hospital. However, being a fairly new employee with Disney, I had very little sick time/vacation time available to me, and I quickly burned through the limited amount I had. It got to the point where I had to start taking days off without pay.
Eventually, I made the huge career decision to leave Disney, the largest single-site employer in North America, whose network contained over 500 Cisco routers and thousands of Cisco Catalyst switches. Being an only child, my responsibility was to care for my mother. By the way, as I write this over fifteen years later, she is doing well and living independently.
This event, however, was a major career reboot for me. While working at Disney, I was preparing for my CCIE R/S lab (having already passed the written exam). My lab date was scheduled, and Disney had already paid my airfare to the lab in RTP North Carolina.
After making the decision to return to Kentucky, I had to get a job, any job. A DSL service provider had just opened an office in Lexington, KY (about a 40-minute commute from where I was going to be living, not bad). Fortunately, I was able to get a job there as a regional manager for the systems engineers in the area. While learning the ropes at this new job, I kept up my CCIE studies, and looked for a job that better suited my interest in Cisco technologies.
Based on my experience with Cisco Catalyst 6500 Series switches at Disney, I was offered a position as an instructor with a Cisco Learning Partner (CLP). This allowed me to focus all of my working hours on learning more and more about Cisco technologies, which played a pivotal role in getting me better prepared for the CCIE R/S lab (which I eventually passed, on my third attempt, in August of 2001).
The two main lessons I hope to impart from this personal story are:
I hope you’ve enjoyed this second post in the Your Route to Cisco Career Success series, and I encourage you to look for opportunities to squeeze out a little study/reading/viewing time in situations you might normally see as distractions.
Kevin Wallace, CCIEx2 (R/S and Collaboration) #7945, CCSI 20061
If you enjoyed this article, you might also want to subscribe to my podcast: