Watson Says... |
 |
| The general idea is that when doing the type of work requiring deep thinking, there are big set-up costs to getting into the flow. |
 |
What do you say? |
 |
| Click here to send us your comments |
|
|
|
As a quick background, the EOQ model is meant to answer the question “How much product should I order this time?” That is, when you order (or make) a widget, should you order just one unit, a hundred units, a thousand units, or more?
To answer that question, you need to understand the trade-off between the fixed ordering cost (or, if you’re making the item, a fixed setup cost) and the inventory carrying cost. If there is a relatively high fixed cost, you want many units in an order. If the inventory carrying cost is relatively high (e.g. the raw materials are expensive, the item is likely to expire, people like to steal the item when you have a lot of it around, etc.), you probably only want to order a few.
The math of the EOQ model is relatively simple, and it tells you exactly how much to order given a few basic input parameters. However, the model is often criticized for its simplistic (but convenient) assumptions. Despite its shortcomings, the EOQ model is used to this day because it brings a fundamental compromise to the forefront: the trade-off between fixed costs and the inventory holding cost.
As long as you have fixed costs (and you almost always do, even if they aren’t readily apparent) and inventory holding costs (which you always will), you’ll need to decide how many items you make or buy at a time. And, the model clearly points to ways to improve: either reduce your fixed costs or optimization around their existence.
This brings us back to the point of the blog post. This fundamental trade-off shows up in many other places besides inventory management.
 In Andy Grove’s excellent classic book, High Impact Management, he takes a lot of insights from classic operations models (like the EOQ model) and applies them to principles of leadership (like being a CEO or manager). One of his insights involves batching similar items together. If there are certain tasks that a manager needs to do -- like respond to messages, meet with the people on his team, and so on --- he suggests that the most productive way to deal with this is to batch things together.
Grove believes that the same EOQ insight applies to to personal productivity. For example, he posits that there is a “fixed cost” (or “fixed time”) of going into your emails to check and respond. If we batch that particular task, we’ll gain time by spreading that fixed cost over many emails. We will, however, give up some responsiveness in order to do so (like the inventory holding cost). I think Grove would argue that if you are very responsive to e-mail, you might not have time for anything else.
 In the great book Algorithms to Live By , the authors point out that the same EOQ trade-off exists in computer science. When designing algorithms for creating a responsive system, you need to create the right kind of caches and methods for switching between applications.
That is, when you switch from one application to another, the system needs to move certain bits and bytes to the forefront, and this takes time (a fixed cost). Of course, this lagtime is measured in tiny fractions of a second, but it’s fixed time nonetheless. If this static time cost is too high, users begin to notice the reduced performance. And if a computer has too many programs running and spends too much time switching between tasks, you may find that your computer fails to do much of anything: all its compute time is consumed in the fixed cost of switching from application to application.
A good third example is related to being productive at programming, deep technical work, or solving a hard problem. The general idea is that when doing the type of work requiring deep thinking, there are big set-up costs to getting into the flow. That is, if you are wondering why you can’t get technical work done on days where you have a few meetings, it is because there is a big set-up cost to get started with this work.
Paul Graham, a famous founder of the Y-combinator startup incubator, says that the problem is that people don’t distinguish between a Manager’s and Maker’s schedule. The Maker, someone doing the deep technical work, needs to have large blocks of time to work on the problem because the set-up costs are high. He argues that the manager’s time doesn’t have the same set-up costs.
I’m starting to think that there are many fixed costs that we just see or don’t recognize. Hopefully, this blog is another reminder to look out for these fixed costs. By identifying them, you can start to either reduce them or figure out the right way to work around the fact that they exist.
Any reaction to this Expert Insight column? Send below.
Your Comments/Feedback
|
