Not all training is created equal. When I hear that "I've tried training my co-workers, but nothing seems to help!" My first question is, "Can I see what your training looks like?"

A quick look at a slide deck, and it's easy to see why training isn't going so well. Most slide decks include information meant for awareness, not training. After spending four hours in a classroom, your co-workers are aware they use Salesforce. They are aware of Global Search and objects. And they are aware that they are supposed to use Salesforce to do their job.

But your co-workers leave training without a clear idea of what their job is, where to do their job, or how to do their job. 

Some of you are naturals in front of a crowd - you know how to roll with surprises and modify how you communicate depending on the audience. But for those of us who aren't as experienced, the tiniest bit of friction or confusion makes us feel like we're failing, and we immediately begin to panic. 

But we don't need to panic. What usually causes us to second-guess ourselves is actually a natural part of teaching and learning. Here are four common moments that are scary and awkward when you're the prestenter, but shouldn't be.

I admit it - I have run my fair share of terrible, boring, ineffective training sessions that made my co-workers cringe.

When I was fresh out of college, one of my responsibilities at my new job was to get new-hires up to speed when they began working on my project. I typically followed these 10 guidelines:

Congrats! Your live training went really well. Everybody was laughing, users were engaged, and your feedback was great - "Best live training I've been to in a long time!"

So... now what?

While discussing best-practices for end-user training with Mike Gerholdt, Salesforce Admin Evangelist, he brought up a great point.

If you only focus on the technology, users will feel disconnected from the process. 

The business process informs the technology and the technology supports the process.

Sometimes, we focus too much on "teaching the technology" and not enough time explaining the process so that the technology -- and the inputs needed -- feel natural.

We couldn’t agree more; however, this brings up a new kind of challenge - what is the best way to teach a business process to end-users? A process map will scare most away, and paragraphs in PowerPoint put everybody to sleep.

"Does Salesforce.com actually work?" That is what some of your resistant users are asking themselves. They also ask questions like, "Why do I need to enter all of this information?" or "Things were working just fine - why change?"

As a Trainer and an Admin, you've been put in charge of answering these kinds of objections. The tricky part is that many of your users don't actually ask these questions out loud - most just don't sign in or update data. 

So, how can we get everybody to "dance?"

Documentation goes by many names:

• Training materials
• Job aids
• User guides
• How-to manuals
• Checklists
• Standard operating procedures (SOPs)

And a few more. But to make things easier for me, I just call it documentation.

And it's clear to me that organizations and teams no longer need to be convinced that having better documentation is important - that debate (if it ever existed) is over.

Right now, the problem many organizations and teams face is creating documentation, and then maintaining it once it's written.

Let me ask you a question - have you ever vented to somebody (or to yourself) any of the following thoughts?

• "Getting people to cooperate with me is like pulling teeth!"
• "Nobody reads any of the training material I make."
• "I need help, but nobody is offering (or willing)."
• "I'm trying to improve things around here, but I can't get any support - nobody listens!"

At one point or another, I have said all of those to either my wife, my co-workers, or my friends during lunch.

And at different times, I would have different reasons for why I just couldn't get through to folks:

The first job I had out of college was working at my dad's medical practice. It was a temporary gig because I had a full-time offer from a consulting firm in Washington, D.C. But since I graduated in December, and the consulting job didn't start until August, I had some time to kill.

So I worked for my dad in Pasadena, CA. I remember the first day at work - I sat down at a computer, received some login credentials for NueMD, and was basically told to