If you are making burgers, and you know you need to make 12 burgers today, why should you only make one when a customer orders it? It’s so much faster just to cook all 12, and it’s faster for the toppings person to put ketchup and pickles on all of them at once. Is that first customer waiting longer than they would if you just made one burger? And what if that 12th customer asks you to hold the ketchup?
Local Optimization is when you work to be efficient in your own work or that of your team. Global Optimization is when efficiency is viewed across teams, focusing on the outcomes.
Would you be willing to work in a less efficient way if it would improve the overall outcome? Why do we so often cannibalize the outcomes in favor of local optimization? How can we change the organization to get better outcomes? Let’s see if we can dig in and find out.
Optimization Myopia. People see optimizations through the lens of their own work. Sometimes it hard to see how things connect.
You hear people say how “inefficient” it is only working on one change to a block of code, while they’re in there why don’t they just do the next 8 changes that are coming? While that might be more efficient for the programmer, it’s much less efficient for the team because the team has to test it, fix it, integrate it and train people on it. Meanwhile, the customer is still waiting for that one small change. It’s difficult to see past the lower output in your group, for the benefit of the whole.
Consider a process that spans teams, where Round A is a single batch of 20 and round B is batches of 2.
In the example above, Round A is more efficient for each team, as they ALL spend less time to develop 20 features. Each team will say “Round B is so inefficient! It takes me twice as long to do the same work!” But what will the customer say? It comes down to this question, “Is the cost savings in Round A great than the revenue you generate in Round B?”
Ghosts of Process Improvements Past. Most of the Process Improvement frameworks over the past decades have favored Reductionist thinking.
Reductionism is when you break a process down into its parts, find out which parts are the slowest and fix those. The core Reductionist belief is that if we get all the parts to be as efficient as possible, the overall process will be optimized. Note: Similarly, getting each individual to be high-performing doesn’t get you a high-performing organization. More on that in a future post.
The Reductionist beliefs that we’ve all followed since Frederick Winslow Taylor introduced them 1901, simply don’t hold true. We’ve got to optimize for the system as a whole.
Policy. By now you may be wondering where to start making change. It’s hard to change mindset and beliefs, it’s easier to start with policy. Look for policies that favor Local Optimization and change those. Here are some examples:
- Rewards and metrics favoring the individual or team efficiency. In the above chart, if any of the teams are rewarded for how quickly they turn around 20 features, you are enforcing local optimization. I’ve seen organizations create “quality indexes” for each individual. This creates an “everyone for themselves” mentality.
- Rankings between dependent teams. If teams need to work together but they are competing for recognition, they won’t be effective. A great example of this is when you see quality teams competing with development teams.
- Conflicting priorities. If one team is measured on speed and another is measured on quality, these teams won’t work well together. The same goes for actual work; if one team is prioritizing project A and the other’s prioritizing project B, they won’t be optimizing for outcomes. Get your priorities aligned.
How have you dealt with local and global optimization in your organization?