At a marketing services SaaS provider, my team inherited data that drives web pages from multiple tables and fields in some very interesting ways, including space-delimited lists. Several applications had their own version of the same merge and position-based manipulation logic.
That design regularly led to data corruption and manual intervention.
The technically pure answer was obvious: refactor the database. The practical answer was harder. A full database refactor would touch internal applications, external-facing applications, reporting, existing workflows, and every piece of code depending on the current data shape. The blast radius was enormous.
So we built a small serialization and deserialization library instead. The data model did not become perfect. The platform became better. The logic moved into one place, the corruption risk went down, and each application could be moved to the safer path without pretending we had a clean-slate system.
That is stoic engineering leadership.
Every engineering leader eventually inherits a codebase they would not have designed. Not a clean architecture diagram. Not a greenfield project. A real system, coupled in weird places, missing tests, and full of decisions that made sense to someone under pressure three years ago.
Your reaction matters. You can walk in disgusted. You can roll your eyes at every table name, every 1,000-plus-line class, every missing abstraction, every strange deployment process, and every decision that violates the standards you would have applied.
That feels righteous.
It is usually useless.
The stoic engineering leader starts somewhere else: reality. The codebase exists. It works. It powers a business. It pays salaries. It serves customers. It is imperfect, sometimes deeply imperfect, but it got the organization this far.
That deserves respect, though not automatic approval. Respect, and grace.
Grace for the people who came before you does not mean lowering the bar. It means acknowledging that you were not there for the constraints that shaped the system. You were not in the room when the deadline moved, when the budget got cut, when the customer escalation hit, or when the engineer who understood the data model left.
Playing armchair quarterback does nobody any good. Your job is not to sneer at the past. Your job is to improve the future.
Start With What You Can Move
You do not control the codebase you inherited, the deadlines that shaped it, the shortcuts that were taken, the staff turnover, the budget decisions, the rushed releases, or the customer pressure that made the current system what it is.
You control what you do next. That is where stoic leadership gets practical.
The stoic leader does not waste energy resenting what cannot be changed. They get to work on what is within practical grasp.
Not everything can be fixed this quarter, or even this year. Not everything should be. Your job is to identify what can be improved now without pretending you have unlimited time, unlimited budget, or a greenfield system.
Practical grasp matters. Improve the next story, add the missing guardrail while you are already touching the code, rename the confusing method, pull one behavior out of the bloated class, document the rule everyone keeps forgetting, and make the next change cleaner than the last one. Start there.
Leadership is not proved by seeing every flaw in the system. Anyone can do that. Leadership is proved by choosing the next responsible improvement and making it real.
Teach From The Old Scars
The codebase is not what creates contempt. The story you tell yourself about the codebase does. There is a difference between judgment and contempt: judgment says, “This table design creates duplication” or “This class has too many responsibilities.” Contempt says, “Whoever built this had no idea what they were doing” or “This whole thing is garbage.” Judgment is useful. Contempt is lazy.
You need technical standards. You need taste. You need the ability to look at a system and see where it is weak.
But you also need humility. I was not there for the constraints that shaped this codebase. I do not know which deadline moved, which customer was escalating, which engineer left, which vendor integration failed, which executive changed direction, or which tradeoff looked reasonable at the time.
Playing armchair quarterback does nobody any good. The old code is not a punching bag. It is a classroom.
Use the failures and misses of the past to educate the future. Show junior developers why the data model creates update anomalies. Walk them through how the database could move toward fourth normal form. Show them how a giant class can be decomposed into clearer responsibilities. Explain why the shortcut created risk without turning the person who took it into a villain.
That is how a team develops standards without developing shame. The lesson matters. The sneer does not.
Lead The System That Exists
You do not get to lead the system you wish existed. You lead the one that exists, which means leveraging what you can. If the architecture is imperfect but stable, use that stability. If the team has strong domain knowledge but weak test coverage, use that conscientiousness while you improve the safety net. If the system is ugly but powers a successful organization, respect the result while raising the standard.
Acceptance is not surrender. It is the beginning of useful action.
The immature reaction to an inherited system is fantasy: “If only we could rewrite it.”
Sometimes you can. Usually you cannot. Even when you can, the rewrite will cost more, take longer, and preserve fewer business rules than the team expects.
The mature reaction is leverage. Ask what still works, what has to keep working, where risk is highest, where one small change can make the next ten changes easier, and what team strength can carry the improvement effort.
Stoic leadership is not pretending the system is fine. It is seeing the system clearly enough to move it, then being disciplined enough to select the few places where movement matters most.
Pick The Highest-Gain Obstacle
The obstacle tells you where the work is.
It does not tell you the priority.
That distinction matters.
Engineers are trained to see flaws. We see missing unit tests, duplicated logic, poor naming, leaky boundaries, manual deploys, dead code, outdated dependencies, and database designs that should have been fixed years ago.
Seeing the flaws is easy. Choosing the order is leadership. Lack of unit tests is not great, but if the system works, your developers are conscientious, and the highest business risk is somewhere else, unit tests may not be your first move.
That sentence will bother some people. Good. Books give general principles. You lead a specific system.
The right next move might be the deployment process that blocks releases, the data model that corrupts reporting, the class everyone is afraid to touch, the manual process that burns ten hours every sprint, or the subsystem only one developer understands. Do not optimize for what makes you feel technically virtuous. Optimize for the next meaningful gain.
The stoic leader does not chase every flaw. They attack the highest-priority, biggest-gain item within reach. That is how improvement compounds.
Field note: At a marketing services SaaS provider, some of the data that drives web pages is stored across multiple tables and fields in very interesting ways, including space-delimited lists.
The current code has to merge that data and manipulate it by position and index. The logic exists in several applications in slightly different forms, producing data corruption, manual intervention, and the same business rule implemented differently in different places.
A full database refactor would touch internal and external-facing applications, reporting, existing workflows, and every dependent component. The blast radius would be huge. My team chose a smaller path: a serialization and deserialization library that holds the logic in one place while applications migrate incrementally.
The platform is not perfect afterward. It is better. The corruption risk goes down, and the team gets one place to fix, test, and understand the rule.
Improve The Real System
Small changes lead to big shifts. Grand rewrites feel clean because they let you imagine a future without brittle old code, strange schemas, awkward boundaries, or accumulated compromise. Just a clean system built the right way.
That fantasy is powerful. It is also where many engineering organizations lose years.
Grand rewrites often fail. When they do not fail, they usually take far longer than expected. Meanwhile, the old system keeps running, the business keeps changing, and the team keeps paying interest.
The stoic leader improves the real system through small seams, decompositions, schema improvements, tests around high-risk behavior, reductions in deployment pain, and standards applied consistently from this point forward. That does not sound dramatic. It works.
One cleaned-up story does not transform a codebase. One better boundary does not change the architecture. One test around a critical behavior does not create comprehensive coverage.
Repeated small improvements change what the team believes is normal. The codebase gets better, standards get clearer, the team gets sharper, shame goes down, and discipline goes up.
That is stoic leadership in software: calm enough to see reality, humble enough to respect how it got here, and disciplined enough to improve it anyway.
Receipts
- Marketing services SaaS provider: My team inherited webpage data stored across multiple tables and fields, including space-delimited lists, with merge logic duplicated across applications.
- Observed failure mode: The duplicated position-based manipulation logic regularly caused data corruption and manual intervention.
- Practical fix: Instead of a full database refactor with a large blast radius, the team built a serialization and deserialization library that centralized the logic and let applications migrate incrementally.
- Leadership tradeoff: The platform became better, not perfect. That was the right move because it reduced risk without destabilizing every internal and external application tied to the current data model.