Things I Learned From Being a Motorcycle Instructor

This blog post was originally published internally at a previous employer, as part of a series on learning to coach and provide feedback to employees.

Introduction

I mentioned in an earlier blog post that one of my interests was motorcycling. In fact I was a volunteer instructor with the Ottawa Safety Council’s motorcycle rider course for about 10 years. I’ve retired from that now, although I still keep in touch with my fellow instructors as friends. That’s me in the back row, right hand side, behind the yellow coat.

The instructors with that organization are a group I was proud to be part of.  They are serious about riding and about teaching riding, and there is extensive training and coaching for the instructors on how to teach and coach.

In this blog post I’d like to share a few things I learned about teaching and coaching from this role. I note that the same lessons seem to apply to other training activities (such as dog training, and teaching martial arts), and I imagine that anyone who teaches or coaches a physical skill, like hockey or skiing, has similar experiences.

Teaching approach

First I’d like to share a couple of the most basic principles the group uses for teaching.

PARDED

The first was called PARDED, an acronym for a process that ensured that instructors spent a minimum of time talking about how to ride, and a maximum of time coaching students who were actually practicing riding.

PARDED stood for Preview, Aim, Reason, Demo, Explain, Demo. It was an approach to teaching a lesson segment, which might go like this:

Instructor: “In this lesson we’re going to learn to turn while starting from a stop. [Preview] By the end you’ll be able to turn right or left immediately after starting from a dead stop, while staying in the marked lane. [Aim] This is important because you need to be able to turn left or right from a stop sign or a traffic light without stalling your bike or losing control of your lane position. [Reason]

“Here’s what we’re going to do.” (Instructor, on a bike, demonstrates the procedure. [Demo]) Then, instructor quickly points out 3-4 important points of the techniques he just demonstrated. [Explain]

“Ok, now that you know what to look for, watch while I demonstrate again.” (Does it again). [Demo]

Then the students get on their bikes and spend time practicing and getting individual coaching.

The idea of PARDED is that a certain amount of theory and explanation is needed, but what we’re really trying to do is establish “muscle memory” so good techniques happen automatically when there is no time to think. And that happens by doing not by listening. So, if half an hour is allocated for a lesson, the students would be doing hands-on practice for 20-25 minutes of that half hour.

I found this teaching technique to be very effective, and I have successfully used it in other contexts. It is very effective for hands-on technical training of computer skills.

Teach the skill, not the test

This was a fundamental policy of the course – and sometimes controversial. Our course ended with a test that served as the student’s road test for their license. However, we consciously did not “teach them to pass the test”. Instead, we “taught them to ride well, and then tested if they had learned that”.

Some of them didn’t pass the test (although our success rate was high – I think something like 95%). Some of those who didn’t pass probably could have passed if they had been drilled on the actual test during the training.

We thought doing that was not in their interest. If a student really isn’t ready to ride in traffic on the street, but we help them pass the test (an artificial, controlled environment), how would we feel if they were then injured in an accident?

I think this applies to career coaching too. We could probably coach people on job interview skills to an extent that they would pass interviews for jobs for which they weren’t really qualified. But that would not be in anyone’s interest.

I’ve had conversations like the following both with people who didn’t pass the motorcycle test, and with people who didn’t pass a job interview:

The motorcycle version:

(them) It’s not fair. I can ride just fine. I just don’t take tests well.

(me) What do you mean?

(them) I can ride perfectly when it’s “for real”. But when I’m under pressure or being watched – the situation in a test – I get flustered and forget.

(me) So you’re saying you can drive a motorcycle just fine unless you are under pressure or being watched. Like, say, driving on the street in rush-hour traffic.

The job interview version:

(them) It’s not fair. I’m qualified for this management job. I just don’t take interviews well.

(me) What do you mean?

(them) I can do the job perfectly when it’s “for real”. But when I’m under pressure or being watched – the situation in an interview – I get flustered and forget.

(me) So you’re saying you can do the job of a manager just fine except for managing your time, responding to questions, defending your point of view, or dealing with pressure? (What did they think a management job was?)

When you are helping someone learn a skill on which they will then be tested, teach the skill, not the test.

Coaching lessons

Aside from the formal methods that we used to teach, I learned a number of things about coaching people who were practicing a skill. These things I learned from watching other good coaches, or being coached myself, or, in a few cases, by watching people doing it badly.

Positive coaching

This is certainly the most important thing I learned about coaching a skill: tell the student what to do, not what not to do.

Telling a student what not to do is not useful. They could do something else, still wrong, and yet be obeying your command to not do that first thing.

This is especially important when correcting an error. Don’t point to or describe their error and say “don’t do that”. Instead, tell them what they should do. Ideally, give them simple targets that they can follow that will cause the desired behavior, and have them repeat that several times so they are developing the habit and muscle memory of doing the thing properly.

Here are a few examples drawn from motorcycle training:

“Don’t look down!”

Students often have trouble balancing a bike when riding very slowly – like crawling along in a traffic jam. Often the biggest cause of this is looking down at the ground just in front of the bike.

We could say “don’t look down”. How is the student supposed to know what that means? They could close their eyes – that’s not looking down. They could look straight up over their head – that’s not looking down. Is that what we wanted?

Instead, tell them what to do and give them a target. I might pick a suitably- placed landmark in view from our training site, and say something like “See that low building over there in the distance? See the chimney on the roof? I want you to look at that chimney while you do this exercise.” Now they are looking level to the horizon and focusing into the distance, which is the behavior I wanted.

The other time students have a problem because of looking down is when turning (especially to the right) while starting from a dead stop. Think, for example, turning right from a stop sign.

“Don’t look at the ground” is not useful feedback – see above. Instead tell them what to do, and give them a target. I would walk 10 or 12 metres away, along the side of the road, point to my own face, and say, “Look here! Look at me!”. Then they would generally have no trouble with their balance or lane position while starting and turning. It was quite remarkable.

“Don’t Pop the Clutch!”

Most motorcycles are standard transmission vehicles, and students would have trouble stalling because they were letting the clutch out too fast. “Don’t Pop the Clutch” is not useful advice. Do students even know what that archaic phrase means?

Instead, tell them what to do, and give them a target. I’d put a cone on the ground about 5 metres away, and say, “Start letting out the clutch until you feel the bike just start to move. Continue to let it out, slowly, at a rate that results in you just finishing letting it out as you pass that cone.”

It might take them one time to work out how slow that is, but after 2 or 3 times, they would be starting perfectly with no stalling.

“Don’t look at the obstacle!”

One of the lessons was to swerve around something on the road – an oil slick, a squirrel, or, in our practice, a traffic cone and, later, an instructor – without hitting it. Beginners would often hit it, or at least come frighteningly close.

An interesting phenomenon called “target fixation” was at play. If you stare at an obstacle while riding, you will likely steer towards it. Realizing you’re going to hit it makes you stare harder, which makes it worse.

Shouting “don’t look at the obstacle” doesn’t help. It only raises the student’s stress level and makes the obstacle even more attractive to stare at.

Instead, tell them what to do, and give them a target. We’d put a small mark on the pavement – a leaf, a bit of tape – in the safe path, such as 1 metre to the right or left of the obstacle, then say “look at this mark while you are swerving”. They’d ride right over the harmless mark, and not into the obstacle.

There are many other examples, but this is not an article on how to ride a motorcycle, so I’ll stop. But I’d like to repeat that this is the most important thing I learned about coaching: Don’t tell them what not to do. Tell them what to do, and give them a target.

Correct one thing at a time – more important first

It’s common to see a coach giving someone feedback in which they list every single thing they saw done wrong, as though there will never be another chance.

Here’s a paraphrase of feedback I once heard an instructor trainee giving a student after a braking exercise.

You were looking down, and your wrists were bent, and you gave it too much gas, and you shifted gears too soon, and your knees weren’t against the tank, and you stomped on the rear brake, and you were sitting too far back on the seat, and your foot wasn’t centered on the foot peg.

What did they think the student would do with this feedback? Make a list and consult it while riding?

One of those errors was far more serious than the others (stomping on the brake). The senior instructor working with the above trainee stepped in and corrected just that error, giving the student instructions on what to do instead. Once they were braking safely, they tackled the next most important problem, and so on.

Never demonstrate the wrong way to do something

Our teaching method made heavy use of demonstration, showing how to do a given skill, not telling how to do it. This was supported by an important rule: always demonstrate proper technique, never demonstrate incorrect technique.

Why on earth would one ever demonstrate incorrect technique? It seems obvious. But, sometimes, a novice instructor would think along these lines:

I’m trying to teach that a certain technique (like using only the rear brake when stopping) is a bad idea, and the students aren’t convinced. Why not do it wrong so they can see it’s a bad idea?

e.g. to show people how ineffective it is to use the rear brake alone, I’ll demonstrate trying to do a high-speed stop using only the rear brake, and they’ll see that it doesn’t work well.

We were very firm that instructors should never do this, for several reasons:

Liability: How would we explain it if your demo goes wrong and you are injured, while doing something that you know you shouldn’t do? What if, in crashing, you injure someone else?

Anchoring: There is a psychological phenomenon that people tend to remember and recall the first things they see or hear, more than other things. Demonstrate the wrong way to do something before demonstrating the right way, and we risk that the student will remember only the wrong way, and will forget that it is wrong.

One-upmanship: Your demonstration won’t convince people who are already convinced that the technique in question is, in fact, the right way to do things. There is a risk they will try to demonstrate that you are wrong by using the bad technique and making it work. Then there is a high risk they’ll be injured.

Diversity in class

We taught in small groups, two instructors with 5-6 students. In every group there were “good” students and “less good” students – those who easily picked up the skills and excelled, and those who struggled.

It was tempting to spend the majority of coaching time working with the lowest- performing students. After all, they need the most help. But this would be an error. Don’t neglect the good students.

  • The good students are also paying customers, and they deserve time and attention. Our objective isn’t to bring all students to the same level, it’s to improve them all. Even the good students should leave the course better.
  • The bad students are learning by watching you coach the good students too. For some students that’s actually more effective, since they are not defensive about feedback they hear you giving to someone else.

Peer performance is powerful. Every time a good student executes a technique properly, that’s like you doing another demo, and the bad students are learning from that.

I used to have the students in my group take the test in what I said was “random” order. I put “random” in quotes because it wasn’t quite random. I would secretly pick the student who I considered the best rider to go first, so the other students were seeing a demonstration of the test being done well by a peer – good for a final clarification, and to establish the confidence that it can be executed successfully.

Others?

I learned a lot from teaching adults a physical skill, and a lot of what I learned has been applicable in other coaching situations. I bet others who teach or coach have similar experiences, and I’d like to invite you to share – in your own blog, in lunchtime presentations, or in the comments section here.

Develop a reliable estimate during an elevator ride? Yes you can.

Colleagues conversing in an elevator

“Elevator Speeches” are an important tool in management. By chance, you find yourself in an elevator with a senior decision maker for 30 seconds. Can you do something useful with that time? You should have an “elevator speech” ready, or be capable of generating one instantly, for several topics, such as:

  • Who are you?
  • What do you do?
  • What are you working on?
  • How’s it going?
  • Anything you’d like me to know?
  • Do you think we could problem-or-concept-you’ve-never-heard-of-before-this-moment? What would it take?

This post talks about an important “elevator response” skill – quickly estimating costs by using rules-of-thumb worked out in advance. It uses Information Technology investment as the working example, but the concepts apply equally well to other fields, although you may need to recalculate some of the rules-of-thumb used.

You can develop estimates that are accurate within a certain range, and that are better than guesses, in a few seconds if you remember some rules of thumb, and if you practice and refine your technique.

Detailed cost analysis and proposal-writing is important, and takes time, and there is definitely a place for it. But fast estimates are used to make high-level strategic decisions more often than you might realize. You should develop this skill.

Nightmare Scenario

If this hasn’t happened to you, it will.

You follow another person onto the elevator and, as the doors close, you realize the other person is your Deputy Minister (private sector: company President), on their way up to the board room on the top floor.

The deputy says hello and you introduce yourself. Then,

Deputy:

So, what do you do?

… Oh, you’re the leader of the IT development organization? Great. I’m on my way to a meeting right now, and it just occurred to me that it might come up that we need a system to do requirement-you’ve-never-heard-of-before. What would that cost?

You:

I can send a business analyst to get your requirements right away, and have an estimate for you by end of week.

Deputy:

No, I’m meeting the Minister now. What’s your best estimate, now?

What often happens next

A number of reactions to this high-pressure situation are rather common, including, “No response”, “Rote inflated response”, and “Poorly informed lowball response”. Here’s how those typically go:

No response

You can think of all kinds of things that you don’t know right now. You don’t want to be anything but exact and perfect. So, you respond, “Sorry, Deputy, there’s no way to give you an estimate without going through our requirements and analysis process; we have to make sure we don’t miss anything.”

The Deputy says, “OK, thanks anyway”. When the opportunity arises later in the day, they remain silent, and the opportunity is lost. The Deputy remembers that you were unable or unwilling to do a fast estimate.

Rote inflated response

Young man with greedy, scheming lookYou can think of all kinds of things that you don’t know right now. You’re terrified that you’ll be held to an estimate that is too low and not have the time or funds to succeed; but “no one was ever fired for having money left over”. So, you “take a conservative guess then double it”. Essentially, you’re going to ask for as much as you think you can get away with. You can return whatever is left over at year-end, or use it for something else.

Most small systems probably cost $150K so you say, “It might be $300,000, and $100,000 per year ongoing?  Maybe more.” The inflection at the end of the sentence implies the “question mark”, re-enforcing that you’re really not sure.

The Deputy responds, “Really? Wow. OK.” Again, they don’t take the idea forward – it’s more money than they’re willing to invest – and the opportunity is lost. Or, even worse, they propose the idea, and are not believed. Your group’s reputation for inflated estimates increases.

Poorly-informed Lowball response

You can think of all kinds of things that you don’t know right now, but you hate to pass up an opportunity to get new work. You’re terrified that if you don’t get awarded this project, it might go to someone else and you’ll lose control. You know they sell a software package that does something like this at Best Buy for about $350 so it must cost something like that to buy or build. You’d need a computer ($3000 at Best Buy) and a couple of days to install it.

So, you respond, “Maybe $5000?”. (Again the spoken question mark.)

And the deputy responds, “Fantastic, thanks! Assume we’re a ‘go’ on this.”

Half a year later, a note written by the Deputy on a returned briefing note says, “You need another $50K and to hire another person? You said $5K!”  By the way, it’s performance review season.

What your response could be

You think for a few seconds while the elevator floor indicator ticks by: 3… 4… 5. Then, taking a deep breath, you say,

This is only an estimate – about $65K one time – that’s $35K salary and $30k capital – then $20K expense ongoing starting in year 2 for as long as the system is in use. There’d also be a small cost – around $10K – to decommission it at end-of-life. I’d need to get back to you on what current project would be sidelined to do this with existing staff. We could avoid that by using a consultant instead, for about $30K more. Don’t forget that the users might require training, and there would be an opportunity cost to take them off their jobs for that.

I could explain where those estimates came from if you like, or could get back to you with a more detailed analysis in a couple of days.

Looking thoughtful, the Deputy responds, “Thanks, that’s enough detail for now. I’ll get back to you if I need to follow up.” The project gets approved, and the actual costs come in within about 15% of this estimate. You’ve built up some trust in your estimating skills.

Where did those numbers come from?

Those figures were not fiction and they were not a guess. They were an estimate based on sound and defendable reasoning.

  • The labour estimate assumed this simple system would take one developer 3 months. The 3 months came from your experience with small systems. (Know how many months small, medium, and large systems usually take.) $500 per day for 60 days gave us the $30,000. (See below for where the $500/day figure came from.)
  • The capital cost assumed that we need to run this system on a server costing $10K. (Know your standard server costs!). We’d need 3 – development, production, and testing.
  • The ongoing expense assumed 1 day every 2 weeks from an employee (which is 10% of a $100K person, for $10K), and assumed 20% of the server cost annually for renewal, for an extra $6K. We rounded the $16K up to $20K. (20% of purchase cost is a standard rule-of-thumb for annual maintenance costs of IT equipment.)
  • 10% of purchase cost is a good rule-of-thumb estimate for the decommissioning of a system at end-of-life.

Do the homework for your domain

You can do estimates like that in a few seconds if you already know the various rule-of-thumb estimation values involved. These might be different for your field – but you can work them out, and you should.

Labour Costs

For labour, know how long typical tasks take, and know roughly what your staff costs are.

In this example, we’re talking about technically-skilled professional staff (CS or ENG). CS salaries range from $66K to $124K – but it’s a bell-curve since most of your staff are in the middle of this range. (i.e. you may have a few CS-01s and a few CS-05s, but most of your staff are probably mid-range, like CS-03.) If we do some kind of weighted average, we get an average salary of $93K. Add the 25% “benefits tax” that our finance group usually includes in calculating salary budgets, and we get about $117K as the annual loaded labour rate for a CS.

Do some simple math and it turns out that there are about 112,000 minutes in a standard work-year. That’s really close to the 117,000 dollars above, so the loaded labour rate for your average technical person is $1.04 per minute, or “a dollar a minute” to a pretty good approximation. That’s about $60 per hour, and just under $500 per day. Double that if you are using contractors – you are paying extra for their profit margin, their administration costs, and for not making a lifelong employment commitment.

$1 per minute for professional staff is a useful rule-of-thumb estimator for many purposes.  Use $2 per minute for Executive staff.

As an added benefit, this is useful to help you keep an eye on how long some decisions take.  If 5 technical people spend an hour deliberating, that’s 5 x 60 = $300 in labour costs.  5 executives: $600. Was that $600 spent making a $200 decision?

If your projects make heavy use of staff in a very different salary range, repeat the calculations above and know your per-minute, hourly, and daily cost for average staff.

Equipment Costs

If you are an IT manager, it’s important you know your average server cost; and don’t forget to allow for more than one if you need a development environment or spares.

If you are virtualized, or using Cloud, know the average cost to add an application, instead of pricing servers. If you are cloud-based, your cost will be expense instead of capital, and there won’t be separate “ongoing” maintenance or decommissioning costs – those are included in the Cloud service fee and are, in fact, a big part of the reason for using the cloud.

If you are not in the IT field, know what other equipment costs are often associated with your work. Office space? Vehicles? Specialized equipment? You might even have no standard equipment costs.

Grow your estimating skills using feedback

Do an estimate like this at the start of every project, even if you are not being cornered in an elevator. Do it yourself, with little or no research, before your experts do detailed costing and planning and fill your head with distracting details.

Then, after every project, compare what actually happened to your estimate. Of course it was wrong – it would be surprising if it wasn’t. But was it spectacularly or dangerously wrong? If so, why? What did you forget or estimate incorrectly? Learn and improve.

Important strategic direction-setting decisions are made with very coarse estimates all the time. Learn to use this process to your advantage by feeding it with good data.

Lessons from Star Trek

At my last few employers I used to blog regularly and encourage other executives to blog. I will be reproducing slightly modified versions of some of those blog posts here. This one was intended to be a little “tongue-in-cheek” because I had a bit of a reputation as a nerd.  It discusses leadership lessons we can learn from watching Star Trek. To my surprise, it turned out to be, by far, the most popular blog post I wrote, and received, by far, the most comments.

Science Fiction Confession

I have a confession: I’m kind of a science-fiction nerd. I certainly have that reputation among my colleagues and get good-natured jokes and ribbing. Sometimes I re-enforce this by “stepping in it”. But, come on, when someone misidentifies a Jawa as an Ewok, or incorrectly mixes Star Trek and Star Wars metaphors, what is a person supposed to do?

Among the Sci-Fi I like, I like Star Trek. I used to rush home from school to catch the new episodes of the original series, and I was thrilled when the series rebooted years later.

I like STNG

My favourite Star Trek series was The Next Generation – known to fans as STNG. I liked it best, and I’m going to discuss some of the aspects I liked that I think are relevant to our work here. I’ll leave the pure fiction fandom for social conversation times.

First, for people familiar with the Star Trek franchise and the STNG series, when I say, “I like STNG”, I mean the “real” episodes. Not the first season, except for how happy I was that anything returned at all. (It’s amazing that there was a second season considering how bad the first was.) And not the silly episodes like the holodeck adventures – I always assumed that those were fillers during creative lapses and during the writers’ strike, although the holodeck episodes in the Deep Space Nine series were worse.

Second, for everyone else: yes, I know it’s fiction. That doesn’t bother me. We can appreciate good writing and can learn from and admire behaviours exemplified in good fiction. And I think the best STNG episodes were good fiction.

I like the world view Star Trek, especially STNG, presented, but my current comments will be limited to ways that world view applies to leadership and technology.

Leadership

The senior leaders in the series demonstrate a variety of leadership characteristics – some good, some bad. We can learn from all of them – but I’ll highlight a few of the good characteristics here.

Values

One of the guiding principles for the lead characters is to have a clear set of values, and to stay true to them. Their employer, The Federation, itself has a simple value statement – the “prime directive” which, interestingly, guides some episodes but is deliberately set aside in other episodes in favour of the personal values of the leaders. Captain Picard seems to have two personal values that override all other concerns.

One is “truth” – in several episodes he emphasizes that nothing is more important than seeking and revealing the truth, and he forgives serious transgressions when staff are open and truthful about them. An episode providing good example of this is “the Pegasus”, which ends with Picard saying to his first officer (while releasing him from confinement),

“When the moment came to make a decision, you made the right one. You chose to tell the truth and face the consequences. So long as you can still do that, then you deserve to wear that uniform. And I will still be proud to have you as my First Officer”.

Another good example is “The First Duty”, with

“The first duty of every Starfleet officer is to the truth… it is the guiding principle on which Starfleet is based.”

(It’s hard for me to recommend that episode as I didn’t like the Wesley Crusher character, but it is a good story.  Here’s the scene.)

The other is the fair and ethical treatment of people. While this is shown in many episodes, I particularly like a couple that involve Commander Data. I like “the Offspring”, where Picard disobeys an order, stating,

“Order a man to hand his child over to the state? Not while I’m his Captain”.

In “The Measure of a Man” Guinan guides Picard to realize that the Federation’s attempt to define Commander Data (a sentient machine) as “property” has deeper implications:

“. . . Whole generations of disposable people.”

“You’re talking about slavery.”

“I think that’s a little harsh.”

“I don’t think that’s a little harsh, I think that’s the truth.”

Strategy vs implementation

The leaders in the series do a good job of separating strategy formulation from implementation. The hard part, and where their attention goes, is in deciding what to do in a given situation. Actually doing it, once the decision is made, is only work, and is facilitated by their technology.

Roles and the chain of command

The Canadian public service has the unofficial slogan, “Fearless Advice, Loyal Implementation”. Many STNG episodes demonstrate these two roles: when options are being sought, provide advice, and argue for your point of view; once a decision is made, execute that decision.

While there are many episodes where this is demonstrated as a matter of routine procedure, the episode “Gambit, Part II” addresses it directly, when Acting Captain Data reprimands Worf.  It’s also a great example of a manager dealing with a performance problem immediately, firmly, clearly, and in private.

Communicate in the audience’s language

The series contains many examples of the importance of communication, especially of adapting it to the circumstances and of speaking to each audience in language they will understand. One is firm – even threatening – with bullies and Klingons, and one quotes regulations to hyper-bureaucrats. The best example of this is the episode “Darmok”, where the entire episode is based on the concept of a species whose language uses a completely unfamiliar structure, and learning to communicate with them.

Technology

Finally, a technology leader can hardly talk about Star Trek without talking about their technology. Some of their technology (e.g. teleportation and faster-than-light travel) is forbidden by the laws of physics as we presently understand them. Most science fiction writing has this problem – there would be no aliens or interstellar travel in stories without some way to violate these laws. While the series depends on these “forbidden” technologies, I like that the writing acknowledges this dilemma in subtle ways.

For example, a physical rule called the Heisenberg Uncertainty Principle prohibits macro-scale matter teleportation such as the Star Trek “transporters”. Clearly the writers are aware of this, because several episodes make passing reference to a system component called “the Heisenberg Compensators”, which presumably addresses this. I like that gesture.

However, a lot of their technology is not impossible in that sense – it’s only hard, or expensive, or something we don’t know how to do yet, but that they have figured out. The underlying premise is that they have a vast, almost unlimited energy source available. What could you do with nearly unlimited quantities of energy? Quite a lot.

Their technology, and its extreme adaptability, is enabled by highly effective system architecture. A real-time graphic display shows the operation of systems, at any level of detail. Interfaces between systems and components are standardized, so you can implement new interactions between systems merely by sketching what you want on the interactive display. “Let’s route the output of this system through this processor, then feed it into this system over here”. There are no concerns about how to do that – you draw the desired flow of energy or information and it just happens.

When I first watched these shows, this kind of flexible system interaction seemed like a distant future vision, probably fiction. Now, however, Cloud computing is close to making this a reality.

The series also contains numerous important nods to security. The ease of accessibility and connectivity of systems also presents a security vulnerability, and this vulnerability is the basis of some episodes. Hacking, viruses, authentication, encryption, and privilege management are all key to various stories. This is a good reminder to get the security right.

STNG is replaying on a variety of networks – Netflix, Crave, etc. Skip the first season (except as the basis for certain drinking games) but have a look at some of the episodes mentioned above. Even if you don’t become a fan, there are good lessons to be found.