We had a staff development day last week and had decided a long time ago to provide some technology training for our secretaries. We have been having issues with them and the sharing of data between different types of software and wanted to help them in this area. In addition, there are some new features of our email system we wanted to show them. Sounds great, right? Well...
I had my new staff developer delivering one session with the support of another staff developer in the room. I reviewed her outline, talked to her about her plan, asked if she was comfortable enough with all of the software and gave her tons of lead time. I gave her the opportunity to work with another staff developer who would be teaching the same session in another room. I thought everything should be in place and all should be ready.
Problem #1 was NOT the fault of the staff developer. It was me. The labs they were teaching in all had Office 2003. All of the secretaries have Office 2000. The documentation for them was created using 2003. This created some confusion when the secretaries got back to their desks and the steps were a bit different and buttons were in other places.
This was my mistake and should not have happened. This is one of the reasons standardization of software is so important. I was under the impression they all had 2003 because the secretary across the hall from me does. NEVER ASSUME!!!!!
I guess the next issue was my fault as well. Overconfidence in my staff developer led me to allowing her to go in without me really looking at every step of her plan. I spent an hour observing the session. The staff developer has experience in presentation. She is a former teacher, literacy coach, and has a CAS in administration. I had high expectations from her first formal session in our district.
She walked people through the steps of each of the skills we were hoping to teach. Period. She slowed down and helped each one when they had trouble to the best of her ability. If they had questions on how they could use a particular skill to do something a bit different, she could not always answer. She did not know the software well enough. She had assured both myself and the other staff developer that she did. Often times, her supporting staff developer had to jump in and eventually took over once of twice.
This led the secretaries to a lack of confidence in the expertise of the presenter, NEVER a good thing. Where some were comfortable with the pacing, others thought it was slow. This is a challenge for all in tech staff development and we should know how to handle it.
What disappointed me the most was the instruction itself. There were no Anticipatory Sets, no meaning was provided for the learning. There was no closure. If she was teaching to an objective, I wasn't sure what it was. Although the lesson was at the appropriate level of difficulty for the group, there was no differentiation.
Our post observation conference s coming up. I will post how that goes. It is sure to be interesting.
Now the big trick will be how to get the secretaries to go into the next staff development day in the spring with a positive attitude. The last thing I want to do is waste their time. I sent out a feedback for asking for suggestions for our next opportunity. I also re-wrote and sent specific instructions for some of the skills they had learned the other day. Of course, I wrote them and used screenshots for Office2000. My direction were VERY specific. The ones they received in the session were bullet points and would not have been clear to the staff if they did not use them immediately following the session. Hopefully, their confidence in the whole tech department in terms of PD is not destroyed.
No comments:
Post a Comment