Author Archives: networkingnerd

Unknown's avatar

About networkingnerd

Tom Hollingsworth, CCIE #29213, is a former network engineer and current organizer for Tech Field Day. Tom has been in the IT industry since 2002, and has been a nerd since he first drew breath.

Why Aren’t There More Technical MBAs?

Posted on by
4

This weekend I was listening to the latest episode of the Art of Network Engineering podcast featuring Russ White. Russ is one of those guests that has a breadth of knowledge outside of technology that colors the way he looks at things in the realm of enterprise IT. Plus he’s a fun interview.

One of the questions he asked was around the idea of technical MBAs. For those that might not know, MBA stands for Masters of Business Administration, which is a post-graduate college business degree. An MBA is widely regarded as a way to put yourself on a track to be a manager for a company in some capacity. An MBA is punching a ticket to be a future CEO. Why does it seem like the number of MBAs coming out of prestigious business schools don’t have a technical background then?

Where the Action Is

I’m going to quote liberally from a book I’ve been reading called The Personal MBA by Josh Kaufman. In it, Kaufman lays out the reasoning behind using his book to study the principles behind the information given in MBA classes instead of spending $200,000 to go to a business school for two years for the same material. The layout of the first few sections gives a great overview of the way that most people think about MBAs as well as how most MBAs view the business world.

The original reason to get an MBA was to apply scientific reasoning to management. The goal was to have managers for factories that looked at the numbers and made sound decisions based on facts and not hunches. In theory that was a great way to get started. However, the numbers started to change in favor of a newer, more exciting way to apply numbers. Instead of crunching them to make people more productive, MBAs started moving toward ways to apply that analysis to make the company rich.

In the past 50 years the number of business school graduates going into finance and consulting has exploded. Per Kaufman, something like 60% of the people getting MBAs have moved toward finance as their preferred area of management. When you think about it that makes all the sense in the world. Finance is where a company can get bigger and more profitable. Value creation can be heavily impacted by workers that are looking to invest profits and reduce costs across the board to increase return to investors. Likewise, investors more heavily reward managers that make them money. This feedback loop means the easiest way to pay off your MBA debt is to go into finance and make the company rich.

On the flip side of the discussion, do you think of value creation when you think of IT? I can remember way back in college when getting my BBA in MIS and being taught that I was going to be spending a lot of my time convincing management that IT departments were not just cost centers. Sales generates revenue. Marketing supports sales. Accounting makes sure we’re actually making money. IT? Well, we ask for stuff and then install it and then fix it when it breaks. We don’t actually do anything to make money.

I know a lot of my readers are probably shouting at their screens right now talking about how IT supports the business and enables the value creation that other parts of the organization do. You’d be absolutely right in your assertion. However, the stigma that IT has is that we take money and don’t give any back to the organization directly. Kind of like how plumbers and electricians are still seen as “dirty” or “low brow” kinds of jobs. Despite evidence the contrary IT is drag on the whole organization. IT doesn’t do the hard work of making money through emails or apps or ensuring databases are up and running to search through for customer leads.

Given that IT is a cost center and the real rock stars all go to finance to keep the shareholders and investors happy is it any wonder that MBAs want to work on spreadsheets instead of Excel? If you had a choice between limiting your career trajectory while also having a lot of business school debt to pay off would you do it knowing tech is a much more exciting role? The question pretty much answers itself.

Promote From Within

Let’s look at the second major reason that MBAs are always technical disciplines. Who is in charge of your IT department now? Is it an MBA? Is it a manager that came from accounting or sales? Or is it someone technical that got promoted a few times and now finds themselves in charge of all the IT teams? Does that manager have a formal background in management or a degree? Or do they learn the ropes as they go and feel a bit rough around the edges?

In many IT organizations that I’ve worked with and worked for the management in those areas tends to be promoted from the bottom up. Instead of a more formalized structure of managers trained to be managers and hired into the organization to manage, IT is more about enabling intelligent and qualified individuals to maintain the department. You see far more people with advanced technical certifications or years and decades of technical experience working to keep the lights on as opposed to the lessons of quantitative analytics from business school being applied to streamline operations.

Admit it. You’d rather work for someone who knew the tech as opposed to someone that had been trained to be a manager right? Is there anything worse than walking into a meeting with the head of the IT department knowing that they won’t understand the challenges of a new hardware installation or implementing a new protocol that could impact operations? The nerve of those people! If they would just get someone technical in that seat that you could talk to things would be different for sure. This place might even run right for once!

The fact is that most technical professionals prefer someone that understands them over someone that is good at managing others. They would rather spend time talking to a promoted tech resource that understands the differences between SSL and TLS instead of someone that was trained in how to go to management and ask for more budget this quarter. We’re more comfortable with people that understand the things we do. It’s the same in accounting and finance and sales. We want to be managed by people that know how to deal with our special areas of expertise.

Extend that to the business school. MBAs go into finance so most finance people are managed by MBAs. IT is managed by people that worked in IT, which is more focused on certification and practical knowledge rather than formal learning in universities. The divide grows each time a new class of business school graduates starts applying for roles in a company. Would you take an interview with a cost center department full of people that automatically don’t like you because they think you don’t know the difference between a switch as an access point? Or would you rather talk to people that “get” you in the finance department?

There have been attempts to bridge this gap. In the above episode AJ Murray mentioned a hybrid degree that offered training in IT and in business. I too looked at the possibility of obtaining an MBA and a MS in MIS from my graduate school. As mentioned by AJ that major was the least popular option at his school and it didn’t last too long at mine either. That’s because the amount of work that you have to do for both degrees is far above what you’d have to do in order to get just the MBA. And there isn’t a lot of crossover either. You could be in a quantitive analysis class for finance on Monday and writing Python code on Tuesday for a program that was due at the end of the semester. It just doesn’t make sense when most of the candidates would prefer one over the other.

Tom’s Take

Russ wondered why there aren’t more people with a technical background getting an MBA. My answer is that the ones with a technical background don’t want it and the ones that want it don’t want to deal with tech. Management doesn’t care if you can manage a team of high-performing nerds to streamline operations for the business. They do care if you can cut costs and use financial wizardry to make the company more profitable. Why do you think so many people who are CEOs are former CFOs and not former CTOs or CIOs? The MBA is a degree to teach people to manage and the roots of it go back much further than enterprise IT as a discipline. As much as we might hate to admit, MBAs are focused on the business, not the departments. And as long as the road to the CEO’s chair involves making money for the shareholders you won’t see many technical people in that chair any time soon.

Multicasting Content in the Twilight of Social Media

Posted on by
1

During Cisco Live EMEA last week I had an interesting conversation with a few people at the show around social media and how the usage of the platforms appears to be changing thanks to decisions made by the smartest people in a given broom closet. With the acceleration of the demise of Twitter as a platform I couldn’t help but comment on the fact that social media is becoming less about conversation and more about broadcast, which seemed to catch some of the people in the conversation off guard.

Back and Forth

Ever since the beginning of my time on Twitter, I’ve seen the platform as conversational instead of content-focused. Perhaps that’s the reason why the idea of a tweet storm has irritated me so much over the past few years. Twitter is about talking to people. It’s about interacting with them and creating a conversation in the noise. Twitter allows us to connect to people and exchange ideas and viewpoints.

Contrast that with other platforms in the social media spectrum. Specifically I’m thinking of Youtube video or TikTok videos. These platforms are designed to create content and send it to a number of people to view. It’s multicasting content to viewers. You don’t interact with people on a one-on-one basis. If Twitter is about the conversation then video platforms are all about the message. Sit here, listen to what I have to say, and don’t talk back.

You may already be thinking to yourself, “But what about the comments!” And you might even be right. However, comments aren’t conversation. They’re a way to add your own viewpoint to a message that isn’t necessarily seen by someone consuming the content. Case in point? Youtube has started hiding the comments behind a widget that you need to click on. TikTok puts the comments behind a button. You can’t see them unless you go looking for them. And most of the time you don’t even want to read them anyway. I mean, Don’t Read the Comments is pretty much a meme at this point, right?

Comments aren’t conversation. Why would you think they are? Because your voice gets added to the mix? Because you get to say what you think? Is anyone even listening? How many times does a conversation or reply chain in the comments on a video involve the creator aside from answering a specific question? How often do the comments turn into a disaster area of people arguing about things not even related to the topic of the content in the first place? Comment hijacking is more common than most people realize. For some platforms it may be the only reason comments exist.

Another important point about comment sections turning into cesspools comes from the lack of interaction with the content creator. A real conversation, like one that happens in person, allows for the expression of viewpoints and discussion of ideas. You don’t have to agree but you do have to listen. And you do have to follow rules for conversation. You don’t get to walk up to someone who expresses an idea and say “You’re wrong and I’m right and here’s why” without also having to listen to the other person’s viewpoint. Well, I mean you probably could but you’ll find yourself excluded from the conversation quickly because you’re not listening. You’re just broadcasting.

Blogs as a Medium

Note that blogs and blogging fall into the same category as the videos above. I write the things I think and you read them. You can think about it or comment about what you believe. I will read it (and I do read them) but I can choose not to reply. The comment section on my NAT66 posts are still going strong something like ten years later and I haven’t left a comment on that video in forever. I’ve said what I wanted to say on the matter and that’s that.

However, blogs differ from videos in one important aspect as far as I’m concerned. The text of the blog post is searchable, as are the comments. You can look for topics or ideas much more easily in written form than you can on video. TikTok especially prefers brevity over conversation. Sure, maybe you highlight and comment and make a new video about what you read but there’s no transaction there. You could spend hours with a conversation that takes about two minutes to have in person. All this happens in a vacuum because you can’t search for the conversation. You can only watch it play out.

Yes, that’s how conversations happen in real life too. Even now I’m recalling parts of what I said to people in the conversation that I had. I’m recalling the discussion that happened and what I said. The key difference here is that I’m writing it down for others to read later and add their own viewpoints. If you choose to share this post with your audience and have your own viewpoint you’re creating conversation with others. That’s a big difference in my mind. How many times have you sent a video to someone to start a conversation? Aside from “this looks pretty cool” or “did you know about this” or “this was funny”?

Tom’s Take

The twilight of Twitter and text-based social media is upon us. The future right now is wrapped up in video content because that’s what people are consuming. Look at how many platforms have added “features” to replicate what the hottest apps are doing right now? There’s still value in the conversation to me. I still feel that we are better off having the discussions and not just blindly consuming content in multicast format. But I’m also old. I love writing. I feel I can get my ideas across in a better way here and on conversational platforms. I relish the idea of back-and-forth over broadcast. But the waning light tells me that my way isn’t long for this world.

Monitoring Other People’s Problems

Posted on by
Reply

It’s Always the Network is a refrain that causes operations teams to shudder. No matter what your flavor of networking might be it’s always your fault. Even if the actual problem is DNS, a global BGP outage, or even some issue with the SaaS provider. Why do we always get blamed? And how can you prevent this from happening to you?

User Utopia

Users don’t know about the world outside of their devices. As soon as they click on something in a browser window they expect it to work. It’s a lot like ordering a package and having it delivered. It’s expected that the package arrives. You don’t concern yourself with the details of how it needs to be shipped, what routes it will take, and how factors that exist half a world away could cause disruptions to your schedule at home.

The network is the same to the users. If something doesn’t work with a website or a remote application it must be the “network” that is at fault. Because your users believe that everything not inside of their computer is the network. Networking is the way that stuff happens everywhere else. As professionals we know the differences between the LAN, the WAN, the cloud, and all points in between. However your users do not.

Have you heard about MTTI? It’s a humorous metric that we like to quote now that stands for “mean time to innocence”. Essentially we’re saying that we’re racing to find out why it’s not our problem. We check the connections, look at the services in our network, and then confidently explain to the user that someone else is at fault for what happened and we can’t fix that. Sounds great in theory, right?

Would you proudly proclaim that it’s someone else’s fault to the CEO? The Board of Directors? How about to the President of the US? Depending on how important the person you are speaking to might be you might change the way you present the information. Regular users might get “sorry, not my fault” but the CEO could get “here’s the issue and we need to open a ticket to fix it”. Why the varying service levels? Is it because regular users aren’t as important as the head of the company? Or is it because we don’t want to put in the extra effort for a knowledge workers that we would gladly do for the person that in ultimately going to approve a raise for us if we do extra work? Do you see the fallacy here?

Keeping Your Eyes Peeled

The answer, of course, is that every user at least deserves an explanation of where the problem is. You might be bent on justifying that it’s not in your network so you don’t have to do any more work but you also did enough work to place the blame outside of your area of control. Why not go one step further? You could check a dashboard for services on a cloud provider to see if they’re degraded. Or do a quick scan of news sites or social media to see if it’s a more widespread issue. Even checking a service to see if the site is down for more than just you is more information than just “not my problem”.

The habit of monitoring other services allows you to do two things very quickly. First is that it lowers the all-important MTTI metric. If you can quickly scan the likely culprits for outages you can then say with certainty that it’s out of your control. However, the biggest benefit to monitoring services outside of your organization that you rely on is that you’ll have forewarning for issues in your own organization. If your users come to you and say that they can’t get to Microsoft 365 and you already know that’s because they messed up a WAN router configuration you’ll head off needless blame. You’ll also know where to look next time to understand challenges.

If you’re already monitoring the infrastructure in your organization it only makes sense to monitor the infrastructure that your users need outside of it. Maybe you can’t get AWS to send you the SNMP strings you need to watch all their internal switches but you can easily pull information from their publicly available sources to help determine where the issues might lie. That helps you in the same way that monitoring switch ports in your organization helps you today. You can respond to issues before they get reported so you have a clear picture of what the impact will be.

Tom’s Take

When I worked for a VAR one of my biggest pet peeves was “not my problem” thinking. Yes, it may not be YOUR problem but it is still A problem for the user. Rather than trying to shift the blame let’s put our heads together to investigate where the problem lies and create a fix or a workaround for it. Because the user doesn’t care who is to blame. They just want the issue resolved. And resolution doesn’t come from passing the buck.

Being the Best at Beginning

Posted on by
Reply

The other day I was listening to an excellent episode of The Art of Network Engineering talking about technical marketing engineers (TME). The discussion was excellent and there was one line from Pete Lumbis in the episode that stuck with me. He said that one of the things that makes you good as a TME is being an “expert beginner”. That phrase resonates at lot with me.

Fresh Eyes on the Problem

I talked a bit about this last year when I talked about being a beginner and how exciting that it was to start over with something. As I compared that post to the AONE episode I realized that what Pete was talking about was a shift in mindset that gives you the energy and focus to pick things up quickly.

You may have heard the phrase “familiarity breeds contempt”. It’s a common phrase used to describe how we feel less impressed with things the more we learn about then. Our brains are wired to enjoy new things. We love new experiences, going to new places, or even meeting new people. The excitement and rush that we get from something unfamiliar causes our brain to devour things. It’s only once we become familiar with them that we feel the contempt set in.

It’s not always possible to avoid the contempt part of things. Think about something as dreary as your morning commute to work, whether it’s walking down the stairs or driving to the office. I used to joke that my car was practically on auto-pilot most mornings because I knew every bump in the road and every turn by heart. When I would go somewhere new I would have to focus more on road signs or directions.

Back to Basics

The beginner aspect of things is easier to deal with. That’s because we can trick ourselves into seeing something with fresh eyes. On a number of occasions I’ve mentioned my friend and mentor John Pross and his assertion that every upgrade or deployment that happened was like the first time doing it. He never took anything for granted. He always took things step-by-step. While this had the affect of him making sure everything was followed to the letter it also gave him the beginner aspect of looking for ways to improve or discovering new solutions to problems along the way.

Once the contempt or apathy sets in you’re going to get very good at just clicking through the steps to get to the end as fast as possible. If you don’t believe me think about how many times you’ve given directions that involve something like “Just click Next, Next, Next, Next and then you’re done”. Trust me, it sounds funnier when you say it out loud. But it speaks to the fact that we know the dialog boxes so well that we know they aren’t important. But what if they are?

If you want to understand what it feels like to be a beginner again and you’re having a hard time getting yourself in that mindset you should find a beginner and coach them through a task like a setup. Don’t just tell them what to do. Let them figure it out. Answer questions as they come up. Make them explain why they’re doing something. I bet you’ll learn a lot more as you have to help them understand why that configuration line is in there or why you always choose twice the amount of RAM in an instance. Once you see the process through the eyes of a beginner you have to learn it more completely in order to help them understand it.

In some roles, like a TME or a VAR engineer, the ability to be an expert beginner is critical to your job. You have to see a technology for the first time and pick up the basics quickly. I used to tell people that the excitement of being an engineer at a VAR was the variety of problems I’d be called on to solve. One day might be wireless clients. The next could be iSCSI storage arrays. Whatever the case may be I could count on finding myself in a new situation pretty regularly. It kept things exciting and made me realize I had to stay on my toes.

For those that work as product managers or on more specialized teams you need to make sure you’re taking time to approach things as a beginner. The “same old, same old” may not actually be the same any more. That kind of contempt and familiarity leads to the phrase “the way we’ve always done it” and doesn’t force you to challenge the process to understand how to improve it. Sometimes you need to step back and remember that you have to see everything for the first time.

Tom’s Take

Beginners shouldn’t feel like they’re a nuisance. In fact they should be celebrated for the energy and focus they bring to a task or project. For roles like a TME it’s important to bring the same kind of energy to new things. You can learn a lot when you allow your brain to soak up knowledge like a fresh sponge. More importantly, the ability to be a beginner helps you refine your knowledge base more and will ensure that you can explain a concept or process to someone with absolute certainty.

Friday Networking Field Day Thoughts

Posted on by
1

I’m wrapping up Networking Field Day 30 this week and as is always the case there was a lot of great discussion from both the presenters and the delegates outside of the presentations. It’s one of the reasons why I love doing this job even after almost ten years. I get to meet fun people and have an impact on so many things in the tech industry.

  • Network-as-a-Service is coming. We recorded a roundtable discussion about it and I think the impact that it’s going to have on mid-sized businesses is massive. It’s going to be like cloud. Not just in operational capability. It’s also going to be a huge driver for what you can do with your network in support of applications. The snowflakes may melt under the weight of the cookies we make from the cookie cutter deployments.
  • It feels like a lot of companies are trying to find what’s next. Part of that is coming from the ways that organizations are changing their outlook for what an office should be after the pandemic shutdowns. But still others are realizing they can’t use the same revenue stream for the next five years and hope to survive. This isn’t simply a game of trying to find an adjacent market to move into to drive growth to keep shareholders and investors happy. This is more about finding something that needs to be done because the alternative is no longer having a company.
  • Sadly, it looks as though third party Twitter clients are gone for good. This is beyond irritating to me because of the way that I choose to consume Twitter. I’ve seen a lot of chatter in various comment threads about third parties making money from the good graces of Twitter but the fact is that those programs drive a LOT of the way that power users interact with the system. If the exodus wasn’t already accelerating I would imagine you’re going to see a lot more coming very, very soon.

Tom’s Take

Stay tuned for all the great info from Networking Field Day on the Tech Field Day YouTube channel and don’t forget to thank your networking team today. You may not need to call them today to tell them something is down but trust me they will appreciate you calling just to say you appreciate them.

Controlling Your View of the World

Posted on by
2

Straw Bales on Hill Landscape, Tuscany, Italy

As I’m writing this it looks like Twitter has made some changes to the way that third-party clients interact with service. My favorite client, Tweetbot, is locked out right now. The situation is still developing but it’s not looking pretty for anyone using anything other than the web interface. While I will definitely miss the way I use Tweetbot I think it’s the kick I needed to move away from Twitter more than before.

A Window on the World

The apps that we use to consume and create content are the way that we view things. Maybe you prefer a webpage over an app or the way that one client displays things over another but your entire view is based on those preferences. If the way you consume your media changes your outlook on it changes too.

I didn’t always use Tweetbot to view Twitter. I tried using the standard app for a long time. It wasn’t until the infamous “Dickbar” incident back in 2011 that I broke away for something that wasn’t so slavishly dependent on ads. The trending topic bar might not have been specifically for ads at the time but the writing on the wall was there. The way I chose to view my content wasn’t compatible with the way that the service wanted to monetize it.

Fast forward to today. Instagram doesn’t show you time sequence posts. Neither does Facebook. Twitter now defaults to an algorithmic timeline. Apps like TikTok are built on their algorithms. It’s all a way to show you things the system thinks you want to see with a sprinkling of ads mixed in whenever they want to show them to you. Could you imagine a TV channel where the ads were just thrown in to the show whenever they wanted you to see one as opposed to more of a standard time? You probably can imagine because that’s what it feels like to watch platforms like Youtube.

Platforms cost money to operate. That fact isn’t lost on me. What is annoying is that trying to change the way I access the platform in order to serve more ads is going to cause more damage in the long run. Given the choice between using the web version of Twitter and just not using it I’m more inclined to the latter. I want a timeline that shows me tweets in chronological order without the need to change to that format every time I open the page. I want to see what I want to see without being forced to view things that don’t interest me. Forcing me to use the web app to see ads is almost as bad as forcing me to follow people that you think are interesting that I have no desire to interact with.

The Only Winning Move

I’m more than a passive participant in services like Twitter. I create content and use them to share it. I participate actively. And I don’t like the way I’m being forced to play.

I started a Mastodon account many years ago the last time Twitter looked like it was making changes. In the past few months I’ve migrated it to a new profile. The Mastodon interface has robust apps and a great way to interact with people. It may not have the numbers that Twitter does right now but it won’t take long for a lot of the best creators to go there instead.

More importantly, choosing an open platform over a monetized nightmare gives me hope that the real value of what we do on the Internet isn’t selling ads. It’s creating valuable things that people enjoy and sharing them with a receptive audience. That may not be the millions of people on Twitter right this minute but those millions of people are about to find out what it feels like when the best reasons to be on a platform are gone.

Tom’s Take

I want to choose how I see the world, not how someone wants me to see it. I want to decide how I share what I’ve made with people and when they see it, not have it placed behind other things a software function decides are more likely to be clicked. If the future of social media is endless ads and trickery designed to make me spend more time fighting through the timeline instead of consuming it then I guess my view of the world is outdated and needs to change. But it will change on my terms.

Problem Replication or Why Do We Need to Break It Again?

Posted on by
Reply

There was a tweet the other day that posited that we don’t “need” to replicate problems to solve them. Ultimately the reason for the tweet was that a helpdesk refused to troubleshoot the problem until they could replicate the issue and the tweeter thought that wasn’t right. It made me start thinking about why troubleshooters are so bent on trying to make something happen again before we actually start trying to fix an issue.

The Definition of Insanity

Everyone by now has heard that the definition of insanity is doing the same thing over and over again and expecting a different result. While funny and a bit oversimplified the reality of troubleshooting is that you are trying to make it do something different with the same inputs. Because if you can make it do the same thing over and over again you’re closer to the root cause of the issue.

Root cause is the key to problem solving. If you don’t fix what’s actually wrong you are only dealing with symptoms and not issues. However, you can’t know what’s actually wrong until you can make it happen more than once. That’s because you have to narrow the actual issue down from all of the symptoms. If you do something and get the same output every time then you’re on the right track. However, if you change the inputs and get the same output you haven’t isolated the issue yet. It’s far too common in troubleshooting to change a bunch of things all at once and not realize what actually fixed the problem.

Without proper isolation you’re just throwing darts. As the above comic illustrates sometimes the victory is causing a different error message. That means you’re manipulating the right variables or inputs. It also means you know what knobs need to be turned in order to get closer to the root cause and the solution. So repeatability in this case is key because it means you’re not trying to fix things that aren’t really broken. You’re also narrowing the scope of the fixes by eliminating things that don’t need to be monitored.

Resource Utilization

How long does it take to write code? A couple of hours? A day? Does it take longer if you’re trying to do tests and make sure your changes don’t break anything else? What about shipping that code as part of the DevOps workflow? Or an out-of-band patch? Do you need to wait until the next maintenance window to implement the changes? These are all extremely valuable questions to ask to figure out the impact of changes on your environment.

Now multiply all of those factors by the number of things you tried that didn’t work. The number of times you thought you had the issue solved only to get the same error output. You can see how wasting hours of a programming team working on things can add up to the company’s bottom line quickly. Nothing is truly free or a sunk cost. You’re still paying people to work on something, whether it’s fixing buggy code or writing a new feature for your application. If they’re spending more of their time tracking down bugs that happen infrequently with no clear root cause are they being used to their highest potential?

What happens when that team can’t fix the issue because it’s too hard to cause it again? Do they bring in another team? Pay for support calls? Do you throw up your hands and just live with it? I’ve been involved in all of these situations in the past. I’ve tried to replicate issues to no avail only to be told that they’ll just live with the bug because they can’t afford to have me work on it any longer. I’ve also spent hours trying to replicate issues only to find out later that the message has only ever appeared once and no one knows what was going on when it happened. I might have been working for a VAR at the time but my time was something the company tracked closely. Knowing up front the issue had only ever happened once might have changed the way I worked on the issue.

I can totally understand why people would be upset that a help desk closed a ticket because they couldn’t replicate an issue. However, I also think that prudence should be involved in any structured troubleshooting practice. Having been on the other side of the Severity One all-hands-on-deck emergencies only to find a simple issue or a non-repeatable problem in the past I can say that having that many resources committed to a non-issue is also maddening as a tech and a manager of technical people.

Tom’s Take

Do you need to replicate a problem to troubleshoot it? No. But you also don’t need to follow a recipe to bake a cake. However, it does help immensely if you do because you’re going to get a consistent output that helps you figure out issues if they arise. The purpose of replicating issues when troubleshooting isn’t nefarious or an attempt to close tickets faster. Instead it’s designed to help speed problem isolation and ensure that resources are tasked with the right fixes to the issues instead of just spraying things and hoping one of them gets the thing taken care of.

Making It Work in 2023

Posted on by
Reply

We’re back to the first of the year once again. January 1, 2023 is a Sunday which feels somewhat subdued. That stands in contrast to the rest of the year that felt like a rollercoaster always one heartbeat away from careening out of control. As is the tradition, I’ll look at the things I wanted to spend more time working on in 2022:

  • More Analytical Content: I have to honestly give myself a no on this one, at least from a technical perspective. I did spend some time making analytical content for my Tomversations series. However, the real difference in analytical content came from my posts about leadership and more “soft skill” focused ideas. I’ve gotten more comments about those posts than anything in 2022 and I couldn’t be more proud.
  • Saying No to More Things: This is the part where I would insert an animated GIF of someone laughing manically. While I did make strides in telling people that I have way too much going on to take care of one extra thing the reality is that I took on more things that I probably should have. That’s something that I definitely do need to change but the real hard part isn’t saying No. It’s making it stick.
  • Getting In Front of Things: This one actually was one that I had the hardest time with. I was able to work on some of this in my Tech Field Day job but it was my blog that suffered the most. I wanted to start spending more time thinking about post topics earlier in the week so I wasn’t always posting on Fridays. The irony is that toward the end of the year I did manage to get some posts out on other days. I just did it because I was having severe writer’s block and I was late on several posts. In fact, I technically missed a post in 2022 for the first time in twelve years. I think it’s more a reflection on how important it is to keep your eye on the prize as you create content. I don’t have metrics like those on YouTube channels driving me to put out 2-3 videos a week. Instead I really have to make sure I’m aware of what needs to happen to keep the content coming out.

2022 was a year of getting things back to a version of normal but it also was a year of me trying to implement things that didn’t go the way I wanted. That seems to be the challenge for all good intentions. So let’s look at what I want to do in 2023 to keep myself from struggling the way that I did before.

  • Keeping Track of Things: I knew I was in for trouble when I stopped writing things down two weeks into the year. My plans for bullet journaling seemed to evaporate because I tried to make changes that didn’t stick. So I’m resetting it back to Square Zero. I’m writing everything down somewhere and I’m not going to forget it this time. I know where my notes are and I know what I need to do to keep myself on track. The difference between writing it down when I do it and just trying to remember to do it is very, very stark. So rather than thinking I have a good memory and forgetting that I don’t I’m not leaving anything up to chance.
  • Creating Evergreen Content: During my workouts this year I’ve spent more time listening to podcasts like Hidden Brain and Huberman Lab which focus on behavior and the brain. Why? Because I’m fascinated to learn why we think and do the things we do. When you couple that with my outside work in the Wood Badge leadership program I think I’m starting to see the value of creating content more around skills and leadership instead of just talking about the next iteration of wireless or SD-WAN. That doesn’t mean my technical writing is going to go away. It does mean that I’m going to try to sprinkle in more posts about mentoring, leadership, and creating a culture that will help you pay dividends unlike ATM, HD-DVD, and several other forgotten technologies.
  • Ensuring Intentionality: This one feels a bit nebulous but that’s because it’s hard to pin down what being intentional really means to everyone. I’ve used the world a bit more in the latter half of 2022 when discussing certain aspects of my job and it seems to have stuck with others. Intentionality to me means making sure that I’m focused on ensuring outcomes happen. A lack of intentionality is like gathering the ingredients for a cake, assembling them on a table, and then hoping that a cake somehow magically appears. You have to combine the ingredients in the proper amounts and make things happen to create a cake. Even with all the right conditions you still need to do the work to make things happen. And if you think that’s an easy thing to do take a look around in your office and tell me just how many people that you work with that aren’t intentional in what they do.

Tom’s Take

One of the things that I can look back on over the past few years is that my first of the year posts have reflected the challenges that I’ve faced. The shifting landscape of content has forced me to look at what I create. The challenges of a world that went into hibernation for a while have changed the way I look at how I get my work done. Even the growth that I’ve experienced over the years has shifted my thinking. I won’t be the next big YouTube star. My gift is in writing. And focusing on that as my starting point for the year to come is going to help me make things work.

Testing Your Weakest Links as a Chain

Posted on by
Reply

You may have heard in the news this week that there was a big issue with Southwest Airlines this holiday season. The issues are myriad and this is going to make for some great case studies for students in the future. However, one thing I wanted to touch on briefly in this whole debacle was the issue of a cascade failure.

The short version is that a weather disruption in the flight schedule became a much bigger problem when the process for rescheduling the flight crews was overwhelmed. Turns out that even after the big computer system upgrades and all the IT work that has gone into putting together a modern airfare booking system that one process was still very manual. The air crew rescheduling department was relatively small in nature and couldn’t keep up with the demands placed on it by the disruptions. It got to the point where Southwest had to reduce their number of flights in order to get the system back to normal.

Worst Case Scenario

I’m not an expert at airline scheduling but I have spent a lot of time planning for disaster recovery. One of the things that we focus on more than anything else is the recovery aspect. The whole purpose of the plan is to get things up and running, right? That requires a look at the big picture of what data needs to be saved and where it needs to be stored and how people are going to do it. In the above example the focus of the airline was getting passengers booked on flights as soon as possible.

However, the details matter just as much as the big picture. If you don’t know the process at every step of the way you’re going to find that the weakest link in the chain is the one that breaks. All the upgrades in the world for remote storage or immutable snapshots won’t matter if someone doesn’t have a key to the data center to turn everything on. Just ask the engineers at Facebook that didn’t realize the door controls for the data center relied on the internal systems that were unreachable during their 2021 outage.

How can you catch these little details? How can you be so sure that everything isn’t going to fall apart because someone forgot the keys to the closet with the disaster recovery binder? The answer, of course, is testing. You’re going to have to test every aspect of the plan from top to bottom. Most everyone will agree that you have to test everything properly to make sure no one problem overwhelms the system. However, that’s where this whole thing falls apart.

Forest for the Trees

If you’re just looking at the individual aspects of your disaster recovery plan in a vacuum you’re going to have a miserable time of it when things go wrong. Unit testing is a popular way to look at the components of the plan to ensure they work without incurring too much cost or too many resources for the testing. However, unit testing alone doesn’t look at the way the details integrate.

That’s where integration testing comes into play. It’s not enough to check the individual pieces. Maybe the computer system is good at rescheduling passengers and balancing the gate assignments. However, if they can’t get on the plane because the system doesn’t think there is a crew due to the way the process interacts with a different area then you don’t have a functional system no matter how great one part of it is.

Disaster recovery tests can be done at the unit level to make sure new modules or processes are solid but you have to make sure you have integrated full tests at least once every six months or so. You have to find the holes in the system caused by the interactions of the details. Sure, the generators might fire up on cue but what if someone is parked in front of the fuel delivery area? What if the keys to the backup cages are on someone’s keychain instead of in a central area? These are questions you want to answer before everyone is running around with their hair on fire.

More importantly, when this happens you need to document all of it. If there is a particular integration that fails you need to write it down and discuss it with your teams. Understand why it happened and put process and procedure in place to cover it. Then make sure that everyone is aware the plan was updated. If people think that something has to be done a certain way because that’s the way it’s always done they’re going to keep doing it that way until they are told differently. Communication is key in any kind of adverse situation.

Lastly, be honest when you’re evaluating these process failures. Don’t try to explain it away or minimize the impact. If someone didn’t do their job then make sure everyone knows what needed to happen and how it failed. If a system doesn’t work properly then analyze the system and fix it. Don’t throw blame where it’s not warranted but don’t explain it away to salve an ego. You need to make the process work and make it work every time so that you don’t run into issues again.

Tom’s Take

Disasters happen. If you’re really lucky you will have something in place to keep the disaster from spiraling out of control. The plural of lucky is good and in order to be good you need to analyze how the process works in concert with every component to make sure there are no weak links. If the chain breaks like it did for Southwest you’ll be very lucky to lose money and customers. If you’re not lucky you’ll lose a lot more.

The Power of Complaining Properly

Posted on by
Reply

Recently I’ve started listening to a new podcast all about the brain and behaviors called Hidden Brain. It’s got a lot great content and you should totally check it out. One of the latest episodes deals with complaining and how it can make us less productive and more likely to repeat patterns or shut people out.

Complaining is as old as language. I’m sure as soon as the first person to create communications around spoken words was able to teach another person one of the first things they did was complain about the weather or something they hated. Our mind is built to express itself about things we don’t like, such as bad drivers or silly behaviors at work.

The episode explores the ways that our brain can trap us in cycles of complaining simply for the sake of complaining. It also discusses how we should try to spend more time trying to be productive in how we address complaints. I’ve experienced this a lot in IT as well as in my career after being directly involved in IT and there’s a lot of merit in changing the way we complain about things.

Airing Grievances

Complaining without a suggested solution is just whining.

I’ve always found complaining just for the sake of complaining to be counterproductive. Sure, it might feel awesome to just let it all out and pick apart someone’s decision making process or their personality but that’s not sustainable long term. As in the episode above when you spend your time complaining just for the sake of complaints you eventually fall into a pattern and you can’t break out of it. We all have that one friend or coworker that comes to us and complains about stuff no matter what, right?

In part this happens because we create an agreeable environment for it. That’s not always a bad thing. People sometimes just want to complain. If you’ve ever had to deal with someone getting upset because you didn’t just agree with their complaints you know how that can go. There are those in society that would rather just let it all out without disagreement or challenge.

The opposite side of that situation is when someone is challenging our assumptions or forcing us to see things in a different light. I’m sure that everyone reading this can think of someone they know that will show them another side of the argument or help them understand the path to solving issues instead of just whining about them. This person is someone you may not go to all the time because you realize they’re going to make you confront what’s going on instead of just agreeing with it.

We cultivate both of these kinds of people in our circles. We have those we will commiserate with and those we will seek out for help. So how do we manage to spend more time on fixing issues instead of just falling into the patterns of whining and regressive behavior?

Outcomes Over Opining

The first key to figuring out how to break out of the cycle and focus on making this better is a trick I use with others that only want to complain about things in my presence. They want to tell me everything that’s wrong, or more accurately what I’ve done wrong. So I ask a simple question:

How would you like this situation resolved?

It sounds almost too simple. However, if you think about the above examples you realize there are those that simply want to complain. They may not have a solution in mind. Think of those on social media that just want to air their grievances about a company or a person on a perpetual basis. Are they looking to change the situation? Or would they just prefer to complain? Once you ask the person, or ask yourself, how they want the situation resolved then you’ve moved past complaining to a solution.

Once you’re able to break out of the complaining loop you need to keep the conversation focused on the outcome. It’s easy to slip back into complaining and whining mode when you lose sight of the goal. If the solution is to recognize that things need to improve work on the plan of improvement. Have a goal in mind. Is the solution to have better service in a restaurant? Or to not have something cost so much if it is of inferior quality? By making the outcome the focus you channel the negativity into something that can be positive. One other side effect of the focus on the outcome is that continued complaining will fall on deaf ears and usually shorten the conversation. Even if the person has a solid outcome in mind they’ll lose interest if the sole purpose of the conversation is venting instead of productive work.

Lastly, understand that this is really focused on complaining on a non-personal level. Personal discussions are often not going to have an outcome in mind. Maybe the goal is to just vent. That’s why I usually ask now if I’m serving as emotional support or problem solving. However, in a business environment the goal should be the outcome. Especially if it’s a conflict or a complaint from a team member. The goal should be reducing friction and not just being a sounding board for those that would rather expend energy on the problem and not the solution.

Tom’s Take

I complain, just like any other normal person does. Sometimes my complaints are just ways to get my emotional weight off my shoulders. However I have always subscribed to the idea that I need to have an outcome in mind to fix what is causing my issues. Sometimes that outcome is far outside of my control, such as fixing someone’s personality. Other times it is very much in my control but will require work on my part to make it happen. That’s where I always ask myself how much I want this issue resolved. I make sure I’m ready to invest the energy to make it better before I even start.Odds are good that if I’m complaining I’m talking myself into making it better. To me, that’s the power of a proper complaint.