In 2023, the engineering team at Prime Video did something that looked like career suicide. Prime Video They had built a tool to monitor video quality streams using a modern Serverless architecture. It used AWS Lambda and Step Functions. It was decoupled. It was scalable. It followed every single industry best practice. There was just one problem. The bill. The bill. At just 5% of the expected load, the cost of passing data between these distributed components was astronomical. The “correct” architecture was going to bankrupt the project. So, they did the unthinkable. They argued against the industry standard and proposed moving back to a Monolith. Monolith They didn’t win that argument by saying “Monoliths are better” or by debating architectural purity. They won by showing the math. They proved that by packing the components into a single process, they could eliminate the expensive data transfer costs. The result? They reduced their infrastructure costs by 90%. They reduced their infrastructure costs by 90%. They didn’t follow the Hype. They followed the Evidence. The Problem with “I Think” We have all been in that meeting where two senior engineers are locked in a stalemate. One wants to use Rust because it is memory safe. The other wants to use Go because the team knows it. They argue about “best practices” and “what Netflix does” for an hour. The meeting ends with “let’s take this offline,” which is just corporate-speak for “let’s argue on Slack for three more days.” This happens because we try to lead with Opinion. Opinion When you are a Senior Engineer, you often have to influence decisions without having direct authority. You can’t just say, “Do it my way because I said so.” If you want to win these debates, you have to stop arguing about Preferences and start arguing about Trade-offs. The Toolkit for Persuasion You cannot mandate decisions, but you can guide them. The trick is to bring evidence in a format that people can actually evaluate. 1. Code Wins Arguments. 1. Code Wins Arguments. Theoretical arguments go in circles forever. Code ends the conversation. Next time someone says, “I think Library X is faster,” don’t argue with them. Spend two hours building a rough prototype. Run a benchmark. When you say, “I built a minimal version of both. Option A processes 1,000 transactions per second and Option B processes 450,” the debate ends immediately. 2. Speak the CFO’s Language 2. Speak the CFO’s Language Engineering managers and VPs care about Velocity and Cost. You need to translate your technical preference into their language. Don’t say “Serverless is cool.” Say “Serverless costs $X per stream. A Monolith costs $Y per stream. Moving to a Monolith saves us 90% of our operating budget.” Management listens to ROI. They tune out technical preferences. 3. The “Steel Man” Technique 3. The “Steel Man” Technique The fastest way to lose a debate is to ignore the other side’s valid points. If you want to win, you must articulate their position better than they can. Before you present your solution, say: “You might wonder why I am arguing against Serverless, given its flexibility. I agree that it offers superior scaling for bursty workloads. However, our workload is constant, which makes the cost premiums of Serverless a bad investment for us.” When you acknowledge the trade-offs, you earn trust. You show that you aren’t trying to “win” a fight. You are just trying to be right. A Real Example: Uber’s Heresy Prime Video wasn’t an isolated incident. In the early 2010s, Uber did something that shocked the engineering world. They migrated their core trip data from Postgres to MySQL. Uber Postgres MySQL At the time, Postgres was considered the superior database by almost everyone. It had more features. It had a better community. Moving to MySQL felt like a step backward. But the Uber infrastructure team didn’t argue about features. They argued about Disk I/O. Disk I/O They presented evidence showing that the way Postgres handled updates was crushing their hard drives at Uber’s specific scale. Every time they updated a trip record, Postgres had to rewrite too much data. MySQL was “dumber” but handled these specific updates much more efficiently. They didn’t choose the “Best Database.” They chose the Best Tool for the Constraint. Best Tool for the Constraint. Your Homework Look at the next technical alignment on your team’s calendar. Prepare one piece of evidence before you walk into the room or join the call. one piece of evidence It could be a spreadsheet comparing cloud costs. It could be a rough prototype benchmark. It could be a list of tickets from the last time you tried this approach and failed. Don’t go in with an opinion. Go in with data.

The is an opinion piece based on the author’s POV and does not necessarily reflect the views of HackerNoon.

Netflix

Slack

The “Best Practice” Trap

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Crunch Time Is Just Debt in Disguise

The Most Dangerous Sentence in Software Engineering: “We Can Build This Better”

The Best Code Doesn’t Matter If It Never Ships

Compose Drawing Mastery - Part 2 - Transformations

105 Stories To Learn About K8s

10 Ways to Future-Proof Your Business With Cloud

Crunch Time Is Just Debt in Disguise

The Most Dangerous Sentence in Software Engineering: “We Can Build This Better”

The Best Code Doesn’t Matter If It Never Ships

Compose Drawing Mastery - Part 2 - Transformations

105 Stories To Learn About K8s

10 Ways to Future-Proof Your Business With Cloud

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps