Predictions As A Service

It’s getting close to the end of the year and it’s time once again for the yearly December flood of posts that will be predicting what’s coming in 2018. Long time readers of my blog know that I don’t do these kinds of posts. My New Year’s Day posts are almost always introspective in nature and forward looking from my own personal perspective. But I also get asked quite a bit to contribute to other posts about the future. And I wanted to tell you why I think the prediction business is a house of cards built on quicksand.

The Layups

It’s far too tempting in the prediction business to play it safe. Absent a ton of research, it’s just easier to play it safe with some not-so-bold predictions. For instance, here’s what I could say about 2018 right now:

  • Whitebox switching will grow in revenue.
  • Software will continue to transform networking.
  • Cisco is going to buy companies.

Those are 100% true. Even without having spent one day in 2018. They’re also things I didn’t need to tell you at all. You already knew them. They’re almost common sense at this point. If I needed to point out that Cisco is going to buy at least two companies next year, you are either very new to networking or you’ve been studying for your CCIE lab and haven’t seen the sun in eight months.

Safe predictions have a great success rate. But they say nothing. However, they are used quite a bit for the lovely marketing fodder we see everywhere. In three months, you could see presentation from an SD-WAN vendor that says, “Industry analyst Tom Hollingsworth predicts that 2018 is going to be a big year for software networking.” It’s absolutely true. But I didn’t say SD-WAN. I didn’t name any specific vendors. So that prediction could be used by anyone for any purpose and I’d still be able to say in December 2018 that I was 100% right.

Playing it safe is the most useless kind of prediction there is. Because all you’re doing is reinforcing the status quo and offering up soundbites to people that like it that way.

Out On A Limb

The other kind of prediction that people love to get into is the crazy, far out bold prediction. These are the ones that get people gasping and following your every word to see if it pays off. But these predictions are prone to failure and distraction.

Let’s run another example. Here are four bold sample predictions for 2018:

  • Cisco will buy Arista.
  • VMware will cease to be a separate brand inside Dell.
  • Hackers will release a tool to compromise iPhones remotely.
  • HPE will go out of business.

Those predictions are more exciting! They name companies like Cisco and VMware and Apple. They have very bold statements like huge purchases or going out of business. But guess what? They’re completely made up. I have no insight or research that tells me anything even close to those being true or not.

However, those bold predictions just sit out there and fester. People point to them and say, “Tom thinks Cisco will buy Arista in 2018!” And no one will every call me on the carpet if I’m wrong. If Cisco does end up buying Arista in 2020 or later, people will just say I was ahead of my time. If it never comes to pass, people will forget and just focus on my next bold prediction of VMware buying Cisco. It’s a hype train with no end.

And on the off chance that I do nail a big one, people are going to think I have the inside track. My little predictions will be more important. And if I hit half of my bold ones, I would probably start getting job offers from analyst firms and such. These people are the prediction masters extraordinaire. If they aren’t telling you something you already know, they’re pitching you something that have no idea about.

Apple has a cottage industry built around crazy predictions. Just look back to August to see how many crazy ideas were out there about the iPhone X. Fingerprint sensor under the glass? 3D rear camera? Even crazier stuff? All reported on as pseudo-fact and eaten up by the readers of “news” sites. Even the people who do a great job of prediction based on solid research missed a few key details in the final launch. it just goes to show that no one is 100% accurate in bold predictions.


Tom’s Take

I still do predictions for other people. Sometimes I try to make tongue-in-cheek ones for fun. Other times I try to be serious and do a little research. But I also think that figuring out what’s coming 5 years from now is a waste of my time. I’d rather try to figure out how to use what I have today and build that toward the future. I’d rather be a happy iPhone user than the people that predicted that Apple’s move into the mobile market would fail miserably. Because that’s a headline you’ll never live down.

I’d like to thank my friends at Network Collective for inspiring this post. Make sure you check out their video podcast!

Advertisements

Scotty Isn’t DevOps

I was listening to the most recent episode of our Gestalt IT On-Presmise IT Roundtable where Stephen Foskett mentioned one of our first episodes where we discussed whether or not DevOps was a disaster, or as I put it a “dumpster fire”. Take a listen here:

Around 13 minutes in, I have an exchange with Nigel Poulton where I mention that the ultimate operations guy is Chief Engineer Montgomery Scott of the USS Enterprise. Nigel countered that Scotty was the epitome of the DevOps mentality because his crazy ideas are what kept the Enterprise going. In this post, I hope to show that not only was Scott not a DevOps person, he should be considered the antithesis of DevOps.

Engineering As Operations

In the fictional biography of Mr. Scott, all he ever wanted to do was be an engineer. He begrudging took promotions but found ways to get back to the engine room on the Enterprise. He liked working starships. He hated building them. His time working on the transwarp drive of the USS Excelsior proved that in the third Star Trek film.

Scotty wasn’t developing new ideas to implement on the Enterprise. He didn’t spend his time figuring out how to make the warp engines run at increased efficiency. He didn’t experiment with the shields or the phasers. Most of his “miraculous” moments didn’t come from deploying new features to the Enterprise. Instead, they were the fruits of his ability to streamline operations to combat unforeseen circumstances.

In The Apple, Scott was forced to figure out a way to get the antimatter system back online after it was drained by an unseen force. Everything he did in the episode was focused on restoring functions to the Enterprise. This wasn’t the result of a failed upgrade or a continuous deployment scenario. The operation of his ship was impacted. In Is There No Truth In Beauty, Mr. Scott even challenges the designer of the Enterprise’s engines that he can’t handle them as well as Scotty. Mr. Scott was boasting that he was better at operations than a developer. Plain and simple.

In the first Star Trek movie, Admiral Kirk is pushing Scotty to get the Enterprise ready to depart in hours after an eighteen month refit. Scotty keeps pushing back that they need more time to work out the new systems and go on a shakedown cruise. Does that sound like a person that wants to do CI/CD to a starship? Or does it sound more like the caution of an operations person wanting to make sure patches are deployed in a controlled way? Every time someone in the series or movies suggested doing major upgrades or redesigns to the Enteprise, Scotty always warned against doing it in the field unless absolutely necessary.

Montgomery Scott isn’t the King of DevOps. He’s a poster child for simple operations. Keep the systems running. Deal with problems as they arise. Make changes only if necessary. And don’t monkey with the systems! These are the tried-and-true refrains of a person that knows that his expertise isn’t in building things but in making them run.

Engineering as DevOps

That’s not to say that Star Trek doesn’t have DevOps engineers. The Enterprise-D had two of the best examples of DevOps that I’ve ever seen – Geordi LaForge and Data. These two operations officers spent most of their time trying new things with the Enterprise. And more than a few crises arose because of their development aspirations.

LaForge and Data were constantly experimenting on the Enterprise in an attempt to make it run better. Given that the mission of the Enterprise-D did not have the same five-year limit as the original, they were expected to keep the technology on the Enterprise more current in space. However, their experiments often led to problems. Destabilizing the warp core, causing shield harmonics failures, and even infecting the Enterprise’s computer with viruses were somewhat commonplace during Geordi’s tenure as Chief Engineer.

Commander Data was also rather fond of finding out about new technology that was being developed and trying to integrate it into the Enterprise’s systems. Many times, he mentioned finding out about something being developed the the Daystrom Institute and wanting to see if it would work for them. Which leads me to think that the Daystrom Institute is the Star Trek version of Stack Overflow – copy some things you think will make everything better and hope it doesn’t blow up because you didn’t understand it.

Even if it was a plot convenience device, it felt like the Enterprise was often caught in the middle of applying a patch or an upgrade right when the action started. An exploding star or an enemy vessel always waited until just the right moment to put the Enterprise in harm’s way. Even Starfleet seemed to decide the Enterprise was the only vessel that could help after the DevOps team took the warp core offline to make it run 0.1% faster.

Perhaps instead of pushing forward with an aggressive DevOps mentality for the flagship of the Federation, Geordi and Data would have done better to take lessons from Mr. Scott and wait for appropriate windows to make changes and upgrades and quite tinkering with their ship so often that it felt like it was being held together by duct tape and hope.


Tom’s Take

Despite being fictional characters, Scotty, Geordi, and Data all represent different aspects of the technology we look at today. Scotty is the tried-and-true operations person. Geordi and Data are leading the charge to keep the technology fresh. Each of them has their strong points, but it’s hard to overlook Scotty as being a bastion of simple operations mentalities. Even when they all met together in Relics, Scotty was thinking more about making things work and less on making them fast or pretty or efficient. I think the push to the DevOps mentality would do well to take a seat and listen to the venerable chief engineer of the original Enterprise.

More Accurate IT Acronyms

IT is flooded with acronyms. It takes a third of our working life to figure out what they all mean. Protocols aren’t any easier to figure out if it’s just a string of three or four letters that look vaguely like a word. Which, by the way, you should never pronounce.

But what if the acronyms of our favorite protocols didn’t describe what the designers wanted but instead described what they actually do?

  • Sporadic Network Mangling Protocol

  • Obscurity Sends Packets Flying

  • Expensive Invention Gets Routers Puzzled

  • Vexing Router Firmware

  • Really Intensive Protocol

  • Someone Doesn’t Worry About Networking

  • Somewhat Quixotic Language

  • Blame It oN DNS

  • Cisco’s Universal Call Misdirector

  • Some Mail’s Thrown Places

  • Mangles Packets, Looks Silly

  • Amazingly Convoluted Lists

  • ImProperly SECured

  • May Push Lingering Sanity To Expire

Are there any other ones you can think of? Leave it in the comments.

Is It Really Always The Network?

Keep Calm and Blame the Network

Image from Thomas LaRock

I had a great time over the last month writing a series of posts with my friend John Herbert (@MrTugs) over on the SolarWinds Geek Speak Blog. You can find the first post here. John and I explored the idea that people are always blaming the network for a variety of issues that are often completely unrelated to the actual operation of the network. It was fun writing some narrative prose for once, and the feedback we got was actually pretty awesome. But I wanted to take some time to explain the rationale behind my madness. Why is it that we are always blaming the network?!?

Visibility Is Vital

Think about all the times you’ve been working on an application and things start slowing down. What’s the first thing you think of? If it’s a standalone app, it’s probably some kind of processing lag or memory issues. But if that app connects to any other thing, whether it be a local network or a remote network via the Internet, the first culprit is the connection between systems.

It’s not a large logical leap to make. We have to start by assuming the the people that made the application knew what they were doing. If hundreds of other people aren’t having this problem, it must not be with the application, right? We’ve already started eliminating the application as the source of the issues even before we start figuring out what went wrong.

People will blame the most visible part of the system for issues. If that’s a standalone system sealed off from the rest of the world, it obviously must be the application. However, we don’t usually build these kinds of walled-off systems any longer. Almost every application in existence today requires a network connection of some kind. Whether it’s to get updates or to interact with other data or people, the application needs to talk to someone or maybe even everyone.

I’ve talked before about the need to make the network more of a “utility”. Part of the reason for this is that it lowers the visibility of the network to the rest of the IT organization. Lower visibility means fewer issues being incorrectly blamed on the network. It also means that the network is going to be doing more to move packets and less to fix broken application issues.

Blame What You Know

If your network isn’t stable to begin with, it will soon become the source of all issues in IT even if the network has nothing to do with the app. That’s because people tend to identify problem sources based on their own experience. If you are unsure of that, work on a consumer system helpdesk sometime and try and keep track of the number of calls that you get that were caused by “viruses” even if there’s no indication that this is a virus related issue. It’s staggering.

The same thing happens in networking and other enterprise IT. People only start troubleshooting problems from areas of known expertise. This usually breaks down by people shouting out solutions like, “I saw this once so it must be that! I mean, the symptoms aren’t similar and the output is totally different, but it must be that because I know how to fix it!”

People get uncomfortable when they are faced with troubleshooting something unknown to them. That’s why they fall back on familiar things. And if they constantly hear how the network is the source of all issues, guess what the first thing to get blamed is going to be?

Network admins and engineers have to fight a constant battle to disprove the network as the source of issues. And for every win they get it can come crashing down when the network is actually the problem. Validating the fears of the users is the fastest way to be seen as the issue every time.

Mean Time To Innocence

As John and I wrote the pieces for SolarWinds, what we wanted to show is that a variety of issues can look like network things up front but have vastly different causes behind the scenes. What I felt was very important for the piece was the distinguish the the main character, Amanda, go beyond the infamous Mean Time To Innocence (MTTI) metric. In networking, we all too often find ourselves going so far as to prove that it’s not the network and then leave it there. As soon as we’re innocent, it’s done.

Cross-function teams and other DevOps organizations don’t believe in that kind of boundary. Lines between silos blur or are totally absent. That means that instead of giving up once you prove it’s not your problem, you need to work toward fixing what’s at issue. Fix the problem, not the blame. If you concentrate on fixing the problems, it will soon become noticeable that networking team may not always be the problem. Even if the network is at fault, the network team will work to fix it and any other issues that you see.


Tom’s Take

I love the feedback that John and I have gotten so far on the series we wrote. Some said it feels like a situation they’ve been in before. Others have said that they applaud the way things were handled. I know that the narrative allows us to bypass some of the unsavory things that often happen, like argument and political posturing inside an organization to make other department heads look bad when a problem strikes. But what we really wanted to show is that the network is usually the first to get blamed and the last to keep its innocence in a situation like this.

We wanted to show that it’s not always the network. And the best way for you to prove that in your own organization is to make sure the network isn’t just innocent, but helpful in solving as many problems as possible.

How To Ask A Question At A Conference

question-mark-706906_1280

The last time you went to a conference, did you ask any questions? Were you curious about a technology and wanted to know more? Was there something that you didn’t quite get and needed an explanation? Congratulations. You’re in a quiet group of people that ask questions for knowledge. More and more, we are seeing questions becoming a vehicle for more than just knowledge acquisition. If you want to learn how to ask a proper question at a conference, read on.

1. Have A Question

I know it goes without saying, but if you’re going to raise your hand at a conference to ask a question, you should actually have a question in mind. Some people grab a microphone without thinking through what they’re going to say. This leads to stammering and broken thoughts that usually culminate in a random question mark here or there. This makes it difficult for the speaker to figure out what you’re trying to ask.

If you’re going to raise your hand, jot some notes down first. Bullet points help as does making a note or two. This is especially true if the speaker is answering questions before yours. If they answer part of your question before you get to ask it, you may have to reframe your thoughts. It never hurts to have an idea of what you’re going to say before you say it.

2. Look For Knowledge, Not To Make A Statement

The other side of the coin from the above recommendation of actually having a question is to make sure that what you’re asking is actually a question and not a statement. A great example of this is a video from Scott Bradner during a recent ONUG meeting:

I’m sure Scott has seen his fair share of statements masquerading as questions during his time. And I can’t disagree with him. Far too often, people seeking questions aren’t really asking to get information. Instead, they are trying to make a point about why they think they are right or why they disagree with the speaker. The point stops becoming a question and more of a soliloquy or soapbox. The most egregious will usually end this rant with an actual question along the lines of, “So, what do you think of my opinion?”

Please, at all costs, avoid this behavior. This is singularly the most annoying thing a speaker has to deal with. It’s enough to be questioned on your material, but it’s something else entirely to have to shift your thinking to someone else’s viewpoint while on stage. If you have a point you’d like to bring up with the speaker that is contrary to their thought process, you should do it after the presentation without people watching. Have a discussion and express opinions there. Don’t grandstand in front of the crowd just to satisfy your ego.

theres-no-question-youre-clever

3. Make Sure Your Question Wasn’t Already Answered.

This one’s a bit tougher. If you’re sitting in a session and you have a question, it’s important to make sure it wasn’t already asked and answered beforehand. This can be tougher if you have to duck out to take a call or you miss a section of the presentation. In these cases, you can ask for clarification or additional information but it would be better to ask after the session. Audiences tend to get a bit irritated if someone asks a question that was previously answered or that was covered earlier.

This one is probably the most forgivable of the question faux pas. People at conferences know that ducking out to deal with things is more common now. But if you are going to ask a question because you missed something, please make sure to address then when you ask. That helps everyone get the frame of reference for why you’re asking it. That will keep the audience on your side and less likely to boo you.


Tom’s Take

I ask lots of questions. I also answer them. And nothing irritates me more than having to deal with someone making a point during Q&A to try and make them look smarter than me. I get it. I have a hatred of keynotes and other speeches with no ability to get feedback. But at the same time, as Scott Bradner says above, the focus of the presentation is about the people presenting. It’s about the people doing the work and sharing the ideas. If you want to use Q&A time to pontificate about your position, then you need to volunteer to be a speaker.

Keystone Keynotes

keystonekeynotepatrol

My distaste for keynotes is well known. With the possible exception of Justin Warren (@JPWarren) there may not be a person that dislikes them more than I do. I’ve outlined my reasons for it before, so I won’t go into much depth about it here. But I do want to highlight a few recent developments that are doing a great job of helping me find new things to dislike.

Drop The “Interviews”

When you walk into a keynote ballroom or arena and see two comfy chairs on stage, you know what’s coming. As someone told me recently, “This is when I know the next hour is going to suck.” The mock interview style of keynote speech is not good. It’s a thinly-veiled attempt to push an agenda. Perhaps it’s about innovation. Or transformation. Or some theme of the conference. Realistically, it’s mostly a chance for a keynote host (some form of VP) to provide forced banter with a celebrity that’s being paid to be there.

These “interviews” are rarely memorable. They seem self serving and very plastic. The only ones that even stand out to me in recent memory are the ones that went off the rails. The time when Elon Musk was “interviewed” on stage at Dell World and responded with clipped answers and no elaboration. Or the time Richard Branson was hitting on the host at Cisco Live. Or the Cisco Live when William Shatner started taking shots at Cisco on stage!

It’s time to drop the fake interviews. Let the speakers tell their stories. Kevin Spacey at Cisco Live 2016 was a breath of fresh air. He was compelling. Invigorating. Engaging. People around me said it was the best keynote they’d heard in year. It was easily the best one I’d see since John Cleese in Orlando in 2008. Give the people who spend their time telling stories a chance to shine. Don’t inject yourself into the process. Because actors and celebrity storytellers don’t play. They live their stories.

All By My Selfie

If the keynote involves talking about community or the power of the user base or some other contrite platitude, you can almost guarantee that the host VP is going to pause at some point, usually during the big celebrity interview, to take selfie with their guest and the whole audience in the background. It’s a nod to how hooked in and in the know with the community. Think back to Ellen Degeneres and her infamous Oscars selfie:

Except it’s not. It’s a big steaming pile of patronizing behavior. Hey everyone that paid $1,500 to hear our transformation strategy! Let me take a picture of myself on a stage with blurry, badly lit faces in the audience! Let me post it to Facegram and Instabook and Snapfilter Stories! Let me have my social team repost it and heart/like/favorite it as many times as it takes for me to look like I “get” social. And after the conference is over, my InstaFaceSnapgrambookfilter feed will go back to auto posting the content fed to it by a team of people trying to make me seem human but not be controversial or get us sued.

Don’t take a selfie with 4,000 people in a hall. Meet those users. The ones that paid you. The ones that run your hardware even though your competitor is knocking on the door every week trying to get them to dump you. The users and customers that are supporting your efforts to cut your nose off to spite your face as you transform yourself into a software company. Or a cloud provider. Or an app company. Don’t pretend that the little people matter in a selfie that needs Super Troopers-style ENHANCE to find my shining freckles in the dark. Be a human and take a selfie with one user that has stuck by you through thick and thin. Make their day. Don’t make yours.

Distrupting Disruption

“We’re like the Uber of….”

No. You aren’t. If you are a part of the market, you aren’t disrupting it. You may be shifting your ideas or repositioning your strategies, but that’s not disruption. You still support your old equipment and software. You’re not prepared to jettison your existing business models to move somewhere new. A networking company building networking software isn’t disruption. A server company buying a networking startup isn’t disruption. It’s strategy.

Uber is the Business School case study for disruption. Every keynote in the last two years has mentioned them. Expect their disruption of the transportation market is far from total or completely impressive. Sure, they are farming out taxi services. They’re also cutting rates to drive business to increase profits without helping drivers with new lower rates. They are bullying municipalities to get laws passed to protect them. They’re driving other companies out of business to reduce competition. Does that sound like the Disruptors of Taxis? Or does is sound like the very cab companies that are getting run out of business by the very tactics they themselves have used?

Don’t tell me how you’re disrupting digital or accelerating change. Tired cliches are tired. Tell me what you’re doing. Tell me how you’re going to head off your competitors. Tell me how you’re addressing a shrinking market for hardware or a growing landscape of people doing it faster, cheaper, and better. This is one of the things that I enjoy about being an analyst. These briefings are generally a little more focused on the concrete and less on the cheerleading, which is a very pleasant surprise to me given my distaste for professional analyst firms.

If you’re tempted to say that you’re the Uber of your industry, do us all a favor and request one to drive you off the stage.


Tom’s Take

Does my dislike of keynotes show yet? Are some you sitting in your chairs cheering? Good. Because it’s all a show for you. It’s a hand-holding, happy hugging reinforcement of how awesome we are. Outside of a few dynamic speakers (who are usually made CTO or VP of Technology), we don’t get the good stuff any more.

If you’re sitting in your chair and getting offended that I’m picking on your event, you should know two things. First, I’m not singling anyone out. EVERY keynote I’ve seen in the last two years is guilty of these things. And if you think yours is, you’re probably right. Fix it. Transform and Disrupt your own keynote. Let story tellers talk. Cut down on the attempts to relate to people. Tell your story. Tell people why they should be excited again. Don’t use cliches. Or funny videos. Or cameraphones. Get back to the business of telling people why you’re in business. Ditch the Keystone Keynotes and I promise you’ll have happier audiences. Including me.

Build Slides Are Evil

 

HammerAndSaw

PowerPoint is a necessary evil. No program allows us to convey as much information in a short amount of time. PowerPoint is almost a requirement for speaking in front of groups. Information can be shown in a very effective manner for audiences of five or five hundred. But PowerPoint also allows presenters to do some very silly things that impact our ability to learn.

Not Built In A Day

The biggest offense in the land of PowerPoint is the build slide. Build slides are those that have elements that must be layered together in order to show the complete picture. In some cases, build slides have complex graphic overlays with many different elements. They may have clip art overlays. But build slides can also be simple bullet points that appear one at a time in a list. The key is that all the parts of the slide must progress in series to “build” the whole thing.

Build slides look very awesome. They provide the appearance of motion and give a movie-like quality to a static presentation. And they often take up a large amount of time during the creation process. But they are almost always unnecessary.

When built properly, a slide conveys a single idea. It may have one or two supporting ideas, but overall it should be pared down to the minimum necessary to get the idea across. Having a page full of bullet points confuses and distracts the reader. It doesn’t matter whether those bullet points are unveiled all at once or sequentially. Each additional piece of information runs the risk of the entire message or idea being forgotten.

Worse yet, the elements of a build slide can be a mystery to everyone, even the presenter. How many times have you watched a presentation where a presenter gets ahead of themselves and reveals a bullet point before it’s on screen? Or perhaps the presenter lost track of how many points were on the slide?

Another strike against build slides is what happens when you’re forced to deal with them outside of presentation mode. Build slides break down when you can’t project them properly in a mode that simulates a projector. Like over a web presentation or screen sharing program. Build slides are also a bad idea when presenting on video. If your slide deck doesn’t come across well, there are options to insert slides into the video recording. But if you have build slides, those slides can’t be inserted without either using the completely built slide, which ruins the suspense of a build up, or looks crowded and complex in many cases.

One Slide At A Time

A build slide is needlessly complicated. If you have four bullet points on a slide, you have an opportunity to make each of those into a separate slide with different information conveying the idea. Like a single supporting fact or statement. Or a picture to help visual learners internalize the idea. There are a multitude of ways to make a slide stand out without pointless animation.

You’re probably thinking to yourself that adding slides to your presentation will make it longer than it needs to be. In fact, the opposite is true. By paring your deck down to a single idea per slide, you can effectively communicate that idea and move on to the next slide. If your original slide had five ideas and took five minutes to talk about, then it follows that one idea per slide spread over five slides should take the same amount of time. In a few cases, it may take less thanks to the reduction in tendency to wander through a long slide.

If you must have bullet points supporting an idea, make each of those bullet points a new slide. Just copy and paste the existing text into a new slide with a new bullet. That allows you to add to what you’ve said previously while still capturing the progression easily. You may also find that you’re adding unnecessary steps that can be removed along the way.


Tom’s Take

I don’t give presentations to amaze people with my PowerPoint skills. People come to hear me talk, not see what transitions I built between my deck. To that point, I don’t use a lot of bullets or make them fly in to wow the people reading my slides. Instead, I stick to the ideas of using lots of pictures and keeping the text short.

When you look at some of the most public presentations from well-regarded speakers, you find that they follow these same guidelines. They keep their presentations simple and focus on ideas and not text. They try to keep all members of the audience focused, but aural and visual learners. They realize that build slides don’t actually offer anything to the audience aside from showing mastery of esoteric aspects of PowerPoint wizardry. Keep it simple and build your audience’s knowledge, not your slides.