How To Explain Code to People Who Control the Budget

If you can’t explain it simply, you don’t understand it well enough.

We have all had that moment. You push “deploy” and for a split second your heart stops. You stare at the monitoring dashboard and pray the graphs don’t turn red.

In 2012, for the engineers at Knight Capital Group, the graphs didn’t just turn red. They exploded. Because of a manual deployment error where they missed just one server out of eight, an old piece of code woke up. It was supposed to be dead code, often called “technical debt,” but instead it started buying high and selling low like a maniac.

In 45 minutes, the algorithm lost $440 million. The company was bankrupt before lunch.

I think about that story a lot. Not because of the money, but because of the conversation that likely happened six months before the crash. I guarantee you those engineers knew their deployment process was manual and scary. They knew that dead code was sitting there like a landmine. But they probably went to management and said, “We need to refactor the deployment pipeline to reduce configuration drift.”

And management heard, “We want to spend money to fix something that isn’t broken.”

If they had said, “We are sitting on a $440 million risk that could wipe out the company in under an hour,” the check would have been signed before they finished the sentence.

The “Rosetta Stone” of Engineering

The biggest lie we tell ourselves as engineers is that executives “don’t get tech.”

Trust me, they get it just fine. They just keep score differently. While you are sweating over Latency, Code Quality, and Uptime, they are looking at Revenue, Cost, and Risk.

If you walk into a meeting speaking “Kubernetes” and they are listening for “Q3 Revenue,” you are going to lose. You need a translator.

The Translation Dictionary

I used to get frustrated when my cleanup projects got rejected. Then I realized I was pitching the wrong things. Here is how I learned to translate “dev speak” into “money speak” for my boss.

1. The “Refactoring” Pitch

• What you want to say: “This code is spaghetti and I hate working in it. We need to rewrite it.”
• What you should say: “Our current messy code slows us down. Right now it takes us 4 weeks to ship a feature. If we clean this up, we can ship 3 features a month instead of one, without hiring more people.”
• (Translation: You are selling Speed and Efficiency).

2. The “Security” Pitch

• What you want to say: “We need to upgrade this library because it has a CVE.”
• What you should say: “We have a vulnerability that makes a data breach likely. The average breach costs a company like ours $4 million. Spending $10k now reduces that risk to almost zero.”
• (Translation: You are selling Insurance).

3. The “Infrastructure” Pitch

• What you want to say: “We need to use this cool new cloud tool.”
• What you should say: “Every minute our site is down, we lose $5,000 in sales. This tool guarantees we stay up, protecting $200k in revenue next year.”
• (Translation: You are selling Revenue Protection).

The One-Page Rule

The next time you want to propose a big technical change, please, I beg you, do not send a 10-page architecture document. Nobody reads it.

Send a One-Pager. Just four bullet points:

1. The Problem: What is broken, and how much money is it costing us?
2. The Solution: What are we building? (Keep it high-level).
3. The Cost: How long will it take?
4. The Payoff: What does the business get out of it?

The Senior Shift

Junior engineers think their job is to write code. Senior engineers know their job is to deliver value using code.

When you start speaking the language of the business, something magical happens. You stop being the “cost center” that needs to be managed, and you start being the “business partner” who gets the budget.