The Misguided Focus on Throughput in Knowledge Work
In the world of manufacturing, the Theory of Constraints (ToC) has long been a cornerstone of improving efficiency and boosting output. By identifying and optimizing the bottleneck in a production process, the entire system's throughput can be increased. This approach makes perfect sense in the realm of physical goods, where the goal is often to produce as much as possible, as efficiently as possible. However, when we attempt to apply this same logic to knowledge work—like software development—we run into some serious limitations.
Focusing solely on the efficiency of the constraint does allow throughput to go up, but it often has very little to do with other, sometimes more important, types of improvement possibilities. In fact, in many cases, these other types of improvements far outweigh the benefits of increased throughput. The problem arises when we treat knowledge work like manufacturing, assuming that more output equates to more value. This assumption can lead to misguided priorities and counterproductive outcomes.
In knowledge work, the idea that progress can be measured by counting lines of code, releases, or even pull requests (PRs) is considered absurd by many experienced practitioners. Unlike manufacturing, where more widgets generally mean more value, software development is about creating the right things, not just more things. This is why so many software features end up being rarely used, even in popular products. The focus on throughput can drive teams to churn out features at a rapid pace, without fully considering whether those features are needed or even useful.
A striking example of this misplaced focus is the recent CrowdStrike bug that caused significant outages. The consequences of this bug were far more severe than any considerations of throughput. Here, we see that the drive to push out features or updates quickly, to maintain high throughput, can lead to disastrous results when quality, security, or customer impact are not given equal—or even greater—weight.
The application of ToC in knowledge work is, therefore, terribly misguided in its focus on throughput as the primary path to value. In manufacturing, throughput is a necessary evil; you need to produce enough to meet demand and stay competitive. But in knowledge work, throughput is often optional and highly conditional. There are many other paths to value in this domain, and improving decision-making about which paths to pursue is where the focus should truly be.
领英推荐
Rather than obsessing over how quickly we can get more code out the door, we should be asking ourselves more critical questions:
In knowledge work, the ability to make better decisions about what to build, when to build it, and how to build it is far more valuable than simply increasing the rate at which we produce.
In conclusion, while throughput may be a key metric in manufacturing, it is a misguided focus in the realm of knowledge work. By recognizing the unique nature of knowledge work, particularly in fields like software development, we can shift our focus from the quantity of output to the quality of outcomes. This shift in perspective is crucial for creating real value and avoiding the pitfalls of a purely throughput-driven approach.
Sounds like there's room for improvement in hitting those targets. What strategies do you think would help close that gap?
Founder of AndonPulse | Speed up engineering delivery by 30% in 4 months
6 个月I agree that having a metric to measure the value a team or developer brings would be beneficial. However, it’s a bit naive to expect developers—whose expertise lies in technical implementation—to be the ones to judge whether the features they’ve built deliver value to end users. It’s like asking a driver to take you to Italy and then blaming them because you actually wanted to be in France. Most teams aren’t fully aware of customer needs, so getting to Italy first and then adjusting your route can be a good strategy.
Partnering with Leaders to Cultivate Self-Managed, Human-Centric Organisations for High Performance & Impactful Value Creation
6 个月Matt. You are definitely onto something. I’m planning to write a piece on predictive vs creative flow. The distinction you made here made a lot of sense. I need to think deeper about TOC but certainly a lot of ideas that agile folks adopted from Lean unfortunately are not applicable to creative product development work. Specially ideals like Flow Velociy. Thats why, now a day we see a lot of feature factories rather than creative product development. Throughput in software development have no bearing on the quality. I get that teams have to be able to release the work into production many times a day if they need to but the number of times a team release in production even with the right tools and instrumentation doesn’t guarantee the right product. Production line is differnt to product development and manufacturing where you are making the same or similar widget thousands of times shall not be conflated with product development where every feature is differnt to the last one.
Engineering, Product and Innovation Leader | Transforming Product Development Systems into Dynamic Growth Engines
7 个月"The problem arises when we treat knowledge work like manufacturing, assuming that more output equates to more value." That is a tricky assumption. There are plenty of manufacturers making a lot of soon-to-be E&O to crank up OEE. One value in manufacturing is aligning supply with demand and doing so cost effectively. In knowledge work, specifically product development, I tend to think the bigger "constraint" is the number of high-value ideas worth working on. Instead of vetting projects out before they get started, most places are creating knowledge E&O (mostly O).
Where is focus, where results. TOC all about focus. So far so good. Current IT industry focusing on releasing more and more stuff. Yes, you can increase effectiveness, add more work hours, add more developers, but at the end it is limited. Looks like is it, but we are forgetting QUALITY. It is not free. In some case it takes up to 30% of developers time. For developing medical software, it is more than 90%. In manufactory quality can be measured, but in IT? For what reason every year quality of coding is lowering. It cannot continue, until quality will disappear. Someday some big NEWS will happen, and politicians will ask what's wrong with IT? What will be answer? We use Agile, Scrum, TOC, Lean, 6Sigma, etc... But probably it is not enough, and politicians will create law according to all software should be developed. I will summarize: every year quality of software is lowering and using any FOCUS type methodology only increase deterioration of quality. Problem not methodologies, but attitude to quality and market pressure.