Training Material, Training, and Behavior Modification: Part 3 of 3 - Behavior Modification

(This is part three of a three part series. Part one is here and part two is here.)

G.I. Joe and his friends (e.g., http://en.wikipedia.org/wiki/G.I._Joe) gave cartoon addicts in the mid-1980s United States a series of television public service announcements. The cartoon kids being given the lesson invariably responded with “Now we know!” to which the G.I. response was always “And knowing is half the battle.” Unfortunately, we often forget that knowing is, in fact, only half the battle.

So, let’s you say have some awesome training materials (slides, eLearning module, video, or whatever) and training day goes beautifully. Everyone now knows exactly what they’re supposed to do. How are you going to get them to do it? Periodic and direct reinforcement are key to real behavior modification.

Start by ensuring that reinforcement messages are pitched at the right level. If you want people to learn the theme, then repeat the theme, act out the theme, and make sure the theme is in their words. Don’t start with “It was the best of times, it was the worst of times” to explain the quarterly software bug report trends to executives (although that would be pretty cool) and don’t tell testers to ensure that the “trend in bug reports must have a positive impact on EBITDA.” For example, tell people who work with software bugs about bugs, and their bosses about trends in bugs, and their bosses about trends in application quality, and their bosses about trends in the application portfolio, and so on.

Don’t start from nowhere with your students. I believe it will be somewhat uncommon for you to be teaching people something entirely new (imagine the blank stares in the first calculus class sometime around 1704 or the first Fortran class in 1954!). Even after training, continue to work diligently to identify the gap between what the students are doing and what you need them to do. Then, use that as a stepping stone to build upon your audience’s existing knowledge and skill. Continue to remind them of what they already know and explain to them what you want them to do that’s extra or different. If you make it sound like they must start from scratch, or make them cover old ground, or if you omit some key knowledge, you’re unlikely to get any positive behavior change at all.

Make sure your learners continue to be motivated to learn and change. Make it part of their objectives. If you took the time to train someone on how to do something, you should check to see that it’s getting done. If the students know you’re going to check, they’ll be a little more motivated to learn it and do it. There are few activities more frustrating than standing in front of a class all day, teaching important stuff that the students really need to know, and having them stare vacantly ahead (remember, you can make them put away their PDAs, but you can’t make them like it). A little positive motivation goes a long way.

Unfortunately, so does a little negative motivation. Just as organizations get peeved when some new law generates an unfunded mandate that’s all stick and no carrot, employees get a little perturbed when any kind of “do it or else” message is sent their way. While this kind of motivation may work in the short term, it’s just not worth it. In many organizations, the employees are the company. For consultancies, independent software vendors, application houses, and so on, the biggest corporate asset—the employees—go home every night. In a job market that offers some easy mobility, don’t give them an unnecessary reason to go somewhere else.

The best way I’ve found to ensure ongoing performance is to institutionalize the activity as the way things are done. Don’t make people have to go out of their way to do the right thing. If you’re training software architects to do threat models and architecture risk assessments, then account for that time in development projects, give them the tools they need, and make it’s part of the software development lifecycle. Ensure there’s not only prescriptive guidance for doing it, but that the results of these activities are part of someone’s metrics and the software governance dashboard. It’s the same for teaching developers to improve their development patterns, teaching testers to perform non-functional security tests, or teaching executives how to institute software governance.

Let me mention metrics once again. If you took the time to train someone how to do it, then “it” should probably be part of the metrics that someone tracks. If you taught a roomful of testers how to do some inside→out white-box security testing, then you should probably keep track of how many software flaws they catch as part of this process, along with some trends. You might even want to, for example, track which code bases are exhibiting the most problems and track that back to the composition, training, and automation support for the various development teams. If you can discover which teams are routinely making similar errors due to, say, having a broken unit testing process, everyone wins.

And, by all means, find and encourage the stars. The people who really get it should be groomed appropriately. They may be the next crop of team leaders or managers. If nothing else, get one of those individuals to improve the course material or even to teach the next class.

I certainly don’t mean that you should ignore the stragglers. If some folks have attended training and have received some follow-up attention and still don’t get it, they may simply be in the wrong profession. That’s always a tough decision, but I find it’s usually best for everyone. If someone has arrived at a position where they are failing, even with training and attention, kindly help them find a place where they can be effective. And I do mean kindly; that person may be your boss someday.

Someone must follow up with the instructors as well. Do post mortems after each class and give constructive feedback. Ensure each student completes a feedback form. And don’t ask those silly questions on the form like “Did you enjoy this class?”; that’s just useless. Ask things like “Did you understand why you were here and the problem we’re addressing?” and something like “Will the information given to you today actually improve your day-to-day performance?”. Of course, you also want to ask things such as “Did the instructor communicate in a clear manner?” and “Do you feel this instructor truly understands the material?” and stuff like that.

As some parting advice, keep in mind that it’s not just the individual student that must get something out of the class. For every course you give, someone is paying a hefty bill. Whether you’re a consultant charging by the hour or an internal expert delivering some training to your friends, someone’s paying the price for you and for those students to not be working. That economic buyer needs to get something for spending that money (real money, opportunity cost, or whatever) if you expect it to happen again. Ensure someone comes up with a way to measure training success, that they actually measure it, and that they let the stakeholders know how it went.

“Now we know!”

Leave a Reply



Resources
> Overview
> Your Account
> Podcast
> Blog
> Case Studies
> White Papers
> Publications
> Books
> Security Articles
> Presentations


RSS

About the Bloggers
  • Pravir Chandra
  • Scott Matsumoto
  • Gary McGraw
  • Sammy Migues
  • Craig Miller
  • John Steven
  • Categories
  • Admin (3)
  • Assurance (6)
  • Data Security (3)
  • Defects, Bugs, and Flaws (3)
  • Enterprise Software Security (11)
  • General Interest (3)
  • Governance and Regulation (5)
  • Risk Management (4)
  • Security Features (2)
  • SOA and Web 2.0 (2)
  • Software Quality (4)
  • Software Security (32)
  • Software Security Touchpoints (7)
  • Software Testing (2)
  • Training (3)
  • Archives
  • April 2008
  • March 2008
  • February 2008
  • January 2008
  • December 2007
  • November 2007
  • October 2007
  • September 2007
  • August 2007
  • July 2007
  • June 2007
  • May 2007
  • April 2007
  • March 2007
  • February 2007
  • By Blogger
  • Craig
  • Gary
  • John
  • Pravir
  • Sammy
  • Scott
  • Guest bloggers
  • Recent Comments
  • Rafal Los on Is Penetration Testing Security Testing?: John, Fascinating analysis. I would like to...
  • gem on Three New Books: Thanks Adam (and sorry not to make your role explicit Andrew). I’m...
  • Adam on Three New Books: Thanks Gary! your copy is on its way. Just a little nit, I’m the...
  • Andre Gironda on Is Penetration Testing Security Testing?: From a book I recently read: Functional...
  • Tom Van Vleck on Security And Market Forces: I can’t come up with a number for how much money I...
  • Recent Entries
  • Unsafe at any bitrate?
  • Three New Books
  • Is Penetration Testing Security Testing?
  • Externalizing Access Control Quandary
  • Making a move
  • Links
  • Cigital
  • Silver Bullet Podcast
  • Blogroll
  • 1 Raindrop
  • Fortify Software's Blog
  • Freedom to Tinker
  • In the Wild
  • Jon Udell
  • Michael Howard's Blog
  • Microsoft Security Vulnerability Research and Defense
  • News.com Security Blog
  • Schneier on Security
  • Security Fix
  • SilverStr's Blog
  • Tao Security