There is also a rough application of some queueing theory ideas (one might also say, the more general lessons one sees in the physics of transport phenomena, be

There is also a rough application of some queueing theory ideas (one might also say, the more general lessons one sees in the physics of transport phenomena, before one specializes in continuums etc) to business, called "theory of constraints." The basic idea is that there is probably right now only a handful of things that are slowing down your ability to make more money, and if you can figure out what they are and add extra capacity to those things, you can presumably get "more bang for your buck" than attempts to improve every part of the system individually. A lot of authors also discuss similar concepts under "systems thinking." More specifically, the theory of constraints is kind of half-applied to the "projects" contexts that we work in in software in the "critical chain" methodology. It basically says in our context that for each project you have, at any given point during a sprint, there should be one person who is "holding the baton" for that project, they need to be aware that any delays in their work are getting communicated to the project launch date, while others working in parallel are usually exempt. Essentially exactly one person on the project should be panicking, and everyone else should have spare capacity to handle the routine "hey Alice from HR wants us to change all of the articles in the table which Bob has authored so that they no longer say that they were authored by Bob since his last day is next Friday, can someone write SQL to do that?" -- even if Carol has the most domain knowledge about that, if she's holding some other baton, that comes first. In fact, if Carol can split her work -- one common one in our field would be between functionality and tests/documentation -- so that she can pass the baton a little sooner, often that is a net win, too: she finishes the core functionality up to testing-by-hand, she delivers it to Darryl who is the next to hold the baton, then she documents and adds unit tests in a separate PR before she loses her context about it. Similarly the management of these projects is different because you don't want to estimate "hey Carol we think this is a two-day PR and we will hassle you come day three," since if she judges it to be a half-day PR then it's in her best interests to spend a week on other urgent-seeming requests as those minimize who is hassling her. But instead you want to communicate "hey, this is going to take however long it takes, and I know I cannot make it happen faster by hassling you. I want you to know that even though we guessed that this was a within-one-day task we put an extra safety cushion in the project in case it goes longer, but you have the entire project's safety cushion if you ultimately need it: conversely, any time you save right now can be passed on to your other developers. What I need from you is a daily guess about when you realistically think you can pass that baton so that I can tell Darryl, 'hey, heads up, you're about to have to drop everything and pick up this baton.' You can change that estimate at any time, I just want to minimize that friction and encourage you to sprint as hard as you can on this since you're on the critical path, if anyone tries to tell you that they have something more important for you to be doing, you tell them to talk to me and I will do it personally." Also the queueing theory makes me a lot more patient with myself. Like I used to get really hard on myself about how "you spent all of this time on the job doing this other thing that didn't need to get done, you lazy procrastinator you!" ... with some queueing theory you start to ask, "what would happen if we defined load as the maximum usage of CPU, RAM, network -- what would happen if we ran a server at 100% load? Machine failure, yes... but also high latency, and things would just get dropped forever. So what would happen if I run myself at 100% load, is that really what's best for the company?" and in a couple of cases (like on these critical paths, with a crucial deadline) that is what's best for the company, but in most cases actually the company should want you to have some idle bandwidth so that you can promptly serve their ad-hoc needs.