This is part 3 of a 10-part series.
Delegating lesson planning
I'm using the term 'lesson planning' as a kind of catch-all to include:
- coming up with a topic
- planning how it will be taught
- creating or collating the necessary resources
- creating assessment materials
- and running any extra training sessions for the rest of team, if necessary.
The suggestion of delegating lesson planning to other team members lends itself to a project-based learning approach, but will work even if you have a different kind of scheme of work. The idea is that instead of you coming up with all the ideas: topics, lesson plans, resources, plus any professional development required, you hand over the reins to others in the team for some parts of the course.
When I adopted this approach I had created a scheme of work which itemised what needed to be taught, and when, for example, Loops and Conditions, First Half of Term 2. I then devised lessons and resources for a couple of the modules, which in effect took care of the first term of the year till December. I invited the other members of my team to each volunteer to take on one of the other modules, with my assistance if they wanted it.
The result was a much more interesting course than would otherwise have been the case. That's not to say my topics would have been boring, but simply an acknowledgement that I don't know everything, and we all have different interests. All the other teachers came up with ideas I'd never have thought of, and for which they were personally enthusiastic. I'm sure that was partly the reason for the numbers of students wanting to take Computing at least doubled over the course of the next 18 months.
Delegating expertise
"Why does everyone keep coming to me with their problems instead of solutions? They know more about their area than I do!"
I'd been in the job about three weeks, leading several teams. The teams were comprised of experts in their field, and each was led by an expert in their field. Yet whenever they came up against a problem, their first port of call was to tell me, and then ask me what they should do.
After a few weeks of this, and of saying to them "I don't know, you tell me.", I asked that exasperated question of the team with whom I worked quite closely.
"I went on: " I'm not the fount of all knowledge. Why doesn't anyone around here think for themselves?"
He told me that their previous line manager never asked for their opinions about anything. When a problem came up, he announced the (his) solution. After a while, team members learnt that their was no point in putting any time or effort into thinking of their own answers.
My view was radically different. I believed I was there to lead, manage and co-ordinate, and to make sure all the teams worked well, both in themselves and in relation to the others. I didn't think I was there to solve problems of a technical nature -- especially when each team had their own experts who knew more than I did about that particular field.
My conclusions
A cynical view of delegation is that it's a way of offloading some of your work to people who are not in a position to argue, while you draw the same pay for less effort. That might be true if all you did was delegate tasks. But if you delegate responsibility, including decision-making, and even some budgetary decisions if the rules allow that, you start to create a self-managing group of people that will come up with ideas and new ways of doing things that probably would not have occurred to you.
In my opinion, creating a culture of innovation has to include giving people permission to do what they think best rather than asking them merely to obey orders.
To borrow from Dr Johnson, I find that most innovative ideas in Computing I read about are both new and exciting. Unfortunately, the ones that are new are not exciting, and the ones that are exciting are not new. It’s all very well “pushing the boundaries”, but all that does is give you more of the same.