1

I seem to run into a little snag when I'm tasked with training a new employee. I think part of my issue is that I have a hard time describing technology things to a person who's computer literacy who is below my level. The other part of the problem is that I'm unable to effectively communicate to my trainee how to think critically about what they just learned.

For example there are certain tasks that require use of multiple software. I kind of see these different software as sets of skills.

For example, the password manager allows the trainee to access their different credentials across all our platforms without having to remember a million passwords. Or rather, the skill of retrieving your credentials.

While another "skill" required is the ability to navigate the file system on pc. Or the skill of navigating the hierarchical structure of our web based management application. And any additional software available to the computer such as word or excel, so on and so forth.

When I train the trainee I usually am tasked with training them how to accomplish the task successfully.

This may involved teaching them how to use the password manager, how to understand the file system, how to use the web based management software and so on. The problem arises when I have to train the trainee on a new task.

Some of the tasks are the same. Retrieving the credentials, navigating the file system.

However it seems that whatever I am doing, I have to re-describe the individual steps to do those tasks that I consider, previously covered, such as retrieving the credentials, or how to navigate the file system.

It's like a step by step guide that repeats these basic tasks.

I feel like my trainees aren't able to compartmentalize each skill as separate entities that come together to make a whole.

If I take the example of baking bread and making toast then it would be as if they see it like:

1. Combine all the ingredients
2. Let it rise
3. Kneed the dough
4. Bake
5. Wait
6. Cut
7. Put in toaster
8. Toast

When they should see it rather like this

A. Baking bread
  1. Combine all the ingredients
  2. Let it rise
  3. Kneed the dough
  4. Bake
  5. Wait
B. Cutting Bread
  1. Cut
C. Toast
  1. Put in toaster
  2. Toast

So that if they wanted to just make toast from already baked bread, they don't have to bake the bread again.

For some reason teaching the skill to Copy and Paste is understood fairly quickly, as it's something that works with most applications the same way with few exceptions, but teaching something that is specific to a piece of software, aka, password management software seems to be difficult.

So finally, what's the question? Is there a teaching/training paradigm that can help compartmentalize different skills, as a series of them are are being taught as a whole of something greater.

closed as too broad by Joe Strazzere, gnat, Telastyn, IDrinkandIKnowThings, Garrison Neely Oct 9 '14 at 14:18

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • I read a book, long time ago... If you read it and followed it to the letter all of the rules listed in that book, then you would get to think critically. Can't remember the title, though... – SJuan76 Oct 8 '14 at 21:15
  • I agree that the question is too broad as defined but overall I think it's a great question with much greater applicability than just The Workplace. – Philip Schiff Jul 27 '17 at 1:10
3

They're not programmers and probably will never "think" like a programmer so stop expecting them to do it. You've been doing the task analysis but then you want them to generalize. You're just going to have to keep creating step by step instructions. If they see how step #4 is the same series of tasks as step #5 of some other utility, that's great. If not, so what?

You see similarities and repeated steps where they do not and you're just frustrating yourself wanting them to think like you. It's probably not going to happen.

Continue to strive to write better instructions. Watch over a test subject's shoulders while he/she tries it out. Take notes. Don't give any prompts - "Pretend I'm not here, but please talk to yourself throughout the process." Get feedback and correct the instructions when they don't understand. If your instructions are in electronic form, you can provide hyper-links to common tasks (How to locate a particular folder on the shared drive.).

It takes time to fully understand things, an with certain jobs, they have too much else to do, so they may not be motivated to "figure it out" the way you do.

  • 1
    There is nothing special about the way a programmer "thinks" that makes them better/worse/different than other professionals. Programmers don't have a monopoly on abstraction or generalization. Whats going on here is a training problem or perhaps an issue with a particular individual. Programmers are every bit as vulnerable as others to rigid/non-general reasoning (ever hear of the "golden hammer" problem?). – teego1967 Oct 13 '14 at 11:41
  • @teego1967 - You're making a lot of assumptions about my answer. I made no claim to a monopoly on this type of thinking and indicated that the OP is apparently dealing with a group that "is" having difficulty grasping these concepts. You make it sound like I think programmers are perfect. – user8365 Oct 14 '14 at 16:13
  • Ok, but if we're talking about assumptions, programming wasn't even mentioned as the kinds of tasks involved here. These are merely described as tasks that involve computers, which today is practically everything. Programming (or the way that programmers might think) has nothing to do with the OP's question. Moreover, assuming the trainee is a normal competent professional, it is impossible that he can't grasp the basic concepts generalizing a task. This is a problem of training and it needs to be addressed as such. – teego1967 Oct 15 '14 at 14:19
3

I think you may just need some more practice in giving training and perhaps you'll need to adjust your expectations about what is normal.

I've been in a situation much like your trainee before when I was taught to use a particular Oracle application (one of their MRP products), I've also been on the other side of the situation when training people up for manufacturing systems. The problem is that your trainee does NOT necessary perceive the same things you are perceiving. In the same way that you may think he doesn't understand the natural segmentation of what you're explaining, he may think that what you're saying doesn't make logical sense.

A trainee needs time to not only digest your explanations, but also to get comfortable enough to ask pointed questions. Many people will allow themselves to silently flounder a bit when they don't understand something believing that they'll "figure it out", but then if you continue your dialog assuming they "got it" and build upon the assumption that the trainee understands the missed concept, the confusion just gets bigger and bigger. It often reachs a point where the trainee is too embarrassed to ask for clarification of a fundamental issue.

One way you can jumpstart this is to give them small but increasingly ill-defined problems to work on. In a friendly, supportive way get them started on performing a task where they do NOT have all the information they need to finish the task, they then can use you as a source of information. It forces them to formulate questions and gives you a clear picture of what is not being understood. This is otherwise known as "learning by doing". It is the best way to learn and also helps the teacher get better at the subject matter and their teaching.

Not the answer you're looking for? Browse other questions tagged or ask your own question.