# Diminishing Returns in Systems Engineering Businesses and processes, whatever their nature, act like transform functions. They take some input, and they provide some output, which is the result of an internal activity. An over-simplistic—and mechanistic—take, perhaps, but not necessarily inaccurate. Granted, most of these things are not single-input-single-output (SISO) black boxes, but instead have multiple inputs and outputs, with cross couplings galore all over the place, and frequently showing complex adaptive behavior. But, if you stop feeding them with what they consume, they sooner or later stop producing anything and go belly up. A company without funds, a restaurant without customers, a plant without water. A flawed logic that seems to reign around some engineering minds is that, for every increase at the input, you should always obtain an equivalent increase at the output. As if processes, teams, and businesses will not show any opposing dynamics to these ever-increasing stimuli. Some practices and methodologies, such as Systems Engineering, have gained themselves a sort of “halo” in certain industries: you just must practice them. Fair, we all agree Systems Engineering brings benefits, lots of them, no doubt about that. But is there a “right amount” of Systems Engineering beyond a point at which it can become counterproductive? Turns out, there is, at least according to research[^1] [^2], which even suggests a pretty precise number: a maximum of 15% of the total project cost, or it turns itself against you. Wanna do more? Go ahead, but you are creating more problems than you are solving, and more problems are not something you need in your project. Overdo it, and you may even enter a self-destructive cycle where you think that the way out is only by doing more of what is actually killing you.  > [!Figure] > _Systems Engineering ROI (Source: INCOSE Handbook)_ Too much of _anything_ is bad. You can die of water poisoning, for example. Yield, turns out, will inevitably start decreasing sooner rather than later as you keep on pumping the inputs, all other things equal. Nothing to see here: just the law of diminishing returns at play. Nothing in the entire engineering practice is safe from suffering the inescapable law of diminishing returns. In short: - There will be a point beyond which bringing more people will not improve the schedule (also known as [Brooks’s law](https://en.wikipedia.org/wiki/Brooks%27s_law)). - There will be a point beyond which more Systems Engineering will not benefit your project costs - There will be a point beyond which more testing will not improve software quality - There will be a point beyond which more features will not make the product any better - There will be a point beyond which more tools will not improve a process any further - There will be a point beyond which more documentation will not make things any clearer Related to this, _lagom_ is a Swedish and Norwegian term that means: "in its right measure", or "just the right amount". Lagom is about finding balance through moderation: take just enough of what you need to do well without going overboard. The Swedish proverb, “Lagom är bäst”, literally means, “The right amount is best” but is also translated as “Enough is as good as a feast”. There is virtue in moderation. The engineering practice must be moderate; engineers must think of _lagom_ when designing, when writing [[Engineering is Broken (but we can fix it)#Fake Requirements|requirements]] or documentation, and when writing code. The right amount is best. The key is to learn to find when to stop. [^1]: Mind this number may vary depending on the context, but the important takeaway is that there is a certain SE effort beyond which you start losing. [^2]: https://www.hcode.com/seroi/documents/SE-ROI%20Thesis-distrib.pdf