In How Centralization Decisions Create Friction, Increase Cycle Time, and Cost Money, Part 1, I discussed how removing support staff for departments and managers created longer cycle times. (And sometimes, increased friction so much that people could not easily do their jobs.) Removing those support staff was one indication the companies fell into the Economies of Scale trap.
Next, How Value and Cost of Delay—Not Cost Savings—Applies to Centralization Decisions Part 2, I explained how to think about the value of work instead of predicted costs. When we see the value of the work and the various delay costs, we can assess the work differently than when we use predicted costs.
Now, it's time for Economies of Scale and how that ties into resource efficiency thinking.
Resource Efficiency Thinking Traps Many Managers
And I said the managers were not stupid. They used resource efficiency to make project portfolio decisions. Resource efficiency focuses on each person's contribution to the whole. (See Resource Efficiency vs Flow Efficiency for more information.)
In very small organizations, resource efficiency, the image on the left, might help everyone realize when the team does not have the necessary skills and capabilities to finish the work. It becomes obvious because, at some point, no one can finish the work.
Instead, the team could work in flow efficiency, as in the image at the top of this post, collaborating as a team. (See my pairing, swarming, and mobbing post or the Project Lifecycles book.) The more the team can manage all its work itself, the less centralized the team is.
You might have heard of “shared services” teams. That's another form of centralization and what organizations refer to as economies of scale. But, shared services create delays and costs. (See Why Shared Services “Teams” Don’t Work with Agility and Unearthing Your Project's Delays.)
Let's examine the idea of economies of scale first.
Clarify Economies of Scale
Economies of scale attempt to clarify the output per unit time, through the division of labor. See the Wikipedia article. That division of labor is all about resource efficiency, the idea of divide and conquer.
If you read the article above or any of the other articles you can find online, you might notice Economies of Scale focus on production—specifically manufacturing production.
Manufacturing repeatedly creates a copy of the same thing.
That's not product development—and that's the first place we get stuck with Economies of Scale thinking. Product development requires teams who can learn together. Anything that slows the team, such as questions for other people or answers from management, will prevent Economies of Scale.
But so many organizations still think resource efficiency and Economies of Scale thinking are useful. Here's why this 2000-person organization fell into that trap:
- Cost accounting, which reinforces resource efficiency thinking.
- Ignorance of the flow metrics.
- An emphasis on individual management goals, which made them unable to collaborate as a management team on the project portfolio.
Let me start with a small rant about cost accounting.
A Short Rant Against Cost Accounting
Every organization must report their financials using cost accounting. Cost accounting wants inventory because (supposedly) inventory has value.
Inventory might have value for physical products, but it rarely does for software products. In software, we want less WIP (Work in Progress), which is a form of inventory. We also want less unreleased work, because we can't learn about the value of that work until the customer can use it.
The more an organization thinks in resource efficiency terms, the more the managers can somehow attribute the finishing (or not) to a specific person. Managers think that helps them understand who offers the most value in the organization.
So the teams separate the work by person, increase their WIP, decrease their throughput, and increase aging. That increases the various costs of delay. (See How Value and Cost of Delay—Not Cost Savings—Applies to Centralization Decisions, Part 2.)
The more centralized the organization, the more the managers focus on cost accounting—because that's all they know how to measure. Even though value is a much better way to manage.
Luckily, the flow metrics help everyone see where the teams have value and where there is just cost.
Flow Metrics Help Everyone See Reality
I wrote about the effect of delayed releases in Little’s Law for Any Kind of Product Development: How to Learn How Long Your Work Will Take.
Here are the four flow metrics:
- WIP: the current number of work items in progress.
- Throughput: the number of work items completed per unit of time.
- Cycle time: the time to release value, at minimum internally, as a trend. (See Measure Cycle Time, Not Velocity.)
- Aging: how long a piece of work has been in progress.
When teams work in flow efficiency, they choose as a team, how to manage all of these measures. The flow metrics help the teams manage themselves and offer valuable information to the people making the project portfolio decisions.
Here's what's interesting about the flow metrics: If you pay attention to all of them, they will decrease your cycle time, increase throughput, and reduce WIP. Most of the time, those changes will decrease aging. (Or, if you're like me, you start with aging and ask, “Why is this item still open after so many days?”)
Individual Management Goals Create Friction for Project Portfolio Decisions
This organization grew partly because customers loved the original product line, and partly from acquiring other, smaller companies. Since the organization started with one coherent product line, it made sense to have a centralized group to make the project portfolio decisions.
However, by the time they had six related—but independent—product lines, the time to make the project portfolio decisions increased dramatically. I discovered these reasons:
- Each manager had his or her own, specific, independent goal. The senior leaders called these OKRs, but they weren't. These goals were often of the sort: “Increase this specific product revenue by 20%” or some nonsense like that.
- Because each manager had “stretch” goals, each manager competed for people.
- The portfolio group assigned individual people—not teams of people—to various projects. They started with developers first, and then testers, and finally UI people. Often, not enough people to make a real cross-functional team.
And it took them months to decide on the portfolio for the coming year. That's because most of the managers' goals were in conflict with each other. (See Modern Management: Want Valuable Outcomes? Create Overarching Goals for an example of this.)
In this case, their centralization caused enormous delays as an organization and in the teams. That was why they had all those Costs of Delays in Part 2.
Centralization did not help them manage the portfolio, or any of the revenue goals. Finally, they chose a different path, based on the various costs of all the delays.
Decentralization Can Help with Significant Delays
Once they realized their centralization wasn't helping, they reorganized into six departments, each with their own portfolio team. That had several good effects:
- Reduced the number of people necessary to make a decision. That allowed them to make smaller decisions more often and agree easier.
- Clarified the number of available people to work on a given product. They needed fewer people, because everyone focused on this department's product. That reduced multitasking.
- Allowed them to reorganize from component teams to feature teams.
While everyone realized the entire organization needed to limit their WIP, their decisions still took a long time because all the “support” people (finance, HR, marketing communications, etc) were still centralized. In a real sense, the “support” staff were shared services. That's why the various management decisions still took too long, creating more costs of delay.
That's when they had the “aha” moment. These various people were not “support” at all. All these people needed to be involved with their specific product's portfolio decisions. The departments needed to decentralize the “support” staff so they could make faster decisions.
Reducing the Costs of Delay More Than Paid for the “Duplication”
When the departments decentralized, they did have more finance, HR, and marketing communications people. Where did each department get the money? From the shorter feedback loops of releasing, which increased both product revenue and customer success revenue.
Because the managers decided everything faster, the teams could start earlier and start fewer projects. As a result, the teams' throughput increased, and cycle time decreased. And the managers received feedback on their decisions, too. That allowed the managers to commit to much less work and experiment more.
In my experience, the less centralization, the better. If you start to track the various Costs of Delay with the centralized functions, you might see that, too.
Economies of Scale Don't Work for Knowledge Work
There are times when economies of scale are useful. But not for knowledge work or product development work. When organizations try to save money on “support” staff, they often increase the decision time, creating many costs of delay.
If you want to speed up your product development and reduce the costs of that development, create teams with all the skills and capabilities necessary for the work. Do everything possible to decrease anyone's decision time.
Want to Rethink Your Management or Leadership?
If I'd realized how many words this would be, I might not have started this series. (!!) However, I started and finished it, so now I'd like something from you.
If you want to rethink your management, start with my books. If you're a leader, read the Modern Management Made Easy books. Or hire me to bring the Modern Management Workshops to your organization. If you're part of a team, read Create Your Successful Agile Project or the Project Lifecycles book. Take a look at my Pragmatic Manager newsletter.
If I've proven my worth to you in these posts, let's work together. However, if you're starting with these ideas, hire me as your trusted advisor. You won't regret it.