I'm not aware of the literature on problems like this. I assume there is some, though, since queueing theory is a large academic area, and this doesn't sound like a ridiculously contrived situation. Mind you, the fact that you care about average latency, rather than worst-case latency or Nth percentile latency, might put you in the minority.
My first instinct is that since there seem to be plenty of jobs around, a good solution would have several "flexible" workers continuously employed. This is a set of workers who, between them, can complete most types of common jobs with acceptable latency. The lower you want latency to be, the more resources in this set and the more time they spend idle. Also the more "bursty" your input is (assuming bursts are unpredictable), the more idle time you need in order to prevent high latency during bursts.
Then on two occasions you hire additional "specialised" workers:
1) A rare type of job comes in which your current set of hires can only handle at high time cost or not at all. So you hire (roughly speaking) whoever can shift it and then do the most possible of the rest of your queue.
2) No such job is in, but you spot an opportunity to hire someone who just so happens to be able to take some combination of jobs off the current queue, and do them more cheaply than your current hires but without leaving your current hires idle. So you hire that resource.
As for the actual algorithm: it's almost certainly not computationally feasible to find the best solution, so the right answer depends on processing resources and you're looking at heuristics and solving partial problems. As long as everyone you hire is busy, and you can't hire anyone else without causing significant idle time at some point in the future, you're probably in the vicinity of a good solution, and somewhere near the "most bang per buck" point of the latency/cost tradeoff. Hiring more resources after that gives diminishing returns, but that doesn't mean you're not willing to do it for a specified latency and/or specified budget.
But it depends what the incoming jobs look like: if you have a resource that can only do one type of job, and that job only comes in once a day/week/year, then it's probably better to hire them once a day than to wait until you have enough of that job to fill their minimum possible timeslice (which is why firefighters spend most of their time playing card games, whereas typists spend most of their time typing. There's always enough typing to keep at least one typist busy, but fires are rare. Furthermore, we don't want the "most bang per buck" solution for fires, we want lower latency than that). So there are probably opportunities to tweak the algorithm for your particular set of resources and pattern of incoming jobs, if you're solving one particular instance of the problem rather than writing general scheduling software.
Plus presumably if the resources are human beings, you can't actually guarantee that hiring succeeds. They aren't going to sit around all day only getting paid when there happens to be work on a minute-by-minute basis, are they?