👉 In this text, "project manager" refers to the person ultimately responsible for the technical decisions of the project, regardless of their official title.

I’ve had the experience of joining projects that were already half-built and developed over time. One recurring mistake I’ve seen in many companies is an excessive focus on non-technical considerations:
"The customer is fine with it as is,"
"Being up-to-date isn’t important,"
"Time-to-market is our top priority."

The result? Source code with no clear architecture, design, or well-thought-out technical decisions. In some cases, teams were even working with technologies that had been practically dead for years, such as Web Forms on the old .NET Framework.

This situation leads to two major problems:

  1. Strong developers get frustrated and eventually leave the team.

  2. The company faces high production costs relative to the delivered value.

Initially, some organizations resist admitting that the root problem lies in legacy technologies and outdated coding styles that can no longer handle the scale, database complexity, or modern product requirements.
They overlook the fact that they are paying significant costs every month due to poor technical conditions and managerial decisions of a technical nature.

A technical lead is not a supervisor who just enforces developers to work in a weak technical environment for the sake of pleasing higher management.
Where a company must make difficult decisions and accept the associated cost and time, it is the technical lead’s responsibility to inform the organization of the risks and prepare them to face these challenges as early as possible.

Making the right tough decision at the right time can save a project—or even the company—from major, sometimes irreparable, risks (or at least prevent much higher costs later).

👉 Note: this discussion is not about technical debt.
Conscious technical debt can be a strategic decision; choosing the wrong technology, however, is a managerial mistake. This text discusses important managerial decisions for technology migration, architecture updates, and ensuring the product’s future.

Conscious technical debt may include:

  • Shortcuts in design
  • Fast coding with a plan to refactor later
  • Deferring improvements

But it does NOT include:

  • Choosing dead technologies
  • Selecting a platform that cannot scale or support the product roadmap

Just because a customer doesn’t value technical aspects doesn’t mean they can be ignored.
If decisions were that easy, what would be the role of a technical lead?

Balancing maintaining technical quality while satisfying the customer—both are critical.
The ability to align these seemingly opposing priorities is exactly what separates an experienced technical lead from a less experienced one.

In short:

  • Technical quality ≠ cost

  • Technical quality = risk management for the future