the kernel as a resource manager
Picture an air-traffic controller at a busy airport. Many planes all want the same runways, the same airspace, the same gates - and they cannot simply take them, or they would collide. One trusted authority sees the whole picture, decides who goes when, and keeps everyone safely apart. The kernel plays this role for a computer's shared resources: it is the one party that owns them all and hands them out.
Concretely, a computer has a fixed pile of shared resources that every running program wants a piece of: the CPU's time, the bytes of physical memory, access to disks and the filesystem, the network, and the various devices. The kernel is the single trusted program that owns and allocates all of these. It is a manager: it decides which program runs on the CPU next (scheduling), it hands out and reclaims memory, and it grants access to files and devices. It is also an arbiter: when two programs both want the same resource, the kernel mediates fairly and keeps them isolated, so one process cannot read another's memory or starve everyone else of the CPU. Programs never seize these resources directly - they request them through system calls, and the kernel decides whether and how to grant each request.
Why it matters: this one idea ties the whole operating-system interface together. The reason a system call exists at all is that the resource it touches is shared and must be arbitrated; the reason the privilege wall exists is to force every program to go through the manager rather than grabbing resources directly. Seeing the kernel as 'the manager and referee of all shared hardware' explains why it must be privileged, why it must validate every request, and why it sits between every program and the machine. Without a single arbiter, a multitasking computer would be a free-for-all where any program could trample any other.
Two programs both call malloc() for a gigabyte each. Neither one grabs RAM directly; each asks the kernel (under the hood), which decides how much physical memory each actually gets, keeps their memory regions separate, and may even hand out memory it does not yet physically back. The kernel is the arbiter the whole time.
Shared resources are requested, never seized - the kernel grants and isolates.
Calling the kernel 'a manager' is a role description, not a claim that it is constantly busy. Much of the time it is idle, waiting; it springs into action only when a program makes a request or a device needs attention. The point is that it is the sole authority over shared resources, not that it is always working.