I generally try and describe Object-Orientated-Programming by using real world examples.
For example, I might say that a class called Vehicle describes the minimum things that a vehicle is. I'll ask the person to tell me what he or she thinks a vehicle is. Sometimes they say things like "Well, like a car or a truck", and I'll nod and agree with them. Then I'll ask what the differences are between a car and a truck. Sometimes they mention size, sometimes the purpose, and other things.
Then I'll ask them to forget about a car, or a truck and just ask them to continue to describe a vehicle:
"Oh, well it moves"
"It has an operator, or a driver"
etc...
Soon, we know what a Vehicle is and I said that in OOP we would define a vehicle, and for the sake of argument say it can move, and give it a driver of sorts. Then I'll ask, ok, so what does a Car have?
"Doors"
"Windows"
And then a truck....
"Doors"
"windows"
"More Wheels!"
Soon, after lots of discussion, the other person generally has identified:
1) What constitutes a vehicle
2) What constitutes a car
3) What constitutes a truck
4) What constitutes an aeroplane.
All without any technicalities. We've divided up the properties of each in to the right areas. They understand inheritance ("Yeah, a car is a vehicle, a truck is a vehicle, but a car is not a truck, it's SIMPLE, duh!").
They even understand polymorphism, "Sure, they basically do the same, but that might do it slightly different.". We can talk about behavior and where that should live in our tree of objects.
Depending on their education and background, some get it faster than others. But when I compare OOP to real-life objects, most people always get it. In fact, I have found in conversations with non-technical people things I had never thought of. Vehicles don't have to be manned, for example (drones), but would a programmer have thought of the operator of the vehicle as a property of it? I am not saying it is right or wrong to have an operator mentioned, but it causes us to think about what we are modelling and what we are trying to achieve when we develop software.
Now, partial template specialization, on the other hand.... :)
I fail to see how they currently add value and is scheduling meetings, booking offsites and other administration works enough for their role?
Don't underestimate the amount of interaction your manager does with other departments. They handle budgets, training plans, HR paperwork. They protect the developers from getting sucked into meetings with other departments and provide a unified front for your group.
In short, their job is to protect self-motivated developers from all of the other demotivating things that exist in business.
Best Answer
Real world? Try carpentry. Most people have played around in a workshop a little.
You measure a piece of lumber and cut it. You need 20 of these. But to save time you take the previous one you cut, lay it flush with the next piece of lumber, and mark where you need to cut.
After 20 times you'll notice that your saw has a non-zero width and/or your pencil doesn't mark exactly where you want to cut. Errors build up and the first piece of lumber won't match the last piece of lumber.