The most expensive mistake of my career wasn't a line of code; it was a "yes." And such a "yes" it was, bringing weeks of overtime, sleepless nights, and unnecessary complexity in its wake. Looking back this week, I realized that what stole most of my time was again this kind of unplanned and thoughtless "yes."
This is a trap that many technology professionals, not just me, unknowingly fall into. Saying "we can do it" sometimes doesn't mean "we should do it." Especially when this "we can do it" combines with a "let's do it and see" attitude, the result is usually much more costly than we anticipate.
The Cost of "We Can Do It": An ERP Story
A few years ago, while developing an ERP system for a large manufacturing company, an urgent request came in. Instant data flow was needed for operator screens, and our existing infrastructure didn't directly support it. My young and enthusiastic colleague on the team said, "Boss, I can solve this in 3 days; we'll write another service, it will pull this data, and we'll get it from there." At that moment, when I said "we can do it," I didn't yet know the cost of saying "let's do it and see."
ℹ️ Technical Detail
This "solution" was essentially built on a "polling" mechanism. The existing service would continuously query the database, and the new service would take this queried data and write it elsewhere. Although we made the initial commit in 3 days, dealing with the subsequent N+1 queries, database locks, and general system slowdown took us a full 3 weeks.
This "solution" was a complete mess. The load on the database increased, query times lengthened, and even some critical operations locked up. Instead of instant data, operator screens started showing frozen frames. We had to write even more code to solve a problem we ourselves created. This cycle continued for a full 3 weeks. Every day, my regret for uttering that initial "yes" grew a little more.
ZTNA and the "Let's Do It Now" Syndrome
I experienced a similar situation in a project related to the security architecture for company exits. When our existing VPN infrastructure proved insufficient, we decided to turn to Zero Trust Network Access (ZTNA) solutions. While talking to a vendor, they claimed their product "automated everything" and "could be set up in seconds." Under the pressure of the moment, I said, "Let's do it now, let's speed this up."
⚠️ Security Warning
ZTNA solutions offer significant security advantages when implemented correctly. However, the claim that they "automate everything" is often misleading. Policy definition, integration, and end-to-end testing require significant time and expertise. A hasty setup can lead to unexpected security vulnerabilities.
The result? The ZTNA solution, which supposedly took "seconds" to set up, took weeks to integrate into our network. Between policy definitions, VLAN segmentation incompatibilities, and conflicts with existing firewall rules, the first phase of the project took much longer than planned. Saying "let's do it now" actually meant "let's deal with more trouble later." This experience taught me how critical patience is with complex systems like ZTNA.
The Power of Saying "No" in Technology Choices
After these experiences, I better understood how important it is to say "no" in technology choices. When starting a project or integrating a new technology, I started asking these questions first:
- Is this truly a need, or just a curiosity about "can we do it"?
- How compatible is it with our existing systems? What will the integration cost be?
- How sustainable will it be in the long run? What are the maintenance and operational costs?
- What are the trade-offs of this choice? What potential problems are we overlooking?
Asking these questions might initially slow down the project. It might even sometimes lead to me being seen as "making things difficult" by my colleagues. But this allows us to build more robust, more sustainable, and less costly solutions in the long run. Instead of complex debugging sessions where I once spent hours saying "we can do it," I can now calmly ask, "is this really necessary?"
What stole most of my time this week wasn't a technical error, but a thought error. And I'm sure this is a lesson that will stay with me until the end of my career.
What stole most of your time in your career, was it a "yes," or something entirely different? Share in the comments.
