When you configure a particular service to run on a particular server, if the server you chose isn't the local server, SharePoint registers a timer job (an instance of SPServiceInstanceJobDefinition, to be exact) that has a singular purpose - to deserialize the SPServiceInstance that represents the service being provisioned from the database, and to call either Provision() or Unprovision() on it, depending on the case at hand.
The SPServiceInstanceJobDefinition is a specialization of SPAdministrationServiceJobDefinition - that is to say, it derives from the SPAdministrationServiceJobDefinition class - and so the SharePoint Administration Service (SPAdminV4) executes this job definition, not the SharePoint Timer Service (SPTimerV4). UPDATE: A timer job that inherits from SPAdministrationServiceJobDefinition will execute within the Timer service (SPTimerV4), but won't fire if the SPAdminV4 service isn't running.
In SharePoint 2007 you could force pending administration service timer jobs to execute by running stsadm -o execadmsvcjobs. In 2010, this stsadm operation will first check to see if the SPAdminV4 service is running; if it is, you'll get a nice little message that tells you, "The service is running, so we'll just let the service take care of executing that job." But what if you really *want* control over when the job fires - for instance, you want it to fire all jobs right now?
The answer is to disable the SPAdminV4 service - a simple net stop SPAdminV4 from a command prompt will do - and *then* run stsadm -o execadmsvcjobs. You'll see your scheduled timer jobs fire off at once. Nice, if you ever find yourself sitting around in a dev environment/lab, waiting for some service to provision when, unknown to you, it wasn't scheduled to run until tommorow at 3:00AM because of some time synchronization wonkiness happening across your VMs.