The biggest and most costly mistakes in my career weren’t hidden in a line of code or a misconfigured network. In fact, my most expensive lessons came from the indirect consequences of saying “yes” to a task or taking on a responsibility. As a system architect, one of the most important things I wish I had learned earlier was this: you can’t do everything, and trying to do so can cause more damage than even the greatest technical debt.
For twenty years, while navigating between systems and networks, I’ve encountered many complex problems. From PostgreSQL WAL bloat to AI-driven production planning algorithms in a manufacturing ERP, I’ve delved deep into technical stacks. However, during this process, I realized that the way people communicate, their expectations, and their boundaries are just as critical as the technology itself.
The Cost of Saying ‘Yes’ to Everything
Over the years, I found myself on many projects. Especially while developing an ERP for a manufacturing company, saying “yes, we can do it” with every new request became almost a reflex. These decisions, made in the name of customer satisfaction, flexibility, and rapid adaptation, might have seemed to work in the short term, but in the long run, they insidiously eroded the project’s core architecture and the team’s energy.
This approach led to many technical problems, from minor glitches like SystemD unit reliability issues to insufficient partitioning strategies in PostgreSQL. Every “yes” unknowingly meant new technical debt, a new maintenance burden, and most importantly, a decline in team morale.
⚠️ Proven by Experience
I later realized how I made the data model and frontend performance unmanageable by saying “yes” to every “small” feature request for operator screens in a manufacturing ERP. Those simple additions turned into a refactoring need that lasted for months.
A Heavier Burden Than Technical Debt: Communication Debt
Often, the root of our technical problems lies in a lack of communication and expectation management. It’s easy to blame the ORM when struggling with N+1 query issues in PostgreSQL. But most of the time, these problems stem from the business unit not fully articulating what they want, or us not understanding that request correctly.
While working on an internal platform for a bank, we were dealing with complex BGP routing decisions and VLAN tagging configurations. However, the system’s biggest bottleneck was an insufficient communication chain that failed to accurately reflect the needs and priorities of different departments. As a result, no matter how robust the technical architecture was, communication breakdowns could paralyze the system.
Knowing My Own Limits
As the years passed, I had to learn to recognize my own physical and mental limits. At 3 AM one night, when my own side project’s backend crashed due to Redis OOM eviction policy, I realized that my insistence on doing everything myself came at a price. This wasn’t just a technical error; it was a consequence of pushing my own boundaries and not asking for help.
Events like these taught me that not only technical solutions but also skills like personal time management, delegation, and the ability to say “no” are critical competencies that a system architect must have in their arsenal. The sustainability of a system is directly proportional to the sustainability of the team building it.
The Dance Between Pragmatism and Perfectionism
As a system architect, we always strive for the most perfect solution. However, my field experience has taught me that sometimes, a “good enough” solution is far more valuable than the time and resources wasted trying to achieve “perfect.” On a client project, instead of creating a complex SELinux profile for security, we achieved much faster and more effective protection with simple fail2ban rules and a proper Nginx reverse proxy configuration.
For example, when designing a VPN topology, while implementing all layers of a Zero-Trust architecture would be ideal, we were able to make significant security improvements with more pragmatic steps like segmentation and routing authentication, given the existing infrastructure and budget constraints. Perfectionism can sometimes be your biggest enemy; pragmatism, on the other hand, gets you to your goal.
In this twenty-year journey, beyond the technical details, I’ve learned how critical “soft skills” like human relationships, expectation management, and knowing my own limits are to a system architect’s success. If only I had learned these lessons at the beginning of my career, perhaps I would have encountered far fewer “disk fires” or “WAL rotation alarms.”
So, what’s the most important lesson you wish you had learned earlier in your career? Don’t hesitate to share in the comments.
