Success is never guaranteed. Courage only matters if failure is a possibility.
We like to tell stories about courage after the outcome is known. The project shipped. The migration succeeded. The risk paid off. Once success has made the decision look inevitable, we recast uncertainty as confidence and fear as foresight.
That is not how courage feels while you are living it.
Courage is doing the right thing when you are scared. It is making the recommendation before you know whether it will work, telling an executive what they do not want to hear, and accepting that your judgment may cost you credibility, opportunity, or even your job.
The Romans called this virtus. The word carried ideas of martial courage, excellence, and character. Its martial roots need translation for modern engineering leadership, but not abandonment. Leadership still demands action under pressure when the stakes, risk, and fear are real.
Not violence. Not conquest. Not performative aggression.
Character expressed through action.
Say what is true, advocate for what is right, and accept the consequences of doing so.
That is virtus in engineering leadership.
Say What Is True
Engineering leaders are often asked to make reality more convenient.
Executives want ten months of work completed in eight. Product leaders want the next feature without paying for the instability underneath it. Teams want a rewrite because the current code offends their sensibilities. Everyone wants certainty before making an expensive decision.
Your first duty is to say what is true.
Early in my career, I was asked to plan a major project. The plan came to ten months. The executives wanted it in fewer than eight.
There was a great deal of back and forth. They applied pressure. I revisited the plan. We discussed it again. The answer remained ten months.
You can negotiate scope, staffing, sequencing, or risk. You cannot negotiate ten months of work into eight through pressure alone.
That was not defiance. It was the truth. Telling them anything else would have produced a more comfortable meeting and a failed commitment.
Three times in my career, I have had to tell executives that a product could no longer support where they wanted the business to go. Each time, I recommended rebuilding it from the ground up. As you might expect, none of those conversations was initially received well.
That resistance was reasonable. Rebuilds are expensive, risky, and routinely underestimated. Engineers often argue for them because they dislike inherited code, want to use a new technology, or mistake architectural beauty for business value.
The rebuild is not justified because the old code is ugly. It is justified when the old product can no longer do the job.
The Harder The Truth, The Stronger The Evidence
In 2006, the company I worked for operated several e-commerce sites written in ColdFusion. Those sites broke on a literal daily basis. We had a staff member whose full-time job was to repair them.
I believed we needed to replace them, but belief was not enough. I envisioned a top-of-the-line e-commerce experience, but the accepted wisdom was that our customers did not care about high-performing, beautiful websites and couldn’t load them anyway. That made no sense to me. Someone willing to spend $10,000 on a table saw for a hobby was making a serious purchase and would benefit from a fast, useful site for researching it.
So I did the work required to make the case defensible. I processed two years of server logs to prove that our customers had broadband access and were ready for the experience I wanted to build. I researched the market, developed a complete plan, and presented it to the entire executive board.
The company approved the rebuild. The shared platform powered five websites, including Powermatic.com, and launched in July 2007. Full product pages loaded in about one second. For the products the company sold, our sites ranked above Amazon in organic search. The daily repair work disappeared completely.
The outcome validated the recommendation, but the outcome came later. The courage happened when I walked into the boardroom with an expensive proposal for a platform I had never built.
In 2012, I faced a similar problem with the primary SaaS product at another company. It was a jumble of architectural styles assembled over years of changing needs. I proposed a modern user interface and an API layer that did not exist in the legacy product.
That CEO was more receptive, but the recommendation still required persuasion and a proof of concept. The resulting product introduced new interface patterns, caching, and more efficient database access. Performance improved dramatically, the experience became smoother, and customers received it well.
Today, I am in the middle of another rebuild. A key sales application does not support the company’s future goals, and its performance does not give sales representatives the confidence or speed of action they need. This story does not have a triumphant ending yet. The work is still underway.
That matters because courage is not retrospective certainty. The current decision carries uncertainty just as the others did.
Courage does not excuse weak preparation. The harder the truth, the stronger the evidence must be.
Speaking truth to executives is not declaring that they are wrong. It is doing enough work that the truth can survive their resistance.
Advocate For What Is Right
Truth identifies the constraint. Advocacy asks the organization to pay the cost of removing it.
That is often the harder step. You can diagnose a problem accurately and still fail as a leader if you do not argue for the action it requires.
The right action is not always obvious from every seat. A technical leader sees fragility, maintenance cost, and operational risk. A financial leader sees investment, delayed revenue, and opportunity cost. A product leader sees commitments and customer expectations. They are looking at the same decision through different responsibilities.
Advocacy requires translating technical reality into terms the rest of the organization can evaluate. You cannot simply declare the technically correct answer and expect everyone else to recognize it as the right business decision.
Sometimes the right action is putting features ahead of the technical debt your team wants to fix. The business may have a narrow market window, a contractual commitment, or an urgent customer need. Engineers do not get to declare every internal imperfection the highest priority.
Sometimes the right action is the opposite. You must stop feature work because the foundation can no longer carry more weight.
The direction is not the point.
The truth is.
The 2012 SaaS rebuild delivered real value, but the founder and CEO shipped it before it was ready. That decision left the team with a bug backlog that eventually grew beyond 120 issues.
About a year later, after a leadership change, I made a strong case for putting nearly everything else on hold. The product did not need another round of features layered over unresolved defects. It needed focused remediation.
We paused. The team worked through the backlog and reduced more than one hundred bugs to about ten minor interface issues.
That was not glamorous work. It did not produce a dramatic new capability for a sales presentation. The new interface had initially earned customer goodwill, but the instability caused by shipping early burned through much of it. The remediation began earning that trust back. It restored reliability, reduced support costs, and gave the team a stable product to build on.
At a healthcare SaaS provider, the business wanted better dashboards and reporting for customers. The visible request was a product feature. The actual constraint was the database.
Several tables contained more than half a billion rows. Important indexes were missing, and the schema had structural problems that made the desired reporting impractical. Some queries could bring a 64-core PostgreSQL server to its knees, running for up to fifteen minutes. The feature could not be shipped.
The database contained more than twelve years of data, reaching back to the founding of the company. We were obligated to retain only five years. I advocated for pausing the dashboard work, archiving everything older than that requirement, refactoring critical parts of the database, and cleaning up the structures that made reporting so expensive.
That was a difficult recommendation. Customers could see a dashboard. They could not see an index, an archival policy, or a refactored table. The business had to delay visible progress to invest in the machinery underneath it.
I left while the work was still underway, so I will not claim a production result I did not witness. In the test database, however, those queries completed in about one second after the changes.
The dashboard was not blocked by the interface. It was blocked by the database. Building the visible feature first would have hidden the constraint, not removed it.
This is why engineers must learn to frame technical debt as a business choice. Executives do not owe us time to make code aesthetically pleasing. We owe them a clear explanation of fragility, operational cost, customer impact, and the consequences of delay.
Saying what is true identifies the constraint. Advocating for what is right asks the organization to act on it.
Put Your Name Behind The Recommendation
Advocacy without ownership is opinion.
Virtus begins when you are willing to be accountable for the recommendation.
In 2006, alongside the e-commerce rebuild, I advocated for placing a web service over every data source in the company. The goal was to turn the organization into a platform on which web applications could be built.
That may sound ordinary now. It was not ordinary then. The idea required a significant development investment without an obvious or immediate payoff. It also attached my credibility to a technical direction the company had never attempted.
It worked. The service layer became a foundation for the applications that followed.
Years later, I was hired by a mortgage SaaS provider to move customers from on-premises deployments into the cloud. The environments held sensitive data for mortgage companies. The design needed to be secure, isolated for every customer, scalable, repeatable, and achievable by the team that would operate it.
This was a new trail for me. The work built on technologies I understood, but the details involved a major learning curve. Failure could have exposed customer data, disrupted operations, damaged the company, and ended my time there. Delivering the migration was the reason I had been hired.
I could not remove that risk. I could prepare for it.
The design used fully independent customer environments and infrastructure-as-code automation. We delivered it three months ahead of schedule. Eventually, every customer moved to the cloud. Provisioning a new customer environment went from a week-long process to about four hours.
Again, success makes the decision look obvious in retrospect. It was not obvious when the architecture was still on paper and the consequences of failure were mine to carry.
The e-commerce platform and the cloud migration shared an important quality. In both cases, I understood the underlying technology, but I had never built that exact kind of system before. I could not point to a prior personal success as proof that the next one would work.
I had evidence, a plan, and principles. I did not have certainty.
Courage happened before the result was known.
Courage Is Not Recklessness
There is a dangerous version of this argument. A leader can mistake confidence for courage, make an impulsive bet, and then demand credit for being bold.
That is not virtus. That is gambling with someone else’s company.
Courage does not mean ignoring risk. It means looking directly at risk and acting because inaction is worse. It means doing the research, building the proof of concept, validating the assumptions, designing the isolation, automating the infrastructure, and making the tradeoffs visible.
Fear contains information. It tells you where the consequences live. Good leaders listen to that information without surrendering to it.
Preparation cannot guarantee success. It can turn fear into a list of questions, risks, mitigations, and decisions. It gives the organization an honest chance to choose.
There is no courage in pretending failure is impossible.
There is courage in understanding how failure could happen, preparing for it, and acting anyway because the work matters.
Accept The Consequences
Perhaps the clearest example of corporate courage I have witnessed happened in 2009. The new CEO of our parent company announced that the marketing and IT functions would move from the United States to Switzerland.
Our U.S. CEO, an industry veteran with an impeccable track record, warned the board that European marketing could not replace an understanding of the U.S. market. He also argued that the top-of-the-line IT organization could not be easily relocated or replaced. When the parent company’s CEO refused to reconsider, he tendered his resignation, stood up, and walked out.
This was not a rage quit. He understood the business and the personal cost of his decision. He put his career on the line rather than lend his authority to a decision he believed would destroy what he was responsible for protecting.
He did not win the argument. He said what was true, advocated for what he believed was right, and accepted the consequences immediately.
Engineering leaders do not control every outcome. We control whether we tell the truth, whether we advocate for the right response, and whether we stand behind our judgment.
Sometimes the executive will reject the recommendation. Sometimes the company will choose the deadline over the risk. Sometimes the team will resent the feature work you prioritized over the cleanup they wanted.
Sometimes you will be wrong.
Accepting the consequences does not mean seeking punishment or treating every disagreement as a moral battle. It means refusing to hide behind ambiguity after the decision is made. You gave the best recommendation you could support. You made the risks clear. You put your name behind the path forward.
Then you do the work.
Kill the bad project. Escalate the real risk. Tell the executive the plan is not credible. Give the direct feedback. Stop the rewrite that has become an ego project. Say no to the shiny technology only one person can maintain. Pause the visible feature when the invisible foundation is failing.
These moments do not feel noble while you are in them. They feel heavy. Your stomach tightens. You wonder whether you are about to damage a relationship, lose political capital, disappoint the team, anger the business, or make the wrong call in public.
That is why it is courage.
Not because you are certain.
Because the decision matters, failure is possible, and you act anyway.
Say what is true. Advocate for what is right. Accept the consequences.
That is virtus.