Some engineers fall into the mistake of thinking that the rational modeling and systematic problem-solving logic that works in their own domain can be applied to human organizations in exactly the same way. Yet when a solution approach that works for a technical problem is carried outside its domain, the resulting “I can solve this too” claim is usually nothing more than hollow puffery rooted in three basic errors.

First, the fallacy that if we define the problem correctly, we will find the solution. In organizations, however, the definition of the problem is itself the terrain of struggle. What counts as a “problem” is a matter of power and coalition-building—whose issue gets recognized as the issue. A technical framing often makes one side’s agenda appear “natural,” but the reality is never that simple.

Second, the fallacy that if we have data, we can decide. In firms, data often measures what is easy to measure, not what truly matters. And metrics change behavior (the Goodhart effect): once a metric becomes a target, it stops representing reality. This leads supposedly rational KPI regimes to be gamed, producing symbolic compliance and “showcase” transformations.

Third, the fallacy that if we develop the right solution, people who see it will comply with the decision. People generally do not want to comply with organizational change demands. They negotiate any proposed “solution” through their own perceptions of risk, status concerns, identities, and relationship networks. Unless it is literally a matter of life and death, change tends to remain superficial, while the old mindset continues in the background. That is why organizations are not like machines; they are loosely coupled, internally contradictory, often sending mixed messages—sometimes “ambidextrous,” but more often “ambivalent.”

Business and management is an academic field that has been taught for decades, with its own theories, methods, and standards of evidence. Even knowledge acquired through reading on strategy, organizational behavior, decision-making, governance, and change is not sufficient on its own. It requires field experience—taking responsibility, being accountable, and living with outcomes. To claim you can rationally design organizations with an engineering mindset—without training, without engagement with the literature, and without concrete field practice—is simply inflated posturing.

Of course, I am not saying engineers cannot lead. Especially in a country like Turkey, where many very capable people choose engineering, we have plenty of engineer-managers. That is precisely why so many people, after graduating, and preferably after gaining some experience, go on to do an Executive MBA or MBA. Many engineers gradually learn management in the field over time—by making mistakes again and again—and some, unfortunately, by turning working life into misery for employees along the way—until (hopefully) they learn.

Management is not the execution of a single correct solution. It is the ability to balance conflicting goals, produce legitimacy, share responsibility, build trust, institutionalize learning, and make decisions under uncertainty. Technical rationality can support these processes, but it cannot substitute for them.