Category Archives: Musing

Brand Protection

Posted on by
Reply

I woke up at 5am this morning to order a new iPhone. I did this because I wanted the new camera upgrades along with some other nice-to-haves. Why did I get an iPhone and not a new Samsung? Why didn’t I look at any of the other phones on the market? It’s because I am a loyal Apple customer at this point. Does that mean I think the iPhone is perfect? Far from it! But I will choose it in spite of the flaws because I know it has room to be better.

That whole story is repeated time and again in technology. People find themselves drawn to particular companies or brands. They pick a new phone or computer or car based on their familiarity with the way they work or the design choices that are made. But does that mean they have to be loyal to that company no matter what?

Agree to Disagree

One of the things that I feel is absolutely paramount to being a trusted advisor in the technology space is the ability to be critical of a product or brand. If you look at a lot of the ambassador or influencer program agreements you’ll see language nestled toward the bottom of the legalese. That language usually states you are not allowed to criticize the brand for their decisions or talk about them in a disparaging way. In theory the idea is important because it prevents people from signing up for the program and then using the platform to harshly and unfairly criticize the company.

However, the dark side of those agreements usually outweigh the benefits. The first issue is that companies will wield the power to silence you to great effect. The worst offenders will have you removed from the program and potentially even sue you. Samsung almost stranded bloggers 10 years ago because of some brand issues. At the time it seemed crazy that a brand would do that. Today it doesn’t seem quite so far-fetched.

The second issue is that those agreements are written in such a way as to be able to cause issues for you even if you didn’t realize you were doing something you weren’t supposed to be doing. Think about celebrities that have tweeted about a new Android phone and the tweet has metadata that says sent with Twitter for iPhone. How about companies that get very upset when you discuss companies that they see as competitors. Even if you don’t see them as competitors or don’t see the issue with it you may find yourself running afoul of the brand when they get mad about you posting a pic of their product next to the supposed competition.

In my career I’ve worked at a value-added reseller (VAR) where I found myself bound by certain agreements to talk positively about brands. I’ve also found myself on the wrong side of the table when that brand went into a bidding process with another VAR and then tried to tell me I could say bad things about them in the process because I was also their partner. The situation was difficult because I was selling against a partner that went with another company but I also needed to do the work to do the bid. Hamstringing me by claiming I had to play by some kind of weird rules ultimately made me very frustrated.

Blind Faith

Do companies really want ambassadors that only say positive things about the brand? Do they want people to regurgitate the marketing points with everyone and never discuss the downsides of the product? Would you trust someone that only ever had glowing things to say about something you were trying to buy?

The reality of our world today is that the way that people discuss products like this influences what we think about them. If the person doing the discussion never has a negative thing to say about a company then it creates issues with how they are perceived. It can create issues for a supposedly neutral or unbiased source if they only ever say positive things, especially if it later comes out they weren’t allowed to say something negative for fear they’d get silenced or sued.

Think about those that never say anything negative toward a brand or product. You probably know them by a familiar epithet: fanboys. Whether it’s Apple or Tesla or Android or Ford there are many people out there that aren’t just bound by agreement to always speak positively about something. They will go out of their way to attack those that speak ill of their favorite product. If you’ve every had an interaction with a fan online that left you shaking your head because you can’t understand why they don’t see the issues you know how difficult that conversation can be.

As a company, you want people discussing the challenges your product could potentially face. You want an honest opinion that it doesn’t fit in a particular vertical, for example. Imagine how upset a customer would be if they bought your product based on a review from a biased influencer only to find that it didn’t fit your need because the influencer couldn’t say anything negative. Would that customer be happy with your product? Would the community trust that influencer in the future?

Tom’s Take

Honesty isn’t negativity. You can be critical of something you enjoy and not insinuate you’re trying to destroy it. I’ll be the first person to point out the shortcomings of a product or company. I’ll be fair but honest. I’ll point out where the improvements need to be made. One of the joys of my day job at Tech Field Day is that I have the freedom to say what I want in my private life and not worry about my work agreements getting me in trouble as has happened with some in the past. I’ll always tell you straight up how I feel. That’s how you protect your brand. Not with glowing reviews but with honest discussion.

When Were You Last a Beginner?

Posted on by
1

In a couple of weeks I’m taking the opportunity to broaden my leadership horizons by attending the BSA leadership course known as Philmont Leadership Challenge. It’s a course that builds on a lot of the things that I’ve been learning and teaching for the past five years. It’s designed to be a sort of capstone for servant leadership and learning how to inspire others. I’m excited to be a part of it in large part because I get to participate for a change.

Being a member of the staff for my local council Wood Badge courses has given me a great opportunity to learn the material inside and out. I love being able to teach and see others grow into leaders. It’s also inspired me to share some of those lessons here to help others in the IT community that might not have the chance to attend a course like that. However the past 3 years have also shown me the value of being a beginner at something from time to time.

Square One

Everyone is new at something. No one is born knowing every piece of information they’ll need to know for their entire lives. We learn language and history and social skills throughout our formative years. When we get to our career we learn skills and trades and figure out how to do complex things easily. For some of us we also learn how to lead and manage others. It’s a process of building layer upon layer to be better at what we do. Those skills give us the chance to show how far we’ve come in a given area by the way we understand how the complex things we do interact.

One of my favorite stories about this process is when I first started studying for my CCIE back in 2008. I knew the first place I should look was the Cisco Press certification guide for the written exam. As I started reading through the copy I caught myself thinking, “This is easy. I already know this.” I even pondered why I bothered with those pesky CCNP routing books because everything I needed to know was right here!

The practitioners in the audience have already spotted the logical fallacy in my thinking. The CCIE certification guide was easy and remedial for me because I’d already spent so much time reading over those CCNP guides. And those CCNP guides only made sense to me because I’d studied for my CCNA beforehand. The advanced topics I was refreshing myself on could be expanded because I understood the rest of the information that was being presented already.

When you’re a beginner everything looks bigger. There’s so much to learn. It’s worrisome to try and figure out what you need to know. You spend your time categorizing things that might be important later. It can be an overwhelming process. But it’s necessary because it introduces you to the areas you have to understand. You can’t start off knowing everything. You need to work you way into it. You need to digest information and work with it before moving on to add more to what you’ve learned. Trying to drink from a firehose makes it impossible to do anything.

However, when you approach things from a perspective of an expert you lose some of the critical nature of being bad at something. You might think to yourself that you don’t need to remember a protocol number or a timer value because “they never worry about that anyway”. I’ve heard more than a few people in my time skip over valuable information at the start of a course because they want to get to the “good stuff” that they just know comes later. Of course, skipping over the early lessons means they’re going to be spending more time reviewing the later information because they missed the important stuff up front.

Those Who Teach

You might think to yourself that teaching something is a harder job. You need to understand the material well enough to instruct others and anticipate questions. You need to prep and practice. It’s not easy. But it also takes away some of the magic of learning.

Everyone has a moment in their journey with some technology or concept where everything just clicks. You can call it a Eureka moment or something similar but we all remember how it felt. Understanding how the pieces fit together and how you grasp that interconnection is one of the keys to how we process complex topics. If you don’t get it you may never remember it. Those moments mean a lot to someone at the start of their journey.

When you teach something you have to grasp it all. You may have had your Eureka moment already. You’re also hoping that you can inspire one in others. If you’re trying to find ways to impart the knowledge to others based on how you grasped it you may very well inspire that moment. But you also don’t have the opportunity to do it for yourself. We’re all familiar with the old adage that familiarity breeds contempt. It’s easy to fall into that trap with a topic you are intimately familiar with.

In your career have you ever asked a question about a technical subject to an expert that started their explanation with “it’s really easy…”? Most of us have. We’ve probably even said that phrase ourselves. But it’s important to remember that not everyone has had the same experiences. Not everyone knows the topic to the level that we know it. And not everyone is going to form the same connections to recall that information when they need it again. It may be simple to you but for a beginner it’s a difficult subject they’re struggling to understand. How they comprehend it relies heavily on how you impart that knowledge.

Wide Eyed Wonder

Lastly, the thing that I think is missing in the expert level of things is the wonder of learning something new for the first time. It’s easy to get jaded when you have to take in a new piece of information and integrate it into your existing view. It can be frustrating in cases where the new knowledge conflicts with old knowledge. We spent a lot of time learning the old way and now we have to change?

Part of the value of being a beginner is looking at things with fresh eyes. No doubt you’ve heard things like “this is the way we’ve always done it” in meetings before. I’ve written about challenging those assumptions in the past and how to go about doing it properly but having a beginner perspective helps. Pretend I’m new to this. Explain to me why we do it that way. Help me understand. By taking an approach of learning you can see the process and help fix the broken pieces or optimize the things that need to be improved.

Even if you know the subject inside and out it can be important to sit back and think through it from the perspective of a beginner. Why is a vanilla spanning tree timer 50 seconds? What can be improved in that process? Why should things not be hurried. What happens when things go wrong? How long does it take for them to get fixed? These are all valid beginner questions that help you understand how others look at something you’re very familiar with. You’ll find that being able to answer them as a beginner would will lead to even more understanding of the process and the way things are supposed to work.

Tom’s Take

There are times when I desperately want to be new at something again. I struggle with finding the time to jump into a new technology or understand a new concept because my tendency is to want to learn everything about it and there are many times when I can’t. But the value of being new at something isn’t just acquiring new knowledge. It’s learning how a beginner thinks and seeing how they process something. It’s about those Eureka moments and integrating things into your process. It’s about chaos and change and eventually understanding. So if you find yourself burned out it’s important to stop and ask when you were last a beginner.

Why 2023 is the Year of Wi-Fi 6E

Posted on by
4

If you’re like me, you chuckle every time someone tells you that next year is the year of whatever technology is going to be hot. Don’t believe me? Which year was the Year of VDI again? I know that writing the title of this post probably made you shake your head in amusement but I truly believe that we’ve hit the point of adoption of Wi-Fi 6E next year.

Device Support Blooms

There are rumors that the new iPhone 14 will adopt Wi-Fi 6E. There were the same rumors when the iPhone 13 was coming out and the iPhone rumor mill is always a mixed bag but I think we’re on track this time. Part of the reason for that is the advancements made in Wi-Fi 6 Release 2. The power management features for 6ER2 are something that should appeal to mobile device users, even if the name is confusing as can be.

Mobile phones don’t make a market. If they were the only driver for wireless adoption the Samsung handsets would have everyone on 6E by now. Instead, it’s the ecosystem. Apple putting a 6E radio in the iPhone wouldn’t be enough to tip the scales. It would take a concerted effort of adoption across the board, right? Well, what else does Apple have on deck that can drive the market?

The first thing is the rumored M2 iPad Pro. It’s expected to debut in October 2022 and feature upgrades aside from the CPU like wireless charging. One of the biggest features would be the inclusion of a Wi-Fi 6E radio as well to match the new iPhone. That would mean both of Apple’s mobile devices could enjoy the faster and less congested bandwidth of 6 GHz. The iPad would also be easier to build a new chip around compared to the relatively cramped space inside the iPhone. Give the professional nature of the iPad Pro one might expect an enterprise-grade feature like 6E support to help move some units.

The second thing is the looming M2 MacBook Pro. Note for this specific example I’m talking about the 14” and 16” models that would features the Pro and Max chips, not the 13” model running a base M2. Apple packed the M1 Pro and M1 Max models with new features last year, including more ports and a snazzy case redesign. What would drive people to adopt the new model so soon? How about faster connectivity? Given that people are already complaining that the M1 Pro has slow Wi-Fi Apple could really silence their armchair critics with a Wi-Fi 6E radio.

You may notice that I’m relying heavily on Apple here as my reasoning behind the projected growth of 6E in 2023. It’s not because I’m a fanboy. It’s because Apple is one of the only companies that controls their own ecosystem to the point of being able to add support for a technology across the board and drive adoption among their user base. Sure, we’ve had 6E radios from Samsung and Dell and many others for the past year or so. Did they drive the sales of 6E radios in the enterprise? Or even in home routers? I’d argue they haven’t. But Apple isn’t the only reason why.

Oldie But Goodie

The last reason that 2023 is going to be the year of Wi-Fi 6E is because of timing. Specifically I’m talking about the timing of a refresh cycle in the enterprise. The first Wi-Fi 6 APs started coming into the market in 2019. Early adopters jumped at the chance to have more bandwidth across the board. But those APs are getting old by the standards of tech. They may still pass traffic but users that are going back to the office are going to want more than standard connectivity. Especially if those users splurged for a new iPhone or iPad for Christmas or are looking for a new work laptop of the Macintosh variety.

Enterprises may not have been packed with users for the past couple of years but that doesn’t mean the tech stood still. Faster and better is always the mantra of the cutting edge company. The revisions in the new standards would make life easier for those trying to deploy new IoT sensors or deal with with congested buildings. If enterprise vendors adopt these new APs in the early part of the year it could even function as an incentive to get people back in the office instead of the slow insecure coffee shop around the corner.

One other little quirky thing comes from an report that Intel is looking to adopt Wi-Fi 7. It may just be the cynic in me talking but as soon as we start talking about a new technology on the horizon people start assuming that the “current” cutting edge tech is ready for adoption. It’s the same as people that caution you not to install a new operating system until after the first patch or service release. Considering that Wi-Fi 6 Release 2 is effectively Wi-Fi 6E Service Pack 1 I think the cynics in the audience are going to think that it’s time to adopt Wi-Fi 6E since it’s ready for action.

Tom’s Take

Technology for the sake of tech is always going to fail. You need drivers for adoption and usage. If cool tech won the day we’d be watching Betamax movies or HD-DVD instead of streaming on Netflix. Instead, the real winners are the technologies that get used. So far that hasn’t been Wi-Fi 6E for a variety of reasons. However, with the projections of releases coming soon from Apple I think we’re going to see a massive wave of adoption of Wi-Fi 6E in 2023. And if you’re reading this in late 2023 or beyond and it didn’t happen, just mentally change the title to whatever next year is and that will be the truth.

Enforcing SLAs with Real Data

Posted on by
Reply

I’m sure by now you’ve probably seen tons of articles telling you about how important it is to travel with location devices in your luggage. The most common one I’ve seen is the Apple AirTag. The logic goes that if you have one in your checked suitcase that you’ll know if there are any issues with your luggage getting lost right away because you’ll be notified as soon as you’re separated from it. The advice is sound if you’re someone that checks your bag frequently or has it lost on a regular basis.

The idea behind using technology to enforce an agreement is a great one. We make these agreements all the time, especially in networking. These service level agreements (SLAs) are the way we know we’re getting what we pay for. Take a leased line, for example. You typically pay for a certain speed and a certain amount of availability. The faster the link or the more available it is the more it costs. Any good consumer is going to want to be sure they’re paying for the right service. How can you verify you’re getting what you’re paying for?

For a long time this was very hard to do. Sure, you could run constant speed tests to check the bandwidth. However, the reliability was the part that was typically the more expensive thing to add to the service. Making a circuit more reliable means adding more resources on the provider side to ensure it stays up. Allocating those resources means someone needs to pay for them and that is usually on the customer side.

It’s easy to tell when a link goes down during working hours. You can see that you’re not getting traffic out of your network. But what about those times when the circuit isn’t being as heavily utilized? What about the middle of the night or holidays? How can you ensure that you’re getting the uptime you pay for?

Trust and Verify

This is actually one of the groundbreaking areas that SD-WAN pioneered for networking teams when it came out years ago. Because you have a more modern way of maintaining the network as well as a way to route application traffic based on more than source and destination address you can build in some fancy logic to determine the reliability of your circuits too.

One of the biggest reasons in the past to use a leased line over a broadband circuit was that reliability factor. You need MPLS because it’s more stable than a cable modem. You get guaranteed bandwidth. It’s way more reliable. Those are the claims that you might hear when you talk to the salesperson at your ISP. But do they really hold water? The issue for years is that you had no way of knowing because your analytics capabilities were rudimentary in most cases. You could monitor the link interface but that was usually from the central office and not the remote branch. And depending on the polling interval you could miss downtime events.

SD-WAN changed that because now you could put an intelligent device on the edge that constantly monitored the link for throughput and reliability. The first thought was to do this for the broadband links to see how congested and unreliable they could be do know when to switch traffic to the more stable link. Over time admins started putting those same monitors on the MPLS and leased line circuits as well. They found that while broadband, such as cable and DSL, was typically more reliable than the sales people would have you believe it was the relatively unreliable leased circuits that surprised everyone.

Much like the above example of lost luggage you previously had to take the airlines at their word when they said something was lost. No details were available. Did your bag ever leave the airport when you flew out? Did it make it to the right location but get stuck somewhere? Did your bag get on the wrong plane and end up in Cleveland instead of Las Vegas? Because the airline reporting systems were so opaque you had no idea. Now, with the advent of Tile and AirTags and many others, you can see exactly where it is at all times.

The same thing happened with SD-WAN analytics. Now, armed with proof that links weren’t as reliable as the SLA, admins could choose to do one of two things. They could either force the provider to honor the agreement and provide better service to meet the agreement. Or the company could reduce their contract to the level of service they are actually getting instead of the one that is promised by not delivered. Having the data and a way to prove the reliability helped with the negotiations.

Once the providers knew that organizations had the ability to verify things they also had to up their game by including ways to monitor their own performance to ensure that they were meeting their own metrics. Overall the situation led to better results because having technology to enforce agreements makes all sides aware of what’s going on.

Tom’s Take

I’ve only had a couple of bags misplaced in my travel time so I haven’t yet had the need to go down the AirTag route. I’ve done it on occasion for international travel because knowing when my bag is about to come out on the carousel helps me figure out how much time it’s going to take me to get through customs. The idea of using technology to make things more transparent is important to me on a bigger scale though. If you can’t verify the promises you make then you shouldn’t make them. Having the AirTag or SD-WAN software to ensure we’re getting what we pay for are just parts of a bigger opportunity to provide better experiences.

All Problems Are Hardware Problems

Posted on by
1

When I was a lad in high school I worked for Walmart. I learned quite a bit about retail at my early age but one of the fascinating things I used in the late 1990s was a wireless inventory unit, colloquially known as a Telxon. I was amazed by the ability to get inventory numbers on a device without a cable. Since this was prior to the adoption of IEEE 802.11 it was a proprietary device that only worked with that system.

Flash forward to the 2020s. I went to Walmart the other day to look for an item and I couldn’t find it. I asked one of the associates if it was in stock. They said they could check and pulled out their phone. To my surprise they were able to launch an app and see that it was in stock in the back. As I waited for them to return with the item I thought about how 25 years of progress had changed that hardware solution into something software focused.

Hardware Genesis

All problems start as hardware problems. If there’s a solution to an issue you’re going to build something first. Need to get somewhere fast? Trains or cars. Need to get there faster? Planes. Communcations? Phones or the Internet. All problems start out by inventing a thing that does something.

Technology is all about overcoming challenges with novel solutions. Sometimes those leaps are major, like radio. Other times the tool is built on that technology, like wireless. However they are built they almost always take physical form first. The reasoning is simple in my view. You have to have the capability to build something before it can be optimized.

If you’re sitting there saying to yourself that a lot of our solutions today are software-focused you would be correct. However, you’re also making some assumptions about hardware ubiquity already. Sure, the smartphone is a marvel of software simplicity that provides many technological solutions. It’s also a platform that relies on wireless radio communications, Internet, and cloud computing. If you told someone in 2005 that cellular phones would be primarily used as compute devices they would have laughed at you. Because the hardware at the time was focused on audio communications and only starting to be used for other things, like texting or PDA functions.

Hardware exists first to solve the issue at hand. Once we’ve built something that can accomplish the goal we can then optimize it and make it more common. Servers seem like a mainstay of our tech world today but client/server architecture wasn’t always the king of the hill. Cloud computing seems like an obvious solution today but AWS and GCP haven’t always existed. Servers needed to become commonplace before the idea to cluster them together and offer their capacity as a rentable service emerged.

Software to the Rescue

Software doesn’t like unpredictability. Remember the Telxon example above? Those devices ran proprietary software that interfaced with a single server. There was no variation. If you wanted to use the inventory software on a different device you were out of luck. There was zero flexibility. It was a tool that was designed for a purpose. So many of the things in our lives are built the same way. Just look at your home phone, for example. That is, if you still have one. It’s a simple device that doesn’t even run software as we know it. Just a collection of electrical switches and transistors that accomplish a goal.

However, we have abstracted the interface of a telephone into a device that provides flexibility. Any smart phone you see is a computer running software with a familiar interface to make a phone call. There’s no specialized hardware involved. Just an interface to a system that performs the same functions that a traditional phone would. There are no wires. No switches like an old telecom engineer would recognize. Just a software platform that sends voice over the Internet to a receiving station.

Software becomes an option when we’ve built a hardware environment that is sufficiently predictable as to allow the functions to be abstracted. The Walmart Telxon can function as an app on a smartphone now because we can write an app to perform those same functions. We’ve also created interfaces into inventory systems that can be called by software apps and everyone that works for Walmart either carries a phone or has access to a device that can run the software.

Tom’s Take

Programs and platforms provide us with the flexibility to do things any time we want. But they only have that capability because of the infrastructure we’ve built out. We have to build the hardware before we can abstract the functions into software. The most complicated unsolved problem you can think of today will eventually be solved by a piece of kit that will eventually become a commodity and replicated as a series of functions that run on everything years later. That’s the way that things have always been and how they will always be.

Saying “Yes” the Right Way

Posted on by
Reply

If only I had known how hard it was to say “no” to someone. Based on the response that my post about declining things had gotten I’d say there are a lot of opinions on the subject. Some of them were positive and talked about how hard it is to decline things. Others told me I was stupid because you can’t say no to your boss. I did, however, get a direct message from Paul Lampron (@Networkified) that said I should have a follow up post about saying yes in a responsible manner.

Positively Perfect

The first thing you have to understand about the act of asking something is that we’re not all wired the same way when it comes to saying yes. I realize that article is over a decade old at this point but the ideas in it remain valid, as does this similar one from the Guardian. Depending on your personality or how you were raised you may not have the outcome you were expecting when you ask.

Let me give you a quick personal example. I was raised with a southern style mentality that involves not just coming out and asking for something. You may have seen this expressed as excessive small talk when you are trying to ask for help. You may feel frustrated that the person that is asking you for something doesn’t come right out and ask for it. You may not understand that this person is trying to feel out your emotional responses before asking a question so they’re almost assured to get a positive answer.

Apply that knowledge to the opposite situation. What if the person that has a hard time come right out and asking for something is trying to interpret a request from someone else? Are they going to accept it for what it is? Or are they going to apply their own knowledge to the situation and assume that the person must be asking for something very important because they know how hard it is for them to ask in that situation? Can you see how this disconnect can create strife in the workplace because different values are being applied to something as simple as a request for help? Now you can see the undertones of the earlier conversation about saying “no” to people that constantly ask for things.

How To Say Yes

How do we agree to things then? If we’re trying to get things accomplished we need to be able to ask for help or tell our coworkers we need them to do something. How do we say “yes” and make sure that everyone involved knows that we are doing what we can to make it happen? How do we avoid being overwhelmed?

First, don’t just agree to make people happy. This is the number one issue that needs to be resolved in the workplace. It’s one that starts early on in our careers. We need to put limits on what we’re going to agree to do in order to keep from not having any boundaries whatsoever. Imagine a junior admin or a new hire constantly agreeing to work on things or come in on the weekends to do cutovers and the like. Does that style of work appeal to you? Do you think it’s something that show initiative and desire? If you’ve been in your role for a while do you think it’s a good thing to come in on the weekends? Or does it sound more like this person needs to have a little more work life balance?

If you agree to do things because you’re trying to make your boss happy or show your value to the organization you’re setting yourself up for eventual failure. Good managers and leaders don’t want robots that have zero personal time. They want good employees that know when they’re reaching their limits and can respectfully and responsibly decline things that would push them over the edge. When you agree to do something outside the scope of your job or perform extra work, make sure that the person you’re talking to understands that it’s outside the norm for you. If you tell them that this isn’t normally part of your role but you’re doing it to learn or that you’re helping someone out that asked you to come in for a cutover you’re setting the expectation that there is a purpose behind what you’re doing and not just that you agree to anything you’re told.

Second, you need to help people understand what is going on with what you’re doing. If an overworked colleague comes to you to ask you for help with something and you’re overworked too you’re not going to be able to provide them with much help or support. For those out there that think an outright refusal is a bad thing, like me present you with the following statement to clarify what’s going on:

What I need to make my answer “yes” is…

In essence, you’re telling the person that you want to agree to do what they’re asking but you need them to understand what’s going on beyond just agreeing. You’re not putting conditions on your answer so much as you’re telling them what you’re involved with and what needs to change in order to help them out. You’re informing them of the roadblocks that are keeping you from helping. That’s responsible in my book. While I’m sure there are people that will say it feels selfish to phrase answers like that you also have to see that you’re not saying “no” without providing context. You’re telling them you do want to help but that you need these other things to go a certain way too.

Third, you need to make sure you keep track of what happens after you agree. Does the job need to be done frequently and you always get asked to do it? Is it a one-time thing never to be seen or heard from again? Are you recognized for your effort? Even if it’s just a simple “thank you”? It sounds silly to keep track of things like this but it’s important because it provides data for you about how often you’re being pulled away to do other things. If this is a recurring task that your manager is asking you to do then it needs to be included in your job role. If it’s something that gets asked of you all the time and no one ever knows what you’re doing then you need to find out why.

Documenting your extra tasks will help you understand who is always coming to you for help and let you do something to reduce that. Do they need additional training? Are they being tasked with something that someone else should be handling? Do they just have a habit of asking you to help them with things because they’re overwhelmed too? Or, in a more negative light, are they making you do the work so they can take the credit? These are all questions that can only be answered when you have data. If you just have it in your head that you’re always helping a particular coworker or it feels like you’re always getting a phone call to run a particular report for someone you need to keep track of it so you can speak with confidence when it comes up.

Tom’s Take

There’s a lot of effort that goes into agreeing to do something for someone outside of what you normally do at work. It is true that you can’t say “no” to every request. However, you can agree in such a way as to help people understand what you’re working on and under what conditions you will be able to help. Again, I’m pretty sure there are those in the community that will tell me that I’m being prickly when I say that you need to put conditions on your agreement but you also have to see that saying yes to everything without taking your own situation into account is just as bad as saying no to things. Either you’re going to be seen as the person with no boundaries that will just do anything or you’re going to get so overwhelmed with work that you don’t get anything done and you end up in the same mess you’d be if you’d said no.

Practice Until You Can’t Get It Wrong

Posted on by
Reply

One of the things that I spend a lot of my time doing it teaching and training. Not the deeply technical stuff like any one of training programs out there or even the legion of folks that are doing entry-level education on sites like Youtube. Instead, I spend a lot of my time bringing new technologies to the fore and discussing how they impact everyone. I also spend a lot of time with youth and teaching them skills.

One of the things that I’ve learned over the years is that it’s important to not only learn something but to reinforce it as well. How much we practice is just as important as how we learn. We’re all a little guilty of doing things just enough to be proficient without truly mastering a skill.

Hours of Fun

You may have heard of the rule proposed by Malcolm Gladwell that it takes 10,000 hours to become an expert at something. There’s been a lot of research debunking this “rule of thumb”. In fact it turns out that the way you practice and your predisposition to how you learn has a lot do to with the process as well.

When I’m teaching youth, I see them start a new skill and keep going until they get their first success. It could be tying a knot or setting up a tent or some other basic skill. Usually, with whatever it is, they get it right and then decide they are proficient in the skill. And that’s the end of it until they need to be tested on it or something forces them to use it later.

For me, the proficiency aspect of basic skills is maddening. We teach people to do things like tying knots or programming switch ports but we don’t encourage them to keep practicing. We accept that proficiency is enough. Worse yet, we hope that the way they will gain expertise is by repetition of the skill. We don’t set the expectation of continued practice.

That’s where the offhanded Gladwell comment above really comes from. The length of time may have been completely arbitrary but the reality is that you can’t really master something until you’ve done it enough that the skill becomes second nature. Imagine someone riding a bicycle for the first time. If they stopped when they were able to pedal the bike they’d never be able to ride it well enough to maneuver in traffic.

Likewise, we can’t rely on simple proficiency for other tasks either. If we just accept that an operations person just learns VLAN configuration once and then we hope they’ll know it well enough that they can do it again later we’re going to either be frustrated when they have to keep looking up the commands for the task or, worse yet, when they bring down the network because they didn’t remember that you needed to use the add keyword on a trunk port and they wipe out a chunk of the network core.

Right vs. Wrong

For all those reasons above I ask my students to take things a little further. Rather than just doing something until you have an initial success I ask them to practice until they have it ingrained into their motor pathways. Put more simply:

Don’t practice until you get it right. Practice until you can’t get it wrong.

The shift in thinking helps people understand the importance of repeated practice. Getting it right is one thing. Understanding all the possible ways something can be done or every conceivable situation is something entirely different. Sure, you can configure a VLAN. Can you do it on every switch? Do you know what order the commands need to be done in? What happens if you switch them? Do you know what happens when you enable two contradictory features?

Obviously there are things you’re not going to need to practice this much all the time. One of my favorites is the people in CCIE study groups that spend way more time working on things like BGP leak maps or the various ways that one could configure QOS on a frame relay circuit. Are these important things to know? Yes. Are they more important to know than basic layer 2/3 protocols or the interactions of OSPF and BGP when redistributing? No.

Tom’s Take

When I was younger, I watched the Real Ghostbusters cartoon. One of the episodes featured Winston asking Egon if he could read Summerian. His response? “In my sleep, underwater, and in the dark. Of course I can read Summerian.”

Practice the basics until you understand them. Don’t miss a beat and make sure you have what you need. But don’t stop there. Keep going until you can’t possibly forget how to do something. That’s how you know you’ve mastered it. In your sleep, underwater, and in dark. Practice until you can’t get it wrong.

Friday Thoughts Pre-Cisco Live

Posted on by
1

It’s weird to think that I’m headed out to Cisco Live for the first time since 2019. The in-person parts of Cisco Live have been sorely missed during the pandemic. I know it was necessary all around but I didn’t realize how much I enjoyed being around others and learning from the community until I wasn’t able to do it for an extended period of time.

Now we’re back in Las Vegas and ready to take part in something that has been missed. I’ve got a busy lineup of meetings with the CCIE Advisory Council and Tech Field Day Extra but that doesn’t mean I’m not going to try and have a little fun along the way. And yes, before you ask, I’m going to get the airbrush tattoo again if they brought the artist back. It’s a tradition as old as my CCIE at this point.

What else am I interested in?

  • I’m curious to see how Cisco responds to their last disappointing quarter. Are they going to tell us that it was supply chain? Are they going to double down on the software transition? And how much of the purchasing that happened was pull through? Does that mean the next few quarters are going to be down for Cisco?
  • With the drive to get more and more revenue from non-hardware sources, where does that leave the partners of Cisco? Is there still a space for companies to create solutions to work with aspects that Cisco doesn’t do well? Or will they find themselves in a Sherlock situation eventually?
  • I’m cautiously optimistic that a successful conference will mean more of the same going forward. I know there’s going to be reports of COVID coming out of Vegas because there’s no way to have a group that big together and be 100% free. If there is a big issue with rates skyrocketing after a combined two weeks of RSA and Cisco Live it will force companies to rethink a return to conference season.

Tom’s Take

If you’re in Vegas next week I hope to see you around! Even if it’s just in passing in the hallway stop me and say hello. It’s been far too long since we’ve interacted as a group and I want to hear how things have been going. For those that aren’t going to go make sure to stay tuned for my recap.

Broadening Your Horizons, or Why Broadcom Won’t Get VMware

Posted on by
Reply

You might have missed the news over the weekend that Broadcom is in talks to buy VMware. As of right now this news is still developing so there’s no way of knowing exactly what’s going to happen. But I’m going to throw my hat into the ring anyway. VMware is what Broadcom really wants and they’re not going to get it.

Let’s break some of this down.

Broad Street

Broadcom isn’t just one of the largest chip manufactures on the planet. Sure, they make networking hardware that goes into many of the products you buy. Yes, they do make components for mobile devices and access points and a whole host of other things, including the former Brocade fibre channel assets. So they make a lot of chips.

However, starting back in November 2018, Broadcom has been focused on software acquisitions. They purchased CA Technologies for $19 billion. They bought Symantec the next year for $10 billion. They’re trying to assemble a software arm to work along with their hardware aspirations. Seems kind of odd, doesn’t it?

Ask IBM how it feels to be the dominant player in mainframes. Or any other dominant player in a very empty market. It’s lonely and boring. And boring is the exact opposite of what investors want today. Mainframes and legacy computing may be the only thing keeping IBM running right now. And given that Broadcom’s proposed purchase of Qualcomm was blocked a few years ago you can see that Broadcom is likely at the limit of what they’re going to be able to do with chipsets.

Given the explosion of devices out there you’d think that a chip manufacturer would want to double and triple down on development, right? Especially given the ongoing chip shortage. However, you can only iterate on those chips so many times. There’s only so much you can squeeze before you run out of juice. Ask Intel and AMD. Or, better yet, see how they’ve acquired companies to diversify into things like FPGAs and ARM-based DPUs. They realize that CPUs alone aren’t going to drive growth. There have to be product lines that will keep the investor cash flowing in. And that doesn’t come from slow and steady business.

Exciting and New

VMware represents a huge potential business arena for Broadcom. They get to jump into the data center with both feet and drive hybrid cloud deployments. They can be a leader in the on-prem software market overnight with this purchase. Cloud migrations take time. Software needs to be refactored. And that means running it in your data center for a while until you can make it work in the cloud. You could even have software that is never migrated for technical or policy-based reasons.

However, that very issue is going to cause problems for VMware and Broadcom. Is there a growth market in the data center in an enterprise? Do you see companies adding new applications and resources to their existing enterprise data centers? Or do you see them migrating to the cloud first? Do you imagine given the choice between building more compute cluster in the existing hybrid data center or developing for the cloud the first time that companies are going to choose the former?

To me, the quandary of VMware isn’t that different from the one faced by IBM. Yes, you can develop new applications to run on mainframes or on-prem data centers. But you can also not do that too. Which means you have to persuade people to use your technology. Maybe it’s for ease-of-management for existing operations teams. Could be an existing relationship that allows you to execute faster. But no matter what choice you make you’re incurring some form of technical debt when you choose to use existing technology to do something that could also be accomplished with new ideas.

Know who else hates the idea of technical debt and slow steady growth? That’s right, investors. They want flashy year-over-year numbers every quarter to prove they’re right. They want to see that stock price climb so they can eventually sell it and invest in some other growth market. Gone are the days when people were proud to own a bit of company and see it prosper over time. Instead, investors have a vision that lasts about 90 days and is entirely focused on the bottom line. If you aren’t delivering growth you don’t have value. It’s not even about making money any more. You have to make more all the time.

The Broad Elephant

The two biggest shareholders of VMware would love to see it purchased for a ton of money. Given the current valuation north of $40 billion, Dell and Silver Lake would profit handsomely from a huge acquisition. That could be used to pay down even more debt and expand the market for Dell solutions. So they’re going to back it if the numbers look good.

The other side of this equation is the rest of the market that thinks Broadcom’s acquisition is a terrible idea. Twitter is filled with analysts and industry experts talking about how terrible this would be for VMware customers. Given that Symantec and CA haven’t really been making news recently would tend to lend credence to that assessment.

The elephant in the room is what happens when customers don’t want VMware to sell? Sure, if VMware is allowed to operate as an independent entity like it was during the EMC Federation days things are good. They’ll continue to offer support and make happy customers. However, there is always the chance something will change down the road and force the status quo to change. And that’s the thing no one wants to talk about. Does VMware reject a very good offer in favor of autonomy? They just got out from under the relationship with Dell Technologies that was odd to say the least. Do they really want to get snapped up right away?

Tom’s Take

My read on this is simple but likely too simple. Broadcom is going to make a big offer based on stock price so they can leverage equity. The market has already responded favorably to the rumors. Dell and Silver Lake will back the offer because they like the cash to change their leverage situation. Ultimately, regulators will step in and decide the deal. I’m betting the regulators will say “no” like they did with Qualcomm. When the numbers are this big there are lots of eyeballs on the deal.

Ultimately Broadcom may want VMware and the biggest partners may be on board with it. But I think we’re going to see it fall apart because the approvals will either take too long and the stock price will fall enough to make it no longer worth it or the regulators will just veto the deal outright. Either way we’re going to be analyzing this for months to come.

Quality To Be Named Later

Posted on by
1

programming

First off, go watch this excellent video from Ken Duda of Arista at Networking Field Day 28. It’s the second time he’s knocked it out of the park when it comes to talking about code quality:

One of the things that Ken brings up in this video that I thought would be good to cover in a bit more depth is the idea of what happens to the culture of your organization, specifically code quality, when you acquire a new company. Every team goes through stages of development from formation through disagreement and finally to success and performance. One of the factors that can cause a high-performing team to regress back to a state of challenges is adding new team members to the group.

Let’s apply this lesson to your existing code infrastructure. Let’s say you’ve spent a lot of time building the best organization that has figured out and your dev teams are running like a well-oiled machine. You’re pushing out updates left and right and your users are happy. Then, you buy a company to get a new feature or add some new blood to the team. What happens when that new team comes on-board? Are they going to integrate into what you’ve been doing all this time? Do they have their own method for doing development? Are they even using the same tools that you have used? How much upheaval are you in for?

Buying Your Way To Consistency

Over a decade ago, United Airlines bought Continental Airlines. Two years later, the companies finally merged their ticketing systems. Well, merged might be a bit of a stretch. United effectively moved all their reservations to the Continental system and named the whole thing United. There are always challenges with these kinds of integrations but one might think that part of the reason for the acquisition was to move to a more modern reservation system.

United’s system was called Apollo and built in the 1970s. How could they move to a more modern system? Was the reason for the huge purchase of another airline directly related to their desire to adopt a newer, more flexible reservation system? There have certainly been suggestions of that for a number of years. But, more importantly, they also saw the challenges faced by one of their Star Alliance partner US Airways in 2007 when they tried a different approach to merging booking systems. The two radically different code bases clashed and created issues. And that’s for something as simple as an airline reservation system!

In the modern day we have much more control over the way that code is developed. We know the process behind what we do and what we write. When we build something we control it the entire way. However, that is true of everyone that writes code. And even with a large number of “best practices” out there no two developers are going to approach the problem the same way unless they work for the same company. So when you bring someone on board to your team through acquisition you’re also bringing in their processes, procedures, and habits. You have to own what they do because now their development quirks are part of your culture.

Bracing For the Impact

There’s a lot of due diligence that happens when companies are purchased. There’s an army of accountants that pore over the books and find all the potential issues. I’d argue that any successful merger in today’s world also needs to include a complete and thorough code review as well. You need to know how their culture is going to integrate into what you’re doing. Never mind the intellectual property issues. How do they name variables? Do they call the same memory allocation routines? Do they use floats instead of integers because that’s how they were taught? What development tools do they use and can those tools adapt to your workflow?

It may sound like I’m being a bit pedantic when I talk about variable naming being a potential issue but when it comes to code that is not the case. You’re going to have to train someone in procedure and you need to know who that is before they start committing code to your codebase. Those little differences are going to create bugs. Those bugs are going to creep into what you’re working on and create even more problems. Pretty soon something as simple as trying to translate from one IDE to another is going to create a code quality problem. That means your team is going to spend hours solving an issue that could have been addressed up front by figuring out how things were done in two different places. If you think that’s crazy, remember NASA lost a satellite over a unit conversion problem.

Tom’s Take

You may never find yourself in the shoes of someone like Ken Duda. He’s committed to quality software and also in charge of trying to integrate acquisitions with his existing culture. However, you can contribute to a better software culture by paying attention to how things are done. If you do things a certain way you need to document everything. You need to ensure that if someone new comes into the team that they can understand your processes quickly. That way they don’t spend needless hours troubleshooting problems that were lost in translation at the start of the process. Do the hard work up front so you aren’t calling people names later.