My biggest one would be that about two years ago I read The Goal by Eli Goldratt, who is a physicist-become-industry-consultant.
I cannot write a glowing praise of it. On paper, it is an awful book, because it contains a textbook but it is trying to be a novel, and so you have to roll your eye when the main character takes the physicist's advice and suddenly his business life and relationships are all sailing smoothly. Even worse: the mathematical derivation that it provides is performed in a context of a steady demand for named products, a manufacturing context, and so it has almost no value in the software engineering "project context" that most of us face, where everything we produce is essentially different from everything else we produce. To understand that you have to read a sequel called Critical Chain, but that sequel is written even worse: at least with The Goal you could imagine yourself as a brave manager finding "Herbies" and putting them "at the front of the troop." But the sequel is just a textbook that has been artificially forced into anecdotal form.
Nevertheless, the points covered by the textbooks deeply changed my view of my purpose at my company and beyond. The essential thesis is that we commit a fallacy: everyone knows the basic accounting knowledge "profit is revenue minus cost" and that the point is to generate more profit, but the fallacy is to assume "there's nothing that I can do to change revenue, that's the job of sales, so the way to maximize profit is to reduce cost, so we will cut costs across the company and then we will be extremely profitable." And it doesn't work! At least, not consistently. What follows is a failure of the greedy algorithm: to improve the efficiency of the system, the greedy algorithm says that you make every single part more efficient, and this is also precisely wrong. The result means that you lose a certain sort of robustness against catastrophe that anyone who has gotten good at backgammon can tell you all about: beginners, who play every move safe, systematically make "good luck" impossible and "bad luck" inevitable: and so they are routinely beaten by the masters who seem to have bad luck all the way until some run of amazing luck causes them to make up their loss and more.
As a consequence you create a circumstance where, as Eli puts it, the entire shop has three priority levels: "hot, red hot, and DO IT NOW". You create a circumstance of "end of the month syndrome": you start every month cutting costs and then you end every month throwing away these lofty ideals in order to meet overdue deadlines and save some customers who are getting mighty irate with you.
All of these are failures to understand that what we'd now call velocity in fact just is profit. With a bit of help from my econ course back at Cornell, most systems can be described with an "order queue" and each order can be associated with its marginal revenue and a marginal cost. You may have to be creative to uncover these in some contexts, for example marginal revenue for a software team at a mechanical contractor may be "paid for" in some "cost savings" for the contractor as a whole in an informal "this is why we keep you programmers around!" type of situation. Marginal cost, similarly, requires being very careful to say "no, I am not going to count my programmers' time in that, unless I really intend on hiring them specially like contractors for this order and only this order." Generally labor, like the building that you are occupying, is a fixed cost.
The velocity of something in the order queue is just the reciprocal of the lead time that it spends in the order queue, and each item in the order queue represents a marginal profit, and your profit comes from creating as much marginal profit as fast as possible -- hence from increasing velocity as much as possible. Furthermore the only reason to prioritize things in that order queue is if you are accepting orders of negative marginal profit and you intend those orders to eventually get cancelled by their recipient -- in the typical case you can mostly ignore all scheduling optimizations and just take orders first-come first-served.
So what you're looking at is a sort of physics about how your organization makes money, and about through my second read-through I started to see how that needed to change my own professional behavior and how I could help my companies to do better. And it's just gone beyond my professional life into thinking about how to increase my throughput of things that make me happy, how to increase my throughput in household chores, how to increase my spiritual throughput. There's a sort of nice ubiquity to any sort of physics.
I cannot write a glowing praise of it. On paper, it is an awful book, because it contains a textbook but it is trying to be a novel, and so you have to roll your eye when the main character takes the physicist's advice and suddenly his business life and relationships are all sailing smoothly. Even worse: the mathematical derivation that it provides is performed in a context of a steady demand for named products, a manufacturing context, and so it has almost no value in the software engineering "project context" that most of us face, where everything we produce is essentially different from everything else we produce. To understand that you have to read a sequel called Critical Chain, but that sequel is written even worse: at least with The Goal you could imagine yourself as a brave manager finding "Herbies" and putting them "at the front of the troop." But the sequel is just a textbook that has been artificially forced into anecdotal form.
Nevertheless, the points covered by the textbooks deeply changed my view of my purpose at my company and beyond. The essential thesis is that we commit a fallacy: everyone knows the basic accounting knowledge "profit is revenue minus cost" and that the point is to generate more profit, but the fallacy is to assume "there's nothing that I can do to change revenue, that's the job of sales, so the way to maximize profit is to reduce cost, so we will cut costs across the company and then we will be extremely profitable." And it doesn't work! At least, not consistently. What follows is a failure of the greedy algorithm: to improve the efficiency of the system, the greedy algorithm says that you make every single part more efficient, and this is also precisely wrong. The result means that you lose a certain sort of robustness against catastrophe that anyone who has gotten good at backgammon can tell you all about: beginners, who play every move safe, systematically make "good luck" impossible and "bad luck" inevitable: and so they are routinely beaten by the masters who seem to have bad luck all the way until some run of amazing luck causes them to make up their loss and more.
As a consequence you create a circumstance where, as Eli puts it, the entire shop has three priority levels: "hot, red hot, and DO IT NOW". You create a circumstance of "end of the month syndrome": you start every month cutting costs and then you end every month throwing away these lofty ideals in order to meet overdue deadlines and save some customers who are getting mighty irate with you.
All of these are failures to understand that what we'd now call velocity in fact just is profit. With a bit of help from my econ course back at Cornell, most systems can be described with an "order queue" and each order can be associated with its marginal revenue and a marginal cost. You may have to be creative to uncover these in some contexts, for example marginal revenue for a software team at a mechanical contractor may be "paid for" in some "cost savings" for the contractor as a whole in an informal "this is why we keep you programmers around!" type of situation. Marginal cost, similarly, requires being very careful to say "no, I am not going to count my programmers' time in that, unless I really intend on hiring them specially like contractors for this order and only this order." Generally labor, like the building that you are occupying, is a fixed cost.
The velocity of something in the order queue is just the reciprocal of the lead time that it spends in the order queue, and each item in the order queue represents a marginal profit, and your profit comes from creating as much marginal profit as fast as possible -- hence from increasing velocity as much as possible. Furthermore the only reason to prioritize things in that order queue is if you are accepting orders of negative marginal profit and you intend those orders to eventually get cancelled by their recipient -- in the typical case you can mostly ignore all scheduling optimizations and just take orders first-come first-served.
So what you're looking at is a sort of physics about how your organization makes money, and about through my second read-through I started to see how that needed to change my own professional behavior and how I could help my companies to do better. And it's just gone beyond my professional life into thinking about how to increase my throughput of things that make me happy, how to increase my throughput in household chores, how to increase my spiritual throughput. There's a sort of nice ubiquity to any sort of physics.