Be ready to disappoint

Posted: 2025-11-21

The Council of Wizards laid the scroll before the benevolent King. The choice was absolute: a single signature would alter the fate of the realm.

The King hesitated. To accept the decree was to incite half the kingdom to anger; they would call him a traitor. To reject it would drive the other half to despair; they would brand him a fool.

Beyond explaining his reasons, what is a leader to do?

He must wear an armor of inner resolve, always ready to do what is right, and not let the eventual disappointment of others stay his hand.

☙

At Google, I once managed a brilliant engineer who lead a team of four engineers. He had taken over a software project I had started as a prototype and turned it into a mature solution that routed over 1 billion (!) RPCs per second, significantly improving the reliability and efficiency of Google services.

He was a craftsman, commited to technical excellence. He was passionate about doing The Right Thing: building software that was robust, sustainable and correct.

But as the system grew, the edges began to fray. Exotic configurations exposed cracks in the foundation. Bug reports started arriving, revealing real problems in our implementations.

The engineer approached me, heavy with the weight of these flaws:

“Users are reporting bugs,” he said. “And they are right! From their perspective, our software is failing.

Fixing this will be expensive. We need to rebuild major pillars of the system. We can’t do this with the hands we have. We don’t have a single engineer we can task with these bugs, without dropping commitments that are even more vital.”

He was distressed. He felt that the bugs in our software, into which he had poured his soul, were a reflection of his own character. To let his users down was a tax he paid with his peace of mind.

But we did not have more people! The company wouldn’t give us more engineers. We had to accept our constraints.

His growth as an engineer required him to accept a painful truth: His only option was to find cheap workarounds and, ultimately, deliver a hard message to our customers:

“Yes, you are right: our software has limitations. It does not work in these situations. We would love to fix it, but we can’t.”

☙

I have seen this pattern many times.

It happens at different stages, but I’ve seen it often at the high-end of Senior SWE (L5) or lower-end of Staff SWE (L6): capable engineers sometimes struggle when the best course of action requires letting someone down.

Their desire to avoid the pain of disappointing others causes them to make suboptimal choices. They shy away from risky projects where the impact is very high, but the chance of failure is real.

They use the wrong prioritization function: rather than seeking to maximize their impact, they optimize for minimizing disappointment.

Obviously, we should aim to be reliable. Disappointing others carries real costs. But there is a balance to be found.

Walk the difficult path: commit to projects that stretch beyond your comfort zone when higher risk of failure is justified by larger potential returns.

Accept “good enough” solutions. Be prepared to explain when you can only offer workarounds, rather than the cure others may prefer.

It sometimes helps to disentangle your core identity from your work. Do your best within the constraints you face; if the output isn’t perfect, it may be more a reflection of those constraints.

Clarity helps. Be upfront! Do not ghost those who depend on you; that would be the wrong conclusion.

Instead, make an honest and respectful effort to explain your choice (and make sure your management chain is informed). For example:

“I must apologize. I will not be able to deliver my commitment. I have been pulled into a priority that’s critical for my organization. I know this is disappointing, and I wanted to tell you directly that I regret the impact this has on you.”