Bad experiences can lead to good practices

We have all had bad experiences and bad managers. We have had bad experiences that make us question our sanity and decision to have ever gotten into this field. As it is, instructional design is the under-appreciated, undervalued role in training that is constantly under the gun for being cut. A lot of businesses go through the same cycles because they truly don’t see the value of what an ID brings to the company.

However, these tendencies for the scary in the instructional design field can lead to developing practices and processes that will make you a better instructional designer, if not safer for your efforts to justify your place in the business environment. It has been the very bad experiences that have made me more confident and more valuable to those that do understand and respect the role of an instructional designer.

The following are three ways that bad experiences have given me insight and experience that now shape me as an ID.

Document, document, document.

I don’t start a project without documentation. I have developed templates for every step of the process that documents the “why” of what I am doing as much as the “what” I am doing. These templates didn’t come from an innate desire to document, I am one of those people that “thinks slow, acts quick.”

I have always been able to develop everything in my head and then execute quickly. The problem with this, however, comes when you have to justify why you did something the way you did or why the content says what it says. After too many times of being caught between competing managers or stakeholders, and me looking bad or being blamed in the process, I started documenting everything. I document and store every email. I take copious notes and then send them to stakeholders for clarification. I develop “maps” of the path I took to the content I have requested, then I document every question I ask for clarification. I do as very little in face-to-face as I can, so I have a document trail of the “why” and the “what.”

What started as CYA has actually really streamlined my process of development and made communication easier, more effective, and consistent. Using a process of templates also provides a visual roadmap for others to follow for continuity. If something were to happen to me, there is a treasure trove of my thinking, my direction, and the next steps that need to be taken. This is as much for the success of my fellow IDs than it is for the business.

The final advantage of documenting is for lessons learned. If there was a gap discovered or misinformation published, documenting allows you to investigate where the breakdown may have occurred. This is especially effective when you have been in a company for a long time and the good idea fairy pops up with a new round of fresh new managers. You can go back to your documentation and say “Yeah, that seems to be a good idea, so how would it be different than the way we did it two years ago and had it flop on its face?” It isn’t necessarily about shutting down the fairies, though, it is about overcoming past issues or errors.

Always get approvals in writing

It is frustrating to stakeholders to have to approve steps, but if something goes wrong, most businesses are looking for scapegoats and blame, not for how to fix the mistake and move on. I request approvals for EVERYTHING. That doesn’t necessarily mean I get them all of the time, but, in the process, I make it clear that at the bottom of the document is a place to sign and date the stakeholders approval. This is always by email with the attached document or a link to it, so I have time and date stamps. I always set a “no later than” date, then remind them three times. The last reminder clearly states that I need to move on with the project to meet their deadlines, so by not responding or signing, they are implying approve of the information. If they do approve it, I save the document. If they do not, I notate the document with the date and time of the last email, and the warning.

I cannot stress enough how many times this tactic has saved me from, at best, being lost in the cracks, or at worst, malicious intent. As instructional designers, we are the gatekeepers of information and processes for an entire company or department. Most often, we are not subject matter experts, we depend on them. But, if something goes wrong, the ID is the first “blamed” and looked at for the mistake. With a documentation and approval process, you can turn it from a blame game into a strategy for correcting the issue. We don’t want to get into blaming, we just want the information to be correct and the project completed.

Don’t be the subject matter expert for what you are developing

We are not meant to be, nor should we be, the subject matter experts on everything we design. And, believe it or not, facilitators/instructors should not be either. The only people that are subject matter experts in a specific topic are the people doing the job or the person leading the people doing the job. Instructional designers should only be subject matter experts in developing effective training in every project. Instructors should only be subject matter experts in delivering that training. Instructor or ID experience only provides context, should never be the source of content.

Does that mean we aren’t or can’t be subject matter experts in other topics? Not at all. We should be experienced in many things. We can be subject matter experts in many different skills and knowledge. However, we shouldn’t be the source for that content. Our experience, training, and knowledge should inform our development, but we should – every time – depend on the people who are actually doing the work for which we are developing training.

The content should be objectively acquired from people who are currently doing the work on a day-to-day basis, who manage those people, or based on research and task analysis. For instance, I once worked in a telephone based role where I trained people how to use a particular web technology. I was considered one of the top performers and wrote a lot of the policies for how others should do their jobs. I went on to become an instructional designer and was tasked with developing training for that role. I evaluated the then current training, interviewed the managers for what their expectations were, then performed a task analysis with a range of people, ranked on their performance by the managers.

The training I developed was exceptionally successful, but none of it was content I developed. I identified where the deficiencies were in achieving target metrics and developed the training to that. Now, my experience was informative, I knew what the job entailed, but, in the time I left the telephone role and was tasked with developing training for that role, enough had changed that my experience couldn’t be content. Also, my experience with how I was first trained informed me for how others should be trained. Even though I knew the managers and the job very well, I still had them generate the content, then approve each step in the training development process. Through this process, the training I developed decreased the time new hires hit their key performance indicators from three-to-six weeks to three days-to-two weeks. The training before I redesigned it was developed by someone who knew the job, but didn’t know instructional design. The difference was clear and set a precedent in the company.

Conclusion

Whenever you find yourself in a situation that makes you feel defeated or unappreciated, look at what you are doing in your current process to feel safe. Look at them long and hard and think to yourself “Is what I am doing now something I can apply to any job or any project?” There are way too many people who find themselves in instructional design without any background or experience in doing the work. Fortunately, there are many of us who have been in exactly that circumstance. Use those opportunities to research test, and develop systems that can help you be more successful and are transferable to other projects, roles, or jobs. The old saying “a bad experience is one that I haven’t learned from” can be applied here. If you take the time to evaluate what is going on around you and how to protect yourself, you may find that you are actually developing processes that make you better in your job and your projects.

#learningtechnologies #instructionaldesigner #learningdesign #instructionaldesign #elearning #edtech #learningtech #learningtechnology #educationtechnology #learninganalytics #xAPI #beginnerid #beginnerinstructionaldesign #instructionaldesigntips