The most expensive mistake in my career wasn’t a line of code; it was a “yes”. That “yes” dragged us into an MRP (Material Requirements Planning) nightmare that would last for weeks. That day, as a system architect, I felt the decision’s weight not only technically but also organizationally and strategically down to my core.
This story began while trying to untangle the chaos behind delayed shipment reports at the heart of a manufacturing ERP. The reports were always incomplete, seriously disrupting our operations. We were wrestling not only with technical issues but also with misunderstood workflows and the “yes” decisions given to them.
Early Symptoms: Incomplete Shipment Reports
When developing the ERP for a manufacturing company, the accuracy of the reports coming from the shipping module was critical. In our case, the reports were constantly incomplete. This was the planning team’s biggest headache; they couldn’t see clearly which product was shipped when. These gaps made inventory tracking harder, disrupted production plans, and lowered customer satisfaction.
To find the root cause we spent days poring over logs and analyzing database queries. At first we thought the problem lay in database performance or an API integration. However, detailed analysis revealed that the real issue was in the data flow itself—how the business processes were translated into software. A simple “yes” decision had thrown the gears of a massive system off balance.
Decision Moment: The Road to “Yes”
At this point we had two main options: either make small tweaks to the existing system, or redesign the workflow from the ground up. Some teammates argued that we could solve the problem without breaking the current architecture. According to them, a few extra checks and the right parameters would be enough. I, however, knew that this approach would be a temporary fix and the issue would recur. The real solution was to do the right thing—report a shipment as completed only when it was truly completed in the system.
It was at this critical juncture that I pushed back against those saying “We can do it” and said “This won’t work; we need a fundamental change.” My resistance was labeled “overly technical” or “unnecessarily complex” by the domain experts. In the end, the majority view prevailed and we voted for a “small adjustment”. That “yes” was, for me, an admission that I hadn’t steered the team correctly.
The Nightmare Unfolds: The N+1 Problem and Beyond
With the “yes” decision in place, the adjustments we made initially seemed to work, but soon unexpected issues surfaced. The changes introduced an N+1 query problem in the database. Running a separate query for each shipment record began to lock the system during peak periods. This was the first sign that our so‑called “small tweak” had turned into a major performance issue.
This situation taught us that system architecture is more than just code. We couldn’t ignore the impact of a decision—a “yes”—on operational processes. Architecture must encompass organizational flows, business processes, and even the human factor. In our case, while chasing a technical fix, we had overlooked the underlying organizational problem.
Takeaway: The Power of Admission
The biggest lesson I took from this MRP nightmare was that doing the right thing is far more valuable than temporary fixes. That day I understood the cost of my own “yes”. As a system architect, my role was not only to provide the best technical solution but also to convince the team and stakeholders of that correct solution.
This experience showed me how important it is to own a mistake and learn from it. After that “yes”, whenever I needed to change a workflow in a project, I started explaining it more clearly to my team and managers. I highlighted not only the technical details but also the operational impact and long‑term benefits.
Looking back now, that “yes” decision became a turning point for me. It made me a more careful, persuasive, and holistic system architect.
What was the most expensive “yes” in your career? Share in the comments, let’s discuss.