The diagram above is a block diagram for a control system. My first theory is that a department is a dynamical system, and each element of the system can controlled using a feedback loop, represented above.
- The input is the information you get from your environment.
- The controller is your means of monitoring and acting on that information.
- The process is the response to the actions set by the controller that the dynamical system takes. This might be good or bad!
- The feedback is the information you get from the process. This then informs the action required through the controller stage.
Here’s an example; think about a student asking you a question;
- The input is the question – “how do you calculate the area of a triangle, sir?”
- The controller is my response – “you calculate the area of a triangle by multiplying the base by the height and halving the answer”
- The process is the student response to the answer.
- A positive outcome would be “thank you sir” and students getting on with task;
- A negative outcome would be “what’s the base?”
- Either of these outcomes is then used as feedback, to determine a future action.
Although this is a simple case you can apply this to any system that makes up the operations that your department carries out, at the macro and micro level.
Now, this has implications. It’s the basis for my belief that incremental change over the long term is better than significant ‘big impact’ changes in the short term, and here’s why: small actions via the controller stage place low stress on the process and create feedback that is easier to determine and measure; case in point, something as simple as changing the position of one or two students in your seating plan can give you easy identifiable and measurable feedback on how the classroom ‘dynamic’ plays out in your lesson. Whereas, if you completely change a seating plan in one go, you’re losing the opportunity to identify if the moves you’ve made are right, because you’ve created unnecessary complexity. Any student of control engineering will tell you that a large variation at the controller stage can completely throw a system because the process can struggle to cope, providing feedback that cannot be properly measured as the system goes through future cycles.
How does this make a department lean? All too often if problems are identified in departments, there’s many a time where the ‘reset’ button is pressed, and new schemes of work are brought in, new textbooks, time spent on putting things in place and fingers are crossed that it’ll all go as planned – often without staff buy-in. This equates to massive time and resource investment, and with a high risk of volatility that needs further time and resource investment if it doesn’t work out as planned. Instead, if you know each incremental step that makes each process of your system, then you can make a series of minimal changes over time, with minimal time and resource costs to restore actions if they didn’t engender a positive outcome.