Saying “Yes” the Right Way

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

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

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

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

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.

Friday Thoughts on the Full Stack

It’s been a great week at Networking Field Day 28 this week with some great presentations and even better discussions outside of the room. We recorded a couple of great podcasts around some fun topics, including the Full Stack Engineer.

Some random thoughts about that here before we publish the episode of the On-Premise IT Roundtable in the coming weeks:

  • Why do you need a full stack person in IT? Isn’t the point to have people that are specialized?
  • Why does no one tell the developers they need to get IT skills? Why is it more important for the infrastructure team to learn how to code?
  • We see full stack doctors, which are general practitioners. Why are there no full stack lawyers or full stack accountants?
  • If the point of having a full stack understanding is about growing non-tech skills why not just say that instead?
  • There’s value in having someone that knows a little bit about everything but not too much. But that value is in having them in a supervisor role instead of an operations or engineering role. Do you want the full stack doctor doing brain surgery? or do you want him to refer you to a brain surgeon?

Tom’s Take

Note that I don’t have all the answers and there are people that are a lot smarter than me out there that have talked a lot about the full stack engineering issue. My biggest fear is that this is going to become another buzzword just like 10x engineer that carries a lot of stigma about being less than useful while being a know-it-all. When the episode of the podcast comes out perhaps it will generate some good discussion on how we should be handling it.

Ease of Use or Ease of Repair

HammerAndSaw

Have you tried to repair a mobile device recently? Like an iPad or an MacBook? The odds are good you’ve never even tried to take one apart, let alone put in replacement parts. Devices like these are notorious to try and repair because they aren’t designed to be fixed by a normal person.

I’ve recently wondered why it’s so hard to repair things like this. I can recall opening up my old Tandy Sensation computer to add a Sound Blaster card and some more RAM back in the 90s but there’s no way I could do that today, even if the devices were designed to allow that to happen. In my thinking, I realized why that might be.

Build to Rebuild

When you look at the way that car engine bays were designed in the 80s and 90s you might be surprised to see lots of wasted space. There’s room to practically crawl in beside the engine and take a nap. Why is that? Why waste all that space? Well, if you’re a mechanic that wants to get up close and personal with some part of the engine you want all the space you can find. You’d rather waste a little space and not have busted knuckles.

A modern engine isn’t designed to be repaired by amateurs. The engine may be sideways or have replaceable parts put in places that aren’t easily accessed without specialized equipment. The idea is that professionals would have everything they need to remove the engine if necessary. Moreover, by making it harder for amateurs to try and fix the issues you’re are preventing them from doing something potentially problematic that you’ll have to fix later.

The same kind of thing applies to computing equipment. Whereas before you could open the case of a computer and try to fix the issues inside with a reasonable level of IT or electrical engineering knowledge you now find yourself faced with a compact device that needs specialized tools to open and even more specialized knowledge to fix. The average electrical engineer is going to have a hard time understanding the modern system-on-a-chip (SoC) designs when you disassemble your phone.

Usability Over Uniqueness

The question of usability is always going to come into play when you talk about devices. The original IBM PC was a usable design for the time it was built compared to mainframes. The iPhone is a usable design for the time when it was built as well. But compared to each other, which is the more usable design today?

Increasing usability often comes at the cost of flexibility. I was talking to someone at a fabrication lab about printer drivers for a laser etching machine. He said that installing the drivers for the device on Windows is easy but almost impossible on a Mac. I chuckled because the difficulty of installing a non-standard printer on a Mac is part of the reason why it’s easy to use for other kinds of printers. The printing subsystem traded usability with things like Bonjour printer installation over flexibility, like installing strange printers on a laptop.

Those trade offs extend into the hardware. Anyone that worked on PCs prior to Windows 95 knows all about fun things like IRQ conflicts, DIP switch settings for COM port addresses, and even more esoteric problems. We managed to get rid of those in the modern computing era but along with that went the ability to customize the device. You no longer have to do the dance of finding an available IRQ but you also can’t install a device that would conflict with another through hardware trickery.

By creating devices for the average user focused on usability you have to sacrifice the flexibility that makes them easier to fix. If you knew you were constantly going to need to be tweaking the jets on a carburetor you’d make it easy to access, right? But if a modern fuel injection system never needs to be adjusted except by a specialized professional why would you make it accessible to anyone that doesn’t have tools? You can see this in systems that use proprietary screws to keep users out of the system or glue parts together to prevent easy access.


Tom’s Take

I miss the ability to open up my laptop and fix issues with the add-in cards. The tinkerer in me likes to learn about how a system works. But I don’t miss the necessity to go in and do it. The usability of a system that “just works” is way more useful to me. It reminds me of my dad in some ways. He may have loved the ability to open up the engine and play with the carburetor but he also had to do it frequently to make things “work right”. In some ways, removing our ability to repair things in the IT space has forced manufacturers to build devices that don’t need to be frequently repaired. It’s not the optimal solution for sure, but the trade off it more than worth it in my mind.

In Defense of Subscriptions

It’s not hard to see the world has moved away from discrete software releases to a model that favors recurring periodic revenue. Gone are the days of a bi-yearly office suite offering or a tentpole version of an operating system that might gain some features down the road. Instead we now pay a yearly fee to use the program or application and in return we get lots of new things on a somewhat stilted cadence.

There are a lot of things to decry about software subscription models. I’m not a huge fan of the way that popular features are put behind subscription tiers that practically force you to buy the highest, most expensive one because of one or two things you need that can only be found there. It’s a callback to the way that cable companies put their most popular channels together in separate packages to raise the amount you’re paying per month.

I’m also not a fan of the way that the subscription model is a huge driver for profits for investors. If your favorite software program doesn’t have a subscription model just yet you’d better hope they never take a big investment. Because those investors are hungry for profit. Profit that is easier to see on a monthly basis because people are paying a fee for the software monthly instead of having big numbers pop up every couple of years.

However, this post is about the positive aspects of software subscriptions. So let’s talk about a couple of them.

Feature Creatures

If you’ve ever complained that an application or a platform doesn’t have a feature that you really want to see you know that no software is perfect. Developers either put in the features they think you want to see or they wait for you to ask for them and then race to include them in the next release. This push-pull model dominates the way that traditional software has been written.

How do those features get added to software? They do have to be written and tested and validated before they’re published. That takes time and resources. You need a team to add the code and tools to test it. You need time to make it all work properly. In other words, a price must be paid to make it happen. In a large organization, adding those features can be done if there is sufficient proof that adding them will recoup the costs or increase sales, therefore justifying their inclusion.

How about if no one wants to pay? You don’t have to look far for this one. Most of the comments on a walled garden app store are constantly talking about how “this app would be great if it had this feature” or “needs to do “X” then it’s perfect!” but no one wants to pay to have those features developed. If the developer is already charging a minimum for the app or giving it away in hope of making up the difference through ad revenue or something, how can we hope to encourage them to write the feature we want if we’re not willing to pay for it?

This is also the reason why you’re seeing more features being released for software outside of what you might consider a regular schedule. Instead of waiting for a big version release to pack in lots of new features in the hopes of getting customers to pay for the upgrade developers are taking a different approach. They’re adding features as they are finished to show people the value of having the subscription. This is similar to the model of releasing the new episodes of a series on a streaming service weekly instead of all at once. You get people subscribed for longer periods instead of doing it only long enough to get the feature they’re looking for. Note that this doesn’t cover licensing that you must hold to use the feature.

Respect for the Classics

One other side effect of subscription licensing is support for older hardware. You may think this sounds counterintuitive. However, the likelihood that an older model of hardware is going to be supported later in life is due to the fact that there is no longer a need to force upgrades to justify hardware development.

Yes, there are always going to be releases that don’t support older hardware. If it’s something that needs to use a new chip or a new hardware feature it’s going to be very difficult to export that back to a platform that doesn’t have the hardware and never will. It’s also harder to code the feature in such as way as to run hardware that has varying degrees of support and implementation capabilities. The fact that an iPhone 7 and an iPhone 13 can run the same version of iOS is a huge example of this.

More to the point, the driver to force hardware upgrades is less impactful. If you’re writing a new app or new piece of software it’s tempting to make the new features run only on the latest version of the hardware. That practically forces the users to upgrade to take advantage of the new kit and new apps. It feels disingenuous because the old hardware may still have had a few more years of life in it.

Another factor here is that the added revenue from the subscription model allows developers to essentially “pay” to support those older platforms. If you’re getting money from customers to support the software you have the resources you need to port it to older version as well as continuing to support those older platforms with things like security updates. You may not get your favorite switch supported for a decade now but you also don’t have to feel like you’re being forced to upgrade every three years either.


Tom’s Take

I go back and forth with subscription models. Some tools and platforms need them. Those are the ones that I use every day and make lots of sense to me to keep up with. Others feel like they’re using the lure of more frequent feature releases to rope users into paying for things and making it difficult to leave. When you couple that with the drive of investors to have regular recurring revenue it puts companies into a tough spot. You need resources to build things and you need regular revenue to have resources. You can’t just hope that what you’re going to release is going to be popular and worry about the rest later. I don’t know that our current glut of subscription models is the answer to all our issues. However, it’s not the most evil thing out there.

No Is A Complete Sentence

Has someone asked you to do something recently that you know you don’t have time to do but felt like you needed to do anyway? Or has someone tried to get you to help with something and impressed upon you just how important it is? You probably told them “yes” out of guilt or obligation or some other kind of negative emotion. Sure, you could have declined but you thought about how bad you would feel if someone did the same to you.

Let me tell you clearly. “No” is a complete sentence. It requires no explanation or defense. It is the only thing you need to say when you know you won’t be able to do something no matter how much the other party tries to get you to agree.

Everything Sucking Equally

If you know anything about QoS, you know that once a given circuit reaches the limitation for bandwidth you can no longer send additional information. What’s counterintuitive about this is most people would assume that if you try to squeeze one more stream or packet into the mix that only that last packet would be affected and everything else would work perfectly fine, right? Only one of the many would suck.

Sadly, all of the packets or flows on the circuit are affected in this situation. Adding just one more thing to the mix means all things are affected because the system has to process the problems all at once. You suffer everywhere because the interface couldn’t say “no” to that last packet.

In fact, the whole mantra behind QoS is prioritizing information before it hits a given interface because the interface is just going to send whatever it is given. Those packets will queue up or eventually be dropped if they can’t be processed. Likewise, if you are trying to do too many things at once you will eventually miss something important and make a mistake because you couldn’t handle everything at once. You need to be able to prioritize all the things that are going on and know when you hit a limit you can’t get past.

Where the challenge comes into play is when others try to add more to the interface without knowing you’re at maximum capacity. It’s easy for someone to ask you to do just one more little thing. In their minds it’s not a huge ask, right? In your mind you’ve already begun trying to juggle all the things that need to be changed to make this one little thing work with all the other things you’ve spent so much time prioritizing. Unfortunately, it’s too easy to just say “yes” to avoid uncomfortable conversations and try to fix the problems as they come up rather than turning away something you know would put you over your limit.

Taking No For an Answer

It’s easy to tell people to say “no”, right? I mean it is possibly the shortest sentence in the English language. However, it’s not the person saying it that usually has an issue. The people doing the asking are the ones that almost invariably are the ones trying to convince, cajole, or outright impress upon the person how critical it is that whatever this is get done in addition to all the other things that are going on.

For those that are asking the question and expecting a positive answer, let me ask you a question of my own: Why does this person need to do the task? There usually are very good reasons for it. Perhaps it’s something this person specializes in. Maybe it’s something that only they have knowledge about. It could perhaps even be their job responsibility to get it done. But the next question you need to ask is even more important.

If they must do this task, what can I do to help them?

The calling card of bad management types is to show up, assign a bunch of tasks that only other people should do, and then fly away to measure their productivity and comment on how nothing seems to be getting done. Instead, management should be asking how they can help. Is this something that someone else could do? Do you have the bandwidth to do the task? Is there another task on your plate that I can do for you that would help you to take care of this?

People are often very fully tasked with all the things they have to take care of. Thinking that you can sneak one more thing onto their schedule without impacting all of it smacks of hubris. What if someone started adding tasks to your plate instead? I doubt you’d like that. Even if you said no, what if it was the CEO or the Chairman of the Board telling you that you had to do it? You’d probably be just as upset, especially if it was a task you couldn’t delegate.

For the people out there like me, try this next time someone asks you to do something and you’re fully tasked or unable to clear enough to accomplish it. Say “no”. Don’t explain. Don’t justify. Don’t defend. Just. Say. No. Watch the other person’s reaction. Are they getting frustrated because you’re not saying anything? Are they coming back in a helpful manner trying to understand why you declined? Or are they more upset that they now have to go find someone else to do it instead? If they come to you with respect and understanding you can tell them why you declined and are unable to help. They may offer suggestions or try to find a way to make it work. The ones that get upset are usually the ones that wouldn’t have taken “no” for an answer no matter what. They are the ones you don’t need to waste your breath on.


Tom’s Take

I will admit this post is as much for me as it is for others. I am the world’s worst for taking on additional things when I know I don’t have the bandwidth to do it all. I don’t like to disappoint. I really want to keep people happy. And instead I end up failing because I overestimate my ability to get work done and underestimate how much others could do if they knew I needed help. Next time you need to tell someone you can’t do something, don’t spend a ton of effort figuring out how to counter their eventual arguments. Just say “no” and move on. If it’s important or something that only you can do they will find a way to make it work. Otherwise, you will have saved so much more effort because you used a complete sentence instead of a needless paragraph.

AI is a Promotion

When I worked at IBM as an intern, part of my job was writing a deployment script to help make our lives easier when installing new ThinkPads. In order to change an MTU setting on the token ring PCMCIA cards (long story), I had to write a script that iterated through all the possible combinations of adapters in the registry to find the one I was looking for and change the value.

Now, I was 22 at the time and green behind the ears, especially when it came to programming. I finally figured out that the most efficient way to do this in the language that I was using was a very deep nested if statement. It wasn’t my best work but it operated properly. I mentioned this to my mentors on my team with a remark of how hard it was to understand the logic at first. My comment was “You know, if it’s hard to read for anyone else then I never have to worry about gettin fired.”

To which the response was, “Yes, but you can never be promoted either.”

That sage wisdom brings me to the modern world and how AI can fix that issue.

Eternal Support

One of the first things you learn in IT is not to volunteer. If you know how to implement a technology or troubleshoot a specific issue then you become the go-to person for that problem. If you add a skill to the team like debugging Rust or configuring voice mail dial peers then you are the new owner for that particular skill.

This becomes annoying when you finally move past that skillset and you’re on to new and better things. If you are the person that knows how to extend database schemas or change auto attendant functions you are always going to be called upon to do those things. Rather than moving on to new challenges you will be called back to work on the things that no one else bothered to learn or couldn’t pawn off on someone else.

When you think about it, that’s part of the reason why so many entry-level positions start with some basics like VLAN programming or LUN configuration. Sure, you’re learning the basics and understanding how systems operate. But you’re also repeating the things that the junior person before you did. Why? Because they now have someone to do that work for them. And when the new person gets hired as a junior-level technician, you’re going to pass along those tasks to someone so they can learn and so you can move on. It’s the Circle of IT Life.

The reinforcement of knowledge is only so important to the organization. Yes, you need someone to keep the lights on and do the tasks regarded as menial by the senior teams. However, miring people in those tasks makes them feel undervalued after a while because no one wants to take them on. And, as above, if it’s something that no one else can be bothered to learn or take over you’re going to be stuck doing it until you leave or until the system in question is eventually replaced. And even then you’ll probably be asked to learn how to do the new thing because “this is your system”.

Learning, Not Thinking

The reason why I’m excited for applied AI in infrastructure and operations is because it will learn these menial tasks and do them as instructed every time without complaint or mistake. Yes, that means you need to train the algorithm correctly. Yes, that means you need to be on the lookout for changes and update accordingly when hardware changes or when procedure changes. Given those constraints AI will work for you, not against you.

When you move on to a new role you expect to face new challenges. If you move from a junior role to a senior role you want to work on harder things or solve new problems. You don’t want to get a new title with the same old work. If you change teams you want to experience new systems and implement new technology. You don’t want to be the cloud person that still deploys campus switches in wiring closets.

In a way, having AI take over the basic tasks of your job functions doesn’t remove your job. It promotes you to a new role. It could be that the first promotion is running the system that you implemented to do the work. A “train the trainer” kind of role, if you will. As soon as you can ensure that it is working correctly and that the rest of the team is aware of how to keep the engine running you can decide where you want to go next. You essentially have the freedom to learn and do and not have to be concerned about going back to doing the old things.

Is AI the Enemy?

AI doesn’t take away jobs. It takes away tasks. It streamlines processes and provides consistent, repeatable outcomes. If your job is a collection of tasks that need to be done then it is worth asking why it’s so easy for it to be replaced by an AI system. I’ve said on a number of occasions that there will always been room for jobs that AI can’t do, such as those that involve physical labor, as well as advanced thinking and creative problem solving.

Where AI does succeed is in the repeatable task department. If a role is comprised of repeatable tasks then the question becomes “why does this role exist?” If an algorithm can determine the best way to implement VLANs or offload clients to other devices then the job that was doing those roles needs to be examined. Can that person be encourage to do something else for the company? Can that role be reduced and given to someone with less experience? If those questions make you or someone on your team bristle, is that the fault of the AI? Or the fact of the job being less than ideal for the business?


Tom’s Take

AI can take away some of the unimportant and forgettable parts of your job and give you the freedom to do things that are more important to the business, possibly in a different role. Isn’t that the textbook definition of a promotion? Change makes people uncomfortable. It makes sense that no one wants to have their job taken away. But if you ask anyone in IT right now if they could get rid of 10-20% of the tasks in their job that they don’t like to do they’d agree in a heartbeat. AI isn’t going to remove your job. It’s going to give you the freedom to do something different. It’s also going to ensure you don’t have to keep getting called back to do that thing over and over again because no one else wants to learn it. I think it’s time we let new technologies like AI give everyone on the team the promotion they deserve.