All organizations use cost accounting to report on their revenue, including profit and loss. We are so accustomed to using cost accounting that we don’t realize how it hides the truth about our progress. Worse, cost accounting creates and reinforces a culture of resource efficiency thinking. (In resource efficiency, the person is the unit of work. In flow efficiency, the team is the unit of work.)
But the problem is resource efficiency prizes busy-ness—not outcomes. (If you’re not sure of that, read the series that starts with How to Use Value Stream Maps to Reinforce Agility & Effectiveness, Part 1 (Expert Teams). The more we split people’s time with multitasking, the longer all the work takes. (For the full explanation, see Flow Metrics and Why They Matter to Teams and Managers.)
When we prize busy-ness over outcomes, we can’t know our progress. Well, we know that we have delays in finishing, but we don’t know the extent of those delays. We have no source of truth about this or any other effort.
While most organizations must report their financials in cost accounting, they do not have to manage that way. Organizations can use flow or throughput accounting to manage. But first, we need to understand how cost accounting hides the truth.
Some of the Ways Cost Accounting Hides the Truth
Because cost accounting focuses on an individual’s busy-ness, cost accounting promotes these misconceptions:
- We can use divide-and-conquer to get work done. (No, it takes a collaborative team to finish product development work. Or a workgroup with sufficient slack so people can support each other.)
- We can create earned value from small additions to a software feature without finishing it. (That’s the idea that inventory, even of incomplete features, is an asset. We might with hard goods. Software is different because we do not create products based on a factory model.)
- That we can predict the end or the cost of the work from some interim point. (We might if we use cycle time. We cannot with forward prediction when so much of the work is unfinished.)
Do your managers believe these misconceptions? Most managers do. Not because they are stupid—your managers might be misinformed, but they are not stupid. They believe these things because their managers do. Also, they have not measured the effects or implications of these beliefs.
But I suspect the biggest misconception is that cost accounting treats humans as if they are “resources” and that software product development looks like manufacturing. Both of those ideas are wrong. That’s because cost accounting had its roots in slavery. And because unknowing managers repeated those accounting ideas when much work moved to the factory. That was the rise of factory model thinking.
The Factory Model Requires Little Thinking
Factories do create finished products. However, a factory has a well-defined process that the factory can apply to all the work in that factory. If you need to change the product, the manufacturing engineers change the process first.
As a teenager, I worked in a men’s clothing factory. Here are all the things I did:
- I moved finished clothing from one staging location to another. (Yes, I was a “robot.” This work required zero thought.)
- I hung plastic content tags from the buttons on the specified sleeve. (Do I remember which sleeve? Of course not!)
- Sometimes, I counted buttons and put them in bags for the people who sewed. Or counted labels and put them in bags for the people who sewed.
I was not capable enough to cut fabric, sew, or do anything else to create those garments. I was a robot who could count and move things. (And I was thrilled to have a paying job!)
The factory model treats people as widgets, with little allowance for human ingenuity and growth. The pattern cutters did have to think, so they would match the cloth patterns at the seams. Sometimes, the sewers had to think, but not often. They took the next two pieces of the garment, sewed them together, and moved the garment to the next station.
While I no longer have any insight into how manufacturers make clothing, I am sure much of the process is automated. Yes, there are still people in sweatshops, but I suspect they think even less now than they did when I understood clothing manufacturing.
No one wanted me to think. Which was fine with me. Factory work is not product development.
Effective Product Development Requires That People Think
Every software product is unique. That means we use a reasonable process—that we can change as we proceed—to develop the product. That requires problem-solving and innovative thought. Sometimes, that thought requires access to people across the organization. (This is why cost accounting charge-backs make zero sense.)
Humans are resourceful because we can develop unique and novel solutions to all kinds of problems. Those solutions often require learning, both as a team and alone.
And what about effective product development? That’s not a function of lifecycle, although shorter feedback loops often support more effective product development.
Instead, effective product development is an outcome of collaborative teamwork. That’s when a team realizes what they have. They finished a feature (or a few features), and demo what they finished.
Someone stands back and says, “Oh. That’s what we have.” The rest of the team also says, “Oh.” If they’re lucky, they do a little congratulating themselves at the retro. Then, once they learn from what they did, they then get the next bit of work to do.
Remember, in factories, the process changes before the product does. In effective product development, the process changes based on what we learned from creating the product.
While the “Oh” might be quiet, it’s an important signal that the team learned something. They learned which problems they solved and how. The more people work alone as experts, the longer it takes for the team to both finish anything and to learn what they did. Worse, the people don’t grow together as a team. They might learn and grow, but often, apart from each other.
Cost Accounting Never Accounts for Learning
While some managers still say, “People are our most important asset,” there’s no way to account for learning and growth in cost accounting. That’s one of the reasons managers just love thinking they can fire everyone and use AI to solve their problems.
Sure, if someone already coded that specific solution and you ask the LLM to add tests, you might be able to use AI to solve some of your problems. But will an AI solve all of your problems? Do you trust the LLM to use its judgment on your product? (Prototypes? Yes. Final product? I would not.)
Yet, we know that the more a team learns together, the faster they can proceed. That’s why flow exposes both the reality and costs of progress where cost accounting does not.
The Series
- How Cost Accounting Hides the Truth from Management, Part 1
- How Flow Exposes the Reality and Costs of Progress, Part 2
Reading Resources
- Caitlin Rosenthal’s Accounting for Slavery: Masters and Management (My Amazon affiliate link). You will never look at a P&L the same way again.
- Niklas Modig and Par Ahlstrom wrote This is Lean: Resolving the Efficiency Paradox. (My Amazon affiliate link.) This book taught me the term “flow efficiency.” You don’t need to measure flow efficiency. Instead, you need to know how to look for it.
- Daniel Doron wrote Seeing Money Clearly – Using Throughput Accounting to Understand and Manage Knowledge-Work. (My Amazon affiliate link.) While I have not yet referenced Doron’s work in this post, I expect to do so. (I do not have the Kindle version. I have a pdf I bought from Daniel as he was completing the book, so I do not know what is different about my version.)
- My Modern Management Made Easy books. Practical Ways to Manage Yourself introduces you to a new view of management, based on flow. Practical Ways to Lead and Serve Others is about flow efficiency in teams. Practical Ways to Lead an Innovative Organization applies flow efficiency to management.