Learning At Work

My entry to the Work/Learning Blog Carnival May 2008.

When it comes to training/ learning at work, what you need to learn is always predetermined and in most cases how you need to go about learning is also decided, you like it or not.

When you enter an organization what you need to learn is determined from your job responsibilities. For example an Instructional Designer needs to know the basic Instruction Design Principles, must know how to do Analysis and Design and create a Storyboard, must write well and so on. A Technical Writer on the other hand must be comfortable learning about technology, must know how to use authoring tools and must write well. Every job has some basic skill requirements and the training agenda is set based on these requirements.

in a large organization you are put through a series of training sessions depending on your job role. For example a Technical Writer mostly has to go through training sessions covering standard and guidelines for writing. authoring tools and some basic introduction to the technology he/she will be working on. Most often the emphasize is on the language and tools the writer would use, when the emphasis must be on the know-how of the technology for which the writer would be writing documentation.

In my opinion basic writing skills is basic requirement for any writing job. With ample initiative and little practice anyone can learn to use any tool. Therefore including language and tool training in the training agenda does not make sense. No one can learn how to write or how to work with a tool in a day or two. It has to happen with practice and over a period of time.

It is important to identify what is of utmost importance for a person to do his/her job well and mentor him/her accordingly. I use the word mentor because I do not think training sessions which happen for 2 or 3 days can do much.

What I have come to realize is that apart from some basic skills, there are some other soft skills that you need to do work on to do your job effectively.

To do my job well, I need to know the technology very well and above all I need to be very good at problem solving. I think these are of utmost importance when it comes to doing my job effectively.

In my job there have been so many instances where I have had to think hard on something that required problem solving skills more than my basic skills.

When it comes to problem solving, the challenge here is to identify the problem first and then find out how to solve it.

For problem solving, more than an individual effort it is collaborative effort that works very well.

For example me and my teammate have been working on the documentation for Product A for quite sometime now. Product A is a stand alone product. Product A also gets embedded within Product B.

Therefore documentation for both needs to be shipped.

The basic features of Product A both as a stand alone product and within Product B remain the same but for a few differences.

We wrote the entire help manual keeping in mind the stand alone Product A. We thought we could use the same content for its integration within Product B. Obviously we did not want to make two copies of the same content.

We kept thinking about writing for Product A all the while because we thought we can use the same content as it is for Product B. But then when we actually started thinking about it we were faced with a big challenge.

Our documentation was basically procedures on how to use the features of the product.

We realized that the first instruction in all the procedures written for Product A was very specific to the stand alone Product A and was completely irrelevant to the product embedded within Product B. The rest of the steps remained the same for both.

We did not want to duplicate content and we could not use the content as it is.

This was indeed a big challenge.

What we first did was to make a list of differences between Product A and Product A embedded within Product B.

This helped us attack the problem in an organized fashion. Once we listed the differences we were clear about the pain points.

As mentioned earlier the first instruction in each procedure was the problem. The first instruction was about how to access a particular feature which was common in both Product A and Product B. How you access the feature in both these products was the only difference.

We captured the steps to access the feature in Product A and Product B in one document. Then we generalized the first instruction in each procedure in the documentation for Product A as follows: Locate the feature (Where is my feature?)

The question Where is my feature within parenthsis was linked to the document where we had captured the steps to access the feature in both the products.

This way we had one copy of documentation which easily fitted both Product A and Product B.

Looking at the solution it does seem that this was not indeed a difficult probleme. But when it actually cropped up, we had to rack our brains to find a solution.

After we solved the problem, we really felt very happy that we addressed the problem in the best way possible. This was indeed a great learning which no training program could have taught us.

Now it is your turn!

Have you experienced any situation at work that turned out to be a good learning experience?

Please share your experiences!

Advertisements

One Response

  1. Rupa, I’m not completely sure that what you need to learn is always predetermined by your job responsibilities. Even in a highly structured or hierarchical organization, it’s impossible to envision everything that a competent person needs to learn to carry out his or her job.

    Obviously there are some fundamentals. When I was an instructional designer at Amtrak (the U.S. passenger rail service), I needed reasonably good skill at reading and writing English. It was helpful for me to have worked as a ticket agent and station supervisor, though those things weren’t essential to the instructional design job.

    Nothing I have learned when I entered the job prepared me for my biggest assignment: managing the computer-based training for Amtrak’s new reservation system. I had taken one self-study course in CBT on a mainframe system that was not the one used for reservations — that made me the most highly qualified CBT developer among Amtrak’s 20,000 employees.

    Your description of product A and product B actually seems to highlight what Karl Kapp calls in his contribution to this month’s carnival accidental learning. You and your colleague had to invent a way of handling the problem. What you learned in your efforts to gather is not learning that could easily have occurred outside of the situation like the one that you were in.

    I’ll give some thought to an example or two from my own learning. For now, I’ll share one of my favorite quotations:

    Good judgment comes from experience. Experience comes from bad judgment.

    (The key here is that the bad judgment doesn’t have to be your own.)

Comments are closed.

%d bloggers like this: