The Future of Hidden Features

 

948AD2EC-79D1-4828-AF55-C71EA8715771You may have noticed last week that Ubiquiti added a new “feature” to their devices in a firmware updated. According to this YouTube video from @TomLawrenceTech, Ubiquiti built an new service that contacts a URL to “phone home” and check in with their servers. It got some heavy discussion going, especially on Reddit.

The consensus is that Ubiquiti screwed up here by not informing people they were adding the feature up front and also not allowing users to opt-out initially. The support people at Ubiquiti even posted a quick workaround of blocking the URL at a perimeter firewall to prevent the communications until they could patch in the option to opt-out. If this was an isolated incident I could see some manner of outcry about it, but the fact of the matter is that companies are adding these hidden features more and more every day.

The first issue comes from the fact that most release notes for apps any more are nothing aside from platitudes. “Hey, we fixed some bugs and stuff so turn on automatic updates so you get the best version of our stuff!” is somewhat common now when it comes to a list of changes. That has a lot to do with applications developers doing unannounced A/B testing with people. It’s not uncommon to have two identical version numbers of an app running two wildly different code releases or having dissimilar UIs just because some bean counter wants to know how well Feature X polls with a certain demographic.

Slipstreaming Stuff

While that’s all well and good for consumer applications, the trend is starting to seep into enterprise software as well. While we still get an exhaustive list of things that have been fixed in a release, we’re getting more than we bargained for on occasion as well. Doing a scrub of code to ensure that it actually fixes the bugs that you have in your environment is important for reliability purposes. When the quality of the code you’re trying to publish is of less-than-stellar quality, you have have to spend more time ensuring that the stated fixes aren’t going to cause issues during implementation.

But what about when the stated features aren’t the only things included? Could you imagine the nightmare of installing a piece of software to fix an issue only to find out that something that was hidden in the code, like a completely undocumented feature, caused some other issue elsewhere? And when I say “undocumented feature” I’m not using it as a euphemism for another bug. I’m talking about a service that got installed that no one knows about. Like a piece of an app that will be enabled at a later time for instance.

Remember Microsoft back in the early 90s? They were invincible. They had everything they wanted in the palm of their hand. And then their world exploded. They got sued by the US government in an anti-trust case. One of the things that came out of this lawsuit was a focus on undocumented features in Microsoft software. The government said that Microsoft was adding features to their application software that gave them performance advantages over other vendors. And only they knew about them.

Microsoft agreed to get rid of all undocumented features, including some of the Easter eggs that were hidden in their software. That irritated some people that enjoyed finding these fun little gifts. But in 2005, there was a great blog post that discussed why Microsoft has a strict “no Easter eggs” policy now. And reading it almost 15 years later makes it sound so prescient.

Security Sounds Simple, Right?

Undocumented features are a security risk. If there is code in your app that isn’t executing or hasn’t been completely checked against the interactions in your environment you’re adding a huge amount of risk. There can be interactions that someone doesn’t understand or that you have no way of seeing. And you can better believe that if the regulators of your industry find them before you do you’re going to have a lot of explaining to do.

That’s even if you notice it in the first place. How many times have you been told to whitelist a specific URL or IP stack to make something work? I can remember being told to whitelist 17.0.0.0/8 for Apple to make their push notification service work. That’s an awful lot of IP addresses to enable push notifications! And that’s a lot of data that could be corrupted or misused by a smart threat actor.

The solution we need to fix the problem is actually pretty simple. We need to push back against the idea that we can slip undocumented features into updates. Release notes need to list everyting that comes in the software package. We need to tell our vendors and companies that we have to have a full listing of the software features. And regulatory bodies need to be ready to share the blame when someone breaks those rules instead of punishing the people that had no idea there was something in the code that was misbehaving.


Tom’s Take

I’m not a fan of finding things I wasn’t expecting. At one point my wife and I had the latest Facebook app updates and somehow her UI looked radically different than mine. But if it’s on my phone or my home computer I don’t really have much to complain about. Finding undocumented apps and features in my enterprise software is a huge issue though. Security is paramount and undocumented code is an entry point to disaster. We are the only ones that can stem the tide by pushing back against this practice now before it becomes commonplace in the future.

In Defense of Support

We’re all in IT. We’ve done our time in the trenches. We’ve…seen things, as Roy Batty might say. Things you wouldn’t believe. But in the end we all know the pain of trying to get support for something that we’re working on. And we know how painful that whole process can be. Yet, how is it that support is universally “bad” in our eyes?

One Of Us

Before we launch into this discussion, I’ll give you a bit of background on me. I did inbound tech support for Gateway Computers for about six months at the start of my career. So I wasn’t supporting enterprises to start with but I’ve been about as far down in the trenches as you can go. And that taught me a lot about the landscape of support.

The first thing you have to realize is that most Tier 1 support people are, in fact, not IT nerds. They don’t have a degree in troubleshooting OSPF or are signatories to the fibre channel standards. They are generally regular people. They get a week or two of training and off they go. In general the people on the other end of the support phone number are better phone people than they are technical people. The trainers at my old job told me, “We can teach someone to be technical. But it’s hard to find someone who is pleasant on the phone.”

I don’t necessarily agree with that statement but it seems to be the way that most companies staff their support lines. Why? Ask yourself a quick question: How many times has Tier 1 support solved your issue? For most of us the answer is probably “never” or “extremely rarely”. That’s because we, as IT professionals, have spent a large amount of our time and energy doing the job of a Tier 1 troubleshooter already. We pull device logs and look at errors and Google every message we can find until we hit a roadblock. Then it’s time to call. However, you’re already well past what Tier 1 can offer.

Look at it from the perspective of the company offering the support. If the majority of people calling me are already past the point of where my Tier 1 people can help them, why should I invest in those people? If all they’re going to do is take information down and relay the call to Tier 2 support how much knowledge do they really need? Why hire a rock star for a level of support that will never solve a problem?

In fact, this is basically the job of Tier 1 support. If it’s not a known issue, like an outage or a massive bug that is plastered up everywhere, they’re going to collect the basic information and get ready to pass the call to the next tier of support. Yes, it sucks to have to confirm serial numbers and warranty status with someone that knows less about VLANs than you do. But if you were in the shoes of the Tier 2 technician would you want to waste 10 minutes of the call verifying all that info yourself? Or would you rather put your talent to use to get the problem solved?

Think about all the channel partners and certification benefits that let you bypass Tier 1 support. They’re all focused on the idea that you know enough about the product to get to the next level to help you troubleshoot. But they’re also implying that you know the customer’s device is in warranty and that you need to pull log files and other data before you open a ticket so there’s no wasted time. But you still need to take the time to get the information to the right people, right? Would you want to start troubleshooting a problem with no log files and only a very basic description of the issue? And consider that half the people out there just put “Doesn’t Work” or “Acting Weird” for the problem instead of something more specific.

Sight Beyond Sight

This whole mess of gathering info ahead of time is one of the reasons why I’m excited about the coming of network telemetry and network automation. That’s because you now have access to all the data you need to send along to support and you don’t need to remember to collect it. If you’ve ever logged into a switch and run the show tech-support command you probably recall with horror the console spam that was spit out for minutes upon minutes. Worse yet, you probably remember that you forgot to redirect that spam to a file on the system to capture it all to send along with your ticket request.

Commands like show tech-support are the kinds of things that network telemetry is going to solve. They’re all-in-one monsters that provide way too much data to Tier 2 support techs. If the data they need is in there somewhere it’s better to capture it all and spend hours poring through a text file than talk to the customer about the specific issue, right?

Now, imagine the alternative. A system that notices a ticket has been created and pulls the appropriate log files and telemetry. The system adds the important data to the ticket and gets it ready to send to the vendor. Now, instead of needing to provide all the data to the Tier 1 folks you can instead open a ticket at the right level to get someone working on the problem. Mean Time to Resolution goes down and everyone is happy. Yes, that does mean that there are going to be fewer Tier 1 techs taking calls from people that don’t have a way to collect the data ahead of time but that’s the issue with automating a task away from someone. If the truth be told they would be able to find a different job doing the same thing in a different industry. Or they would see the value of learning how to troubleshoot and move up the ladder to Tier 2.

However, having telemetry gathered automatically still isn’t enough for some. The future is removing the people from the chain completely. If the system can gather telemetry and open tickets with the vendor what’s stopping it from doing the same proactively? We already have systems designed to do things like mail hard disk drives to customers when the storage array is degraded and a drive needs to be replaced. Why can’t we extend things like that to other parts of IT? What if Tier 2 support called you for a change and said, “Hey, we noticed your routing protocol has a big convergence issue in the Wyoming office. We think we have a fix so let’s remote in and fix it together.” Imagine that!


Tom’s Take

The future isn’t about making jobs go away. It’s about making everything more efficient. I don’t want to see Tier 1 support people lose their jobs but I also know that most people consider their jobs pointless already. No one wants to deal with the info takers and call routers. So we need to find a way to get the right information to the people that need it with a minimum of effort. That’s how you make support work for the IT people again. And when that day comes and technology has caught up to the way that we use support, perhaps we won’t need to defend them anymore.

The End of SD-WAN’s Party In China

As I was listening to Network Break Episode 257 from my friends at Packet Pushers, I heard Greg and Drew talking about a new development in China that could be the end of SD-WAN’s big influence there.

China has a new policy in place, according to Axios, that enforces a stricter cybersecurity stance for companies. Companies doing business in China or with offices in China must now allow Chinese officials to get into their networks to check for security issues as well as verifying the supply chain for network security.

In essence, this is saying that Chinese officials can have access to your networks at any time to check for security threats. But the subtext is a little less clear. Do they get to control the CPE as well? What about security constructs like VPNs? This article seems to indicate that as of January 1, 2020, there will be no intra-company VPNs authorized by any companies in China, whether Chinese or foreign businesses in China.

Tunnel Collapse

I talked with a company doing some SD-WAN rollouts globally in China all the way back in 2018. One of the things that was brought up in that interview was that China was an unknown for American companies because of the likelihood of changing that model in the future. MPLS is the current go-to connectivity for branch offices. However, because you can put an SD-WAN head-end unit there and build an encrypted tunnel back to your overseas HQ it wasn’t a huge deal.

SD-WAN is a wonderful way to ensure your branches are secure by default. Since CPE devices “phone home” and automatically build encrypted tunnels back to a central location, such as an HQ, you can be sure that as soon as the device powers on and establishes global connectivity that all traffic will be secure over your VPN until you change that policy.

Now, what happens with China’s new policy? All traffic must transit outside of a VPN. Things like web traffic aren’t as bad but what about email? Or traffic destined for places like AWS or Azure? It was an unmentioned fact that using SD-WAN VPNs to transit through the content filters in place in China was a way around issues that might arise from accessing resources inside of a very well secured country-wide network.

With the policy change and enforcement guidelines set forth to be enacted in 2020, this could be a very big deal for companies hoping to use SD-WAN in China. First and foremost, you can’t use your intra-company VPN functions any longer. That effectively means that your branch office can’t connect to the HQ or the rest of your corporate network. Given some of the questions around intellectual property issues in China that might not be a bad thing. However, it is going to cause issues for your users trying to access the mail and other support services. Especially if they are hosted somewhere that is going to create additional scrutiny.

The other potential issue is whether or not Chinese officials are even going to allow you to use CPE of your own choosing in the future. If the mandate is that officials should have access to your network for security concerns, who is to say they can’t just dictate what CPE you should use in order to facilitate that access. Larger companies can probably negotiate for come kind of on-site server that does network scanning. But smaller branches are likely going to need to have an all-in-one device at the head end doing all the work. The additional benefit for the Chinese is that control of the head end CPE ensures that you can’t build a site-to-site VPN anywhere.

Peering Into The Future

Greg and Drew pontificate a bit on the future on what this means for organizations from foreign countries doing business in China in the future. I tend to agree with them on a few points. I think you’re going to see a push for Chinese offices of major companies treating them like zero-trust endpoints. All communications will be trading minimal information. Networks won’t be directly connected, either by VPN substitute or otherwise.

Looking further down the road makes the plans even more murky. Is there a way that you can certify yourself to have a standard for cybersecurity? We have something similar with regulations here in the US were we can submit compliance reports for various agencies and submit to audits or have audits performed by third parties. But if the government won’t take that as an answer how do you even go about providing the level of detail they want? If the answer is “you can’t”, then the larger discussion becomes whether or not you can comply with their regulations and reduce your business exposure while still making money in this market. And that’s a conversation no technology can solve.


Tom’s Take

SD-WAN gives us a wonderful set of features included in the package. Things like application inspection are wonderful to look at on a dashboard but I’ve always been a bigger fan of the automatic VPN service. I like knowing that as soon as I turn up my devices they become secure endpoints for all my traffic. Alas, all the technology in the world can be defeated by business or government regulation. If the rules say you can’t have a feature, you either have to play by the rules or quit playing the game. It’s up to businesses to decide how they’ll react going forward. But SD-WAN’s greatest feature may now have to be an unchecked box on that dashboard.

Locked Up By Lock-In

When you start evaluating a solution, you are going to get a laundry list of features and functionality that you are supposed to use as criteria for selection. Some are important, like the ones that give you the feature set you need to get your job done. Others are less important for the majority of use cases. One thing tends to stand out for me though.

Since the dawn of platforms, I believe the first piece of comparison marketing has been “avoids lock-in”. You know you’ve seen it too. For those that may not be completely familiar with the term, “lock-in” describes a platform where all the components need to come from the same manufacturer or group of manufacturers in order to work properly. An example would be if a networking solution required you to purchase routers, switches, access points, and firewalls from a single vendor in order to work properly.

Chain of Fools

Lock in is the greatest asset a platform company has. The more devices they can sell you the more money they can get from you at every turn. That’s what they want. So they’re going to do everything they can to keep you in their ecosystem. That includes things like file formats and architectures that require the use of their technology or of partner technologies to operate correctly.

So, the biggest question here is “What’s wrong with that?” Note that I’m not a proponent of lock-in. Rather, I’m against the false appearance of choices. Sure, offering a platform with the promise of “no lock-in” is a great marketing tool. But how likely are you to actually follow through on that promise?

I touched on this a little bit earlier this year at Aruba Atmosphere 2019 when I talked about the promise of OpenConfig allowing hardware from different vendors to all be programmed in a similar way. The promise is grand that you’ll be able to buy an access point from Extreme and run it on an Aruba Controller while the access layer polices are programmed into Cisco switches. It’s the dream of interoperability!

More realistically, though, you’ll find that most people aren’t that concerned about lock-in. The false choice of being open to new systems generally comes down to one single thing: price. The people that I know that complain the most about vendor lock-in almost always follow it up with a complaint about pricing or licensing costs. For example:

The list could go on for three or four more pages. And the odds are good you’ve looked at one of those solutions already or you’re currently dealing with something along those lines. So, ask yourself how much pain vendor lock-in brings you aside from your checkbook?

The most common complaint, aside from price, is that the vendor solution isn’t “best of breed”. Which has always been code for “this particular piece sucks and I really wish I could use something else”. But there’s every possibility that the solution sucks because it has to integrate tightly with the rest of the platform. It’s easy to innovate when you’re the only game in town and trying to get people to buy things from you. But if you’re a piece of a larger puzzle and you’re trying to have eight other teams tell you what your software needs to do in order to work well with the platform, I think you can see where this is going.

How many times have you actually wished you could pull out a piece and sub in another one? Again, aside from just buying the cheapest thing off the shelf? Have you ever really hoped that you could sub in an Aerohive AP630 802.11ax (Wi-Fi 6) AP into your Cisco wireless network because they were first to market? Have you ever really wanted to rip out Cisco ISE from your integrated platform and try to put Aruba ClearPass in its place? Early adopters and frustrated users are some of the biggest opponents of vendor lock-in.

Those Three Words

I’m about to tell you why lock-in isn’t the demon you think it is. And I can do it in three words:

It. Just. Works.

Granted, that’s a huge stretch and we all know it. It really should be “well built software that meets all my functionality goals should just work”. But in reality, the reason why we all like to scream at lock-in when we’re writing checks for it is because the alternative to paying big bucks for making it “all just work” is for us to invest our time and effort into integrating two solutions together. And ask your nearest VAR or vendor partner how much fun that can be?

I used to spend a LOT of my time trying to get pieces and parts to integrate because schools don’t like to spend a lot of money on platforms. In Oklahoma they’re even allowed to get out of license agreements every year. Know what that means? A ton of legacy software that’s already paid for sitting around waiting to run on brand new hardware they just bought. And oh, by the way, can you make all that work together in this new solution we were sold by the Vendor of the Month Club?

And because they got the best deal or the best package, I had to spend my time and effort putting things together. So, in a way, the customer was trading money from the hardware and software to me for my wetware — the brain power needed to make it all work together. So, in a way, I was doing something even worse. I was creating my own lock-in. Not because I was building an integrated solution with one vendor’s pieces. But because I was building a solution that was custom and difficult to troubleshoot, even with proper documentation.


Tom’s Take

Lock-in isn’t the devil. You’re essentially trading flexibility for ease-of-use. You’re trading the ability to switch out pieces of a solution for the ability to integrate the pieces together without expending much effort. And yes, I realize that some lock-in solutions are harder to integrate than others. I’m looking at you, Cisco ISE. But, that just speaks to how hard it is to create the kind of environment that you get when you are trying to create all kinds of integrations. You’ll find that the idea of freedom of choice is much more appealing than actually having the ability to swap things out at will.

Procrastination Party

“I’ll get to that later.”

“I’m not feeling it right now.”

“I have to find an angle.”

“It will be there tomorrow.”

Any of those sound familiar? I know they do for me. That’s because procrastination is the beast that lives inside all of us. Slumbering until a time when it awakes and persuades us to just put things off until later. Can’t hurt, right?

Brain Games

The human brain is an amazing thing. It is the single largest consumer of nutrients and oxygen in the human body. It’s the reason why human babies are born practically helpless due to the size in relation to the rest of an infant. It’s the reason why we can make tools, ponder the existence of life in the universe, and write kick-ass rock and roll music.

But the human brain is lazy. It doesn’t like thinking. It prefers simple patterns and easy work. Given a choice, the human brain would rather do some kind of mindless repetitive task ad naseum instead of creating. When you think about it that makes a lot of sense from a biological perspective. Tasks that are easy don’t engage many resources. Which means the brain doesn’t have to operate as much and can conserve energy.

But we don’t want our brains to be lazy. We want to create and learn and do amazing things with our thoughts. Which means we have to overcome the inertia of procrastination. We have to force ourselves to move past the proclivity to be lazy in our thoughts. It is said that the hardest part of running isn’t the mileage but is instead getting up in the morning and putting on your shoes. Likewise, the hardest part of being creative isn’t the actual thinking but is instead starting the process of it in the first place.

Strategies for Anti-Procrastination

I have some methods I use to fight my tendency to procrastinate. I can’t promise they’ll work for you but the idea is that you base your strategies around the ideas and go from there.

  • Make Yourself Uncomfortable – I’m not talking about laying on a bed or nails or working in the freezing cold. What I mean is take yourself out of you comfort zone. Instead of sitting in my office when I need to write a few things, I intentionally go somewhere in public, like a coffee shop. Why? Because putting myself in a place with noice and uncomfortable chairs makes me focus on what I’m supposed to be doing. My brain can’t get lazy when it’s being stimulated from all sides. I have to apply some effort to drown out the conversation and that extra effort pushes me into action.
  • Set a Small Goal to Relax – This one works wonders for your brain. If it thinks there’s even a remote possibility in the near future that it can relax it’s going to race to that finish line as fast as possible. If you’re familiar with the Pomodoro Technique that’s basically what’s going on. Your brain sees the opportunity to be lazy five minutes out of every 30 so it pushes to get there. Except you’re tricking it by forcing it to do work to get there. You become more productive because you’re thinking you get to relax in ten or fifteen minutes when in fact you’re much more productive because you’ve secretly been focused the whole time.
  • Create a Zone For Yourself – This is kind of the opposite of the first point above but it works just as well. Your brain likes to do mindless repetitive tasks because they require very little energy. So why not use that against your lazy brain and trick it into thinking whatever you’re doing is actually “easy”? There’s a ton of ways to do this. My two favorites involve aural stimulation. There are a lot of folks that have a Coding Playlist or a Writing Setlist that they use to zone out and accomplish tasks that require some focus but are mindless in nature. Likewise, I often use noise generators to do the same thing. My current favorite is A Soft Murmur because it allows me to customize the noise that I want to help me shut off the distractions and focus on what I’m doing. I’ll often pair it with a sprint from the second point above to help me really dial in what I’m trying to work on.

Tom’s Take

Your mileage may very greatly on the items above. Your brain doesn’t work like mine. You know how you think and what it takes to motivate you. Maybe it’s massive amounts of coffee or a TV playing in the background. But knowing that your mind wants to shut off active processing and do repetitive things over and over again does wonders to help figure out how best to engage it and work smarter. You can’t always stop procrastination. But, with a little planning, you can put it off until tomorrow.

Fast Friday Thoughts – Networking Field Day 21

This week has been completely full at Networking Field Day 21 with lots of great presentations. As usual, I wanted to throw out some quick thoughts that fit more with some observations and also to set up some topics for deeper discussion at a later time.

  • SD-WAN isn’t just a thing for branches. It’s an application-focused solution now. We’ve moved past the technical reasons for implementation and finally moved the needle on “getting rid of MPLS” and instead realized that the quality of service and other aspects of the software allow us to do more. That’s especially true for cloud initiatives. If you can guarantee QoS through your SD-WAN setup you’re already light years ahead of where we’ve been already.
  • Automation isn’t just figuring out how to make hardware and software do things really fast. It’s also about helping humans understand which things need to be done fast and automatically and which things don’t. For all the amazing stuff that you can do with scripting and orchestration there are still tasks that should be done manually. And there are plenty of people problems in the process. Really smart companies that want to solve these issues should stop focusing on using technology to eliminate the people and instead learn how to integrate the people into the process.
  • If you’re hoping to own the entire stack from top to bottom, you’re going to end up disappointed. Customers aren’t looking for mediocre solution from a single vendor. They’re not even looking for a great solution from a couple. They want the best and they’re not afraid to go where they want to get them. And when you realize that more and more engineering and architecture talent is focused on integrating already you will see that they don’t have any issues making your solution work with someone else’s instead of counting on you to integrate your platforms together at some point in the future.

Tom’s Take

Networking Field Day is always a great time for me to talk to some of the best people in the world and hear from some of the greatest companies out there about what’s coming down the pipeline. The world of networking is changing even more than it has in the last few software-defined years.

The Certification Ladder

Are you climbing the certification ladder? If you’re in IT the odds are good that you are. Some people are just starting out and see certifications as a way to get the knowledge they need to do their job. Others see certs as a way to get out of a job they don’t like. Still others have plenty of certifications but want to get the ones at the top of their field. This last group are the ones that I want to spend some time talking about.

Pushing The Limit

Expert-level certifications aren’t easy on purpose. They’re supposed to represent the gap between being good at something and going above and beyond. For some that involves some kind of practical test of skills like the CCIE. For others it involves a board interview process like the VCDX. Or it could even involve a combination of things like the CWNE does with board review and documentation submissions.

Expert certifications aren’t designed to be powered through in a short amount of time. That’s because it’s difficult to become an expert at something without putting in the practice time. For some tests, that means meeting some minimum requirements. You can only attempt your VCDX when you have already passed the VCAP-DCA and VCAP-DCD test, for example. Or you may have a minimum requirement of time in the industry, such as the CISSP requirement of four years in the security industry.

But, more importantly, the requirement is that you truly are an expert. How many times have you bumped into someone that has a certification that you think to yourself, “How on earth did they pass that?” It should be fairly uncommon to run into a CCIE that you feel that way about. The test is rigorous and requires everyone to pass a very similar version of the practical exam. Sure, you still run into people that say the old 2-day exam was harder. But by and large, most CCIEs have had to endure the same kind of certification requirements.

Now, what people do after they get there is an entirely different matter altogether. There are a lot of people that get to the pinnacle of their certification journey and sit there on top of their mountain. They take time to survey the lands that they now watch over and they relax. They don’t see any need in going any further. They’ve done what they came to do. And for many that’s the way to go. Congratulations on your ride.

Still others use this opportunity negatively. They expect people to kiss the brass certificate and pay deference to them because of it. This can affect almost anyone. I remember years ago back to a time when I had just gotten my CCIE lab out of the way. I was working on a proposal for a customer. We had just gotten an email from the customer asking why we didn’t include a particular switch in the design. I told our team that we didn’t need it because the requirements of the design didn’t need something that cost three times over what we recommended. The customer’s response was, “Well, this other partner guy is a CCIE and he says we need that switch.” I replied back with, “Well, I’m a CCIE too, so let’s cut that crap and talk about the hardware.”

I’m not sure how many times that person had used the “I’m a CCIE” justification for their recommendations, but it shows me that some people believe a piece of paper speaks louder than their track record. Those people are usually the ones that fall back into the pattern of “listen to me because I passed tests” not “listen to me because I did the studying”. It’s important to ascribe value to passing a test, but remember that the test is a way to prove you have knowledge. It reminds me of this scene from Tommy Boy:

Throwing up a certification as justification for a recommendation is no different that just tossing a worthless guarantee on a box. Prove you know what you’re talking about instead of just saying you do.

Exceeding Your Reach

The last type of person that climbs the certification ladder is like the one in this tweet from my friend Hank Yeomans:

He looks at the ascent to the top of his certification ladder as a chance to do more. To build more. It’s not the end of the journey. It’s not bad to stop and look around at the new view from the top of your ladder when you’ve climbed it. But if you look at the journey as the start of something that you need to finish, you’re going to start immediately looking around to find the next thing that you need to do. Perhaps it’s learning a new technology related to the one that you just finished. Or maybe it’s that you want to figure out how to get even better at what you do.

People that never rest in their attempts to be better at the ones that ultimately change the way things are done. They don’t just accept that this is the way that things need to be. Instead, they use the top of their ladder to stretch out and see what they can reach. They realize that everything we do in life it just building on something else we’ve already done. We use Crawl, Walk, Run as a metaphor for building through a project or a process all the time. That’s because we know that you have to make steps all the time to progress. But what if someone just said, “You know what, I’ve mastered walking. I don’t need to run. All you people who only crawl listen to me because I’m better than you!” It would show how short-sighted they are when it comes to continuing the journey.


Tom’s Take

Many times, I’ve talked about the fact that I relaxed after I passed my CCIE and enjoyed not studying into the wee hours of the night. But after a while I started getting uncomfortable around 8-9pm. Because there was a little voice in the back of my head that kept telling me “You should be studying for something.” Instinctively, that voice knew that I needed to continue my journey. I would never be content resting on my laurels and I could never bring myself to use my certification as a crutch to make myself look important to others. Instead, I needed to push myself to build on what I’ve already done and make myself better. As Hank said, it’s just a foothill on a greater journey. Once you’ve learned how to use your ladder to increase your reach, even the sky isn’t the limit any longer.