My dear colleague,
Your message yesterday troubled me, and I've been reflecting on it since. You described feeling caught between your technical conscience—which urges you to address the mounting technical debt in the authentication service—and the business pressure to deliver new features for the upcoming release. This tension is one every thoughtful engineer experiences, and how you navigate it will define not just the quality of your code, but the quality of your career.
Let me first acknowledge the reality: the pressure you feel is real. The business need for those features is legitimate. The stakeholders pushing for delivery are not villains. But I want to speak clearly about another reality that often goes unacknowledged: the moral dimension of technical debt.
When we allow technical debt to accumulate without a plan to address it, we are making a decision with ethical implications. We are choosing a path that will, inevitably, lead to future pain—for our users, our colleagues, and our business. This isn't merely a technical preference for clean code; it's about honesty, responsibility, and care for those affected by our work.
Think of technical debt as a form of borrowing against the future. Like financial debt, it can be a strategic tool when used consciously, with clear terms and a repayment plan. But when we allow it to accumulate silently, without acknowledgment or plan, we cross into something more troubling: a hidden tax on everything built upon that foundation, a burden transferred to others who didn't consent to bearing it.
This is where moral courage enters the picture. Moral courage is the willingness to take a stand for what is right, even when it's difficult. In engineering, it means being willing to advocate for the long-term health of the system, even when short-term pressures push in the opposite direction.
Here's what moral courage might look like in your situation:
-
Name the debt explicitly. Document the specific issues, their potential impacts, and the estimated cost to address them now versus later. Make the invisible visible.
-
Propose a balanced path forward. Perhaps some features can proceed while the most critical debt is addressed. Or maybe we need a dedicated "debt sprint" after this release. There's rarely a binary choice between all debt or all features.
-
Speak up in a way that builds bridges. Present your concerns not as an obstacle to business goals, but as essential to achieving them sustainably. Use language that non-technical stakeholders can connect with: reliability, maintainability, team velocity.
-
Accept that your position may not prevail. Sometimes, after you've made the best case you can, the organization will still choose the short-term path. This doesn't make your advocacy less valuable—you've ensured the decision was made with full awareness.
What would lack moral courage? Silently implementing what's asked while privately resenting it. Or worse, taking technical shortcuts without making decision-makers aware of the consequences. Both paths lead to bitterness and broken systems.
I still remember being in your position fifteen years ago, when I was asked to implement a critical financial feature without proper error handling and validation—"just to get it working for the demo." I knew it was wrong, but I lacked the courage to push back effectively. Six months later, when corrupted data caused a major outage, I felt personally responsible for the harm caused to our users and the weekend that my team spent recovering. That experience taught me that technical decisions are rarely just technical decisions.
The authentication service you're working on sits at the heart of our system. It touches everything. The debt you're concerned about—the lack of proper token validation, the duplicate user lookup logic, the hardcoded temporary workarounds—these aren't mere aesthetics. They're accidents waiting to happen. Security vulnerabilities in potential. Future pain for users and the team that we can foresee now.
So speak up. Do it thoughtfully, with empathy for the business concerns, but do it clearly. Document your concerns. Propose alternatives. Be part of the solution-finding rather than just a bearer of inconvenient truths.
And know that whatever the outcome, the act of raising these concerns makes you the kind of engineer that every organization needs—even when they don't immediately recognize it.
If you'd like to discuss specific approaches to these conversations, or if you want me to join you in them, my door is always open.
With respect and solidarity,
A fellow traveler on the engineering path