Why Your Presentation Stinks (Part 2)
Last time, we talked a little about making certain your presentation has a point — or a porpoise, as the case might be. This time I want to talk about a few other common mistakes I see network engineers make when building presentations, and actually presenting them.
First, you put too much text on your slides. I know you’re afraid you’re not going to remember everything you want to say, but that’s no excuse to have a 500 word essay on every slide. The bullet points on a slide are supposed to be just that — bullet points. They’re supposed to remind you of what you mean to say at this point in the presentation, not to be the actual words you’re planning on saying.
Okay, I understand we’re running head in to another problem here — what about folks who print my presentation out and take it home to read it later? That’s what hidden slides are for. Put all the text you really want to put into a slide on a hidden slide just after the slide itself. Then pull out just enough words for you to remember what’s on the hidden slide when you’re doing the presentation. Continue reading
Show 218 – OSPF Design Part 2
A long time ago, Packet Pushers ran an OSPF Design Part 1 show. That show went after the default design guides that network engineers have been reading for years, making the big point that you can scale a single OSPF area quite large indeed. But…that’s not the entire story about OSPF areas. Areas still have their use cases, […]
Author information
The post Show 218 – OSPF Design Part 2 appeared first on Packet Pushers Podcast and was written by Ethan Banks.
Thinkers
Big thinkers think about giving, doing, and ideas. Small thinkers think about getting and having. If you’re comparing to or gossiping about others — you’re not thinking at all.
Business Drivers Talk at Interop 2015
This talk is a case study around some of the issues and solutions for TelePost Greenland. I’ll have to give credit to Denise Donohue and the folks there as I go along through the slides, but it’s a unique network with some extreme requirements — and therefore some interesting solutions.
Why Your Presentation Stinks (Part 1)
Powerpoint doesn’t stink. Our presentation skills do. So how do we fix it?
First, you must decide: what do I want this presentation to be? We’ve all seen the brilliant TED talks about new ideas. We’ve all seen the really cool sample presentations from those online presentation sites about someone’s trip around the world. When you’re looking at those talks, though, remember this: they are selected out of millions of talks for their content, and their content fits their format. I’ve seen folks do fairly standard slideshows with Prezy. It doesn’t work. I’ve also seen people do “let me tell you about my trip” presentations with Powerpoint. Again, it doesn’t work.
So, just like network engineering, pick the right tool for the job. Since most of an engineer’s presentations aren’t going to feature exciting trips down the River of Doubt, or even up Doubtin’ Mountain, we’re probably pretty safe to stick with a fairly standard presentation package — slides, warts, and all.
Yes, it’s important to get the flow right. I once stood in for a presenter who’d lost his voice — the material was router architecture (hardware and software), so it’s a topic I know well, so I wasn’t Continue reading
Powerpoint Doesn’t Stink
“Presentations are just a waste of time.”
“Powerpoint stinks.”
“Can’t we do something other than another long, boring, presentation?”
“We should just ban Powerpoint.”
If I had a nickel for every time I’ve heard someone complain about Powerpoint, or presentations, I’d be rich enough to quit work and stop blogging. 
Isn’t it about time we were honest with ourselves, though? Isn’t it about time we told the truth about this particular problem? Blaming Powerpoint for bad presentations is like blaming word processors for badly written books.
The problem isn’t Powerpoint. The problem is the person you see every morning looking at you in the mirror. The problem isn’t the tool, it’s that we stink at organizing and presenting our thoughts in any sort of reasonable way. So let’s talk about how to build a better presentation.
To begin: forget everything you’ve ever read in a book about making elevator pitches, making a presentation that impacts, with dash, flair, or whatever. There is a set of presentations that present as a story, with flair and dash, and there is another set that just doesn’t.
As an example, I was the Routing Protocols SGM for Cisco Live for Continue reading
The Degree or the Certification: Answering the Question
Okay, finally, I’m going to answer the question. For some value of the word “answer,” anyway. I’ve spent three weeks thinking through various question you should be asking, along the way making three specific points:
- Stop asking “should I get a degree or a certification,” and start asking “what do I want to learn next.” Neither degrees nor certifications are a “final point,” in education (terminal, in the vocabulary of the educational world).
- Learn to see beyond the question of specific technical skills — to think about the underlying skills, like abstraction.
- Stop acting and thinking like a widget. You are more than a money making machine.
Okay, so how do I actually decide?
First, ask: where do I want to go? Who do I want to be as a person, overall? This question needs to be a “bigger life” question, not a narrow, “how much money do I want to be making,” question. One of those other turning points in my life as an engineer was when Don S said to me one day, “When I’m gone, people aren’t going to remember me for writing a book. They are going to remember me as a father, friend, and Continue reading
The Degree or the Certification: You are Not a Widget
One of the things that bothers me the most about the Internet of Things (IOT) is how blithely we slip from talking about objects as things to people as things. Among all the things I do not want to be, a “thing,” attached to the “Internet of Things,” is not one of them. What does this have to do with the question of whether you should get a degree or a certification? Simply this: You shouldn’t treat yourself as a widget, either.
Let me explain.
I can’t count the number of times I’ve heard people say, “You should get a certification because it provides more bang for the buck.” In fact, in one rather amusing line of reasoning on the subject, Peter Thiel (who started the Thiel Foundation to encourage smart young people to quit college and take up a career instead), said in a recent interview:
Educational institutions are far too often interested in churning out graduates (i.e., getting their money) without imparting the ability to think rather than just work the system.
To paraphrase, you should opt out of college because colleges are just in the game to make money off you, and you’ll make Continue reading
The Degree or the Certification: Learn to See
This week I was reading through various RSS feeds, and ran across a couple that fell within the scope of last week’s topic. So, rather than moving on to more practical concerns, as I had planned to do — well, I thought I should respond to some common lines of thinking.
First of all, the IT space is in constant change, and the speed of change is just increasing. That change manifests itself in new technologies coming about, and new processes associated with the technologies. Secondly is work experience: What you’ve done in the past is not necessarily useful for the future. Like in the financial realm, where it’s recognized that past performance is no guarantee of future performance, it’s also true in the work environment. When you look at past experience, it’s already dated, from a technology perspective. -IT Business Edge
Now, I’m not one to argue with the idea that the IT world is always changing. Certainly new technologies come, and old technologies go. As the saying goes, legacy just means what you’re currently installing. And certainly there will always be a need to learn the new language, the new command line, the new hardware choices, the Continue reading
The Degree, or the Certification: First Thoughts
Having just come off doing a presentation on “being a great engineer,” I can tell you what the number one question people asked was: Should I get a degree, or a certification? In fact, several people were irritated that Denise and I were even talking about anything else, because it’s the only question that counts.
Let me counter that thought. If you’re asking whether you should get a degree or a certification, you’re asking the wrong question.
It’s not that I don’t have anything invested in certifications. I hold a CCIE (2635), CCDE (2007:001), and CCAr. I’ve written questions for the CCIE. I was on the original SME team that invented the CCDE and CCAr certifications. I’ve taught certification classes, written certification books, and generally been involved in the certification world for a long time.
It’s not that I don’t have anything invested in college, either. I have one four year degree, two Master’s degrees, and I’m currently working like crazy to gain acceptance into an PhD program (Philosophy, in Apologetics and Culture, if you’re curious). I’ve taught as an adjunct in the NC State MS program, and I’m on Capella University’s advisory council. I teach on a regular basis Continue reading
The Inner Ring
An avid reader of C.S. Lewis, I often find his thoughts and statements applicable far outside his original intent. For instance, in 1944 (at least a few years before I was born I feel safe to say), he gave an amazing lecture at the Memorial Lecture of King’s College, University of London. The entire speech can be found here, but to gain a sense of his statement, consider the following quote:
And the prophecy I make is this. To nine out of ten of you the choice which could lead to scoundrelism will come, when it does come, in no very dramatic colours. Obviously bad men, obviously threatening or bribing, will almost certainly not appear. Over a drink, or a cup of coffee, disguised as triviality and sandwiched between two jokes, from the lips of a man, or woman, whom you have recently been getting to know rather better and whom you hope to know better still—just at the moment when you are most anxious not to appear crude, or naïf or a prig—the hint will come. It will be the hint of something which the public, the ignorant, romantic public, would never understand: something which even the outsiders Continue reading
Write Like You Mean It (Part 2)
In the first part of this two part series, I talked about why it’s important to learn to write — and to learn to write effectively. But how do you become an effective writer? I started with the importance of reading, particularly difficult and regular reading across a broad array of topics. Is there anything else you do to improve your writing skills? Yes — specifically, get yourself edited, and get some practice.
Hey — I’m a pretty good writer, why do I need to get myself edited? After all, I’ve written nine books, hundreds of articles, tens of research papers, and… But that’s just the point, isn’t it? I wrote several large papers (at least I considered them large at the time) while I was in the Air Force, but they never seemed to have the impact I thought they should have. Weren’t they well written? Weren’t they well organized? Well researched? As it turns out, no, not really. I started on my first white paper just after I’d started in the Cisco TAC, reading through the EIGRP code and writing a paper — for internal use only — based on what I could find. Done and I Continue reading
Write Like You Mean It (Part 1)
Engineers are supposed to be able to gather information, arrange it in a way that makes sense, and then propose a solution that actually solves the problem at hand — right? So why is it I’m almost constantly astounded at the lack of writing skills in the engineering community? Why don’t engineers know how to write, given the almost complete overlap between the way the engineering process is supposed to work, and the way writing is supposed to work?
I suspect there are a number of reasons, probably foremost of which is that engineers don’t think in the logical chains we like to believe. Engineers are too often caught in the modern “search engine world” — find a thesis, search for a few exports to support your belief, and declare the issue decided. We’re sorely lacking the serious interplay between ideas, the pros and cons way of thinking, that exist in many other intellectual pursuits (though honestly, on a decreasing level every day).
If you need some encouragement, let me put it another way: learning to write will not only enhance your thinking skills as an engineer, it will also advance your career. Seriously.
What to do? Well, we can’t Continue reading
Get Out of the Way
I have a lot of memories that have emerged from my years as a network engineer — from funny stories to profound moments to those times when I felt like a complete idiot (because we’re all idiots sometimes). One of those formative moments was when I was agonizing over the decision to leave the Global Escalation Team in customer support and move into an engineering focused role. I agonized over the change for a number of reasons.
I was moving out of something I knew well, directly supporting customers in a very real way. The Escalation Team was the last stop in customer support. If we couldn’t solve it, it couldn’t be solved. That meant a lot of high pressure customer interaction, doing troubleshooting work on really hard, really big problems. I learned a ton. The Escalation Team was also the top of the hill in my world. There wasn’t anyplace, really, I could imagine wanting to be more than working directly with customers, being able to say at the end of the day, “I helped someone solve a real problem,” or even better, “I helped someone learn how to solve a real problem.” Not only for external customers, Continue reading
Jim — I’m an Engineer, not a…
Doctor McCoy, on the original Star Trek series had a signature line — he was forever complaining about this or that with the exclamation that he was just a doctor, and not a… Well, whatever, from shuttle driver to politician.
And how many times, in my career, have I wanted to stop in the middle of some meeting and scream, “Jim — I’m an engineer, not a politician!”
After all, there’s some sense in which engineers become engineers because we’re focused on the problem at hand, we’re focused on the technical issue, not the people issue. I once saw a cartoon that expressed the feeling in the technical community almost perfectly — an engineer talking to her manager, who has apparently just been told she needs to work on her “people skills.” Her answer? “I only went into computers in the first place because I don’t like people.”
Exactly.
And there used to be a time when engineers could get away with this. There was once a time when IT was in the basement (we used to joke about putting on the asbestos suites when going down to the basement to get to our desks in one Continue reading
What Good is UML?
A friend of mine — Tony P to be exact — recently talked me into reading up on UML. I hadn’t worked a lot with modeling languages in a serious way before, but I took the bait and read UML Distilled (Safari Amazon). Okay — this is actually interesting stuff. First, a short review of the book itself.
There are, according to the author, two sorts of UML models. The one advocated here is sketchup, which is used to outline a process or the relationship between various components. There is a stricter version of UML that can actually be compiled into software, but I immediately attached the PowerPoint compiler to this in my head (right or wrong, there’s something about moving from a model to a product without anything in the middle that just doesn’t seem right to me — maybe I’m just an old fogy or something). The progress of the book is useful, moving from the basic concept of modeling languages, a history of the UML, and finally through several constructs within the UML. The author attempts to take you through enough constructs to get you to the point of being able to use the UML Continue reading
What I Learned by Being Laid Off
There’s nothing quite so unnerving as being laid off. I know, because I’ve been let go in a “limited restructuring” twice in my life. Through the process, I learned some “life lessons,” that apply to just about every engineering in the world. While I’m safely ensconced in a great place at Ericsson, I thought it might be useful to reflect on the lessons I’ve learned — especially as it seems to be layoff season in other places (or maybe it’s layoff season all the time?).
First, it doesn’t matter if it’s about you, the politics, or just a random event. I still harbor a suspicion that both times I was laid off there was more going on in the background than just “we don’t need your services any longer.” There were probably politics. On the other hand, the politics in these situations are always bigger than you, no matter how personal it might seem. There’s always some back story, there’s always some power play in progress, there’s always some internal struggle.
But the truth is — it doesn’t matter. You can either stew on the past, or move on with your life. Stewing in the past isn’t going Continue reading
Jack of All Trades
“Jack of all trades, master of none…”
How many times have you heard that in your life? In your career as an engineer? I’ve probably heard it hundreds of times, if not thousands, from working on RADAR and various sorts of radio and other electronics in the US Air Force to as recently as last week. There seems to be a feeling that if you can’t know one thing really well unless you somehow give up on knowing a lot of other things — perhaps there is some sort of limiter in our brains that keeps us from learning more than a certain amount of “stuff” in a single lifetime, or some such nonsense. We’ve all seen the Sherlock Holmes moment, for instance, when Sherlock says something about not remembering something because he has so much other stuff to remember.
And we come back to this idea: Jack of all trades, master of none.
Now I’ll readily admit that I only have so much time to read, and therefore to learn new things. I have four or five wish lists on Amazon, each of which has more than 100 books on it. I have a reading list in Logos Bible Continue reading
Show 155 – Integrating OTV, FabricPath & LISP – Sponsored
At Cisco Live 2013 in Orlando, Packet Pushers co-hosts Ethan Banks and Greg Ferro sat with Nexus 7000 champion Ron Fuller and network design expert Russ White to discuss how, when and why you might choose to deploy FabricPath, OTV, or LISP. In particular, we get into the specifics of what each protocol does, where […]
Author information
The post Show 155 – Integrating OTV, FabricPath & LISP – Sponsored appeared first on Packet Pushers Podcast and was written by Ethan Banks.