I Bored a CEO to Tears and It Changed How I Write Updates Forever

August 4, 2025

I once had to explain a critical database migration to our CEO. I had five minutes.

I walked in, armed with slides full of architectural diagrams, query performance benchmarks, and a detailed list of instance types. I was proud of it. We were doing good work.

Two minutes in, her eyes glazed over. By minute four, she was checking her phone under the table. I finished my spiel, she said “Thanks for the update,” and I walked out knowing I had completely, utterly failed.

She didn’t get it. And it was my fault.

I was sending the same update to everyone: my engineering manager, the product lead, and the C-suite. I thought I was being efficient. In reality, I was just being lazy, and it was costing my team. That project, which was foundational for the company’s next three years, was seen as a boring “cost center” thing. We fought for every scrap of headcount and budget.

It took me years to learn the lesson: you can’t just tell people what you did. You have to tell them why it matters to them.

And that means you need three different versions of every single technical update.

The Three People You’re Actually Talking To

Forget “stakeholders.” You’re talking to three groups of people with very different anxieties:

1. The People with the Money (Executives): The C-suite, VPs, and finance folks. They live in a world of spreadsheets, risk, and competition. They’re constantly asking, “Are we spending our money on the right things? Will this make us more money or save us from losing it?” They don’t care about PostgreSQL vs. MySQL. They care about market share and P&L statements.

2. The People Who Talk to Users (Product & Customer Teams): Product managers, designers, customer success, and sales. Their world revolves around user complaints, feature roadmaps, and support tickets. They’re trying to answer, “Will this make our customers happier? Can I sell this? Will it stop the flood of tickets about the dashboard being slow?”

3. The People in the Trenches (Your Fellow Techies): Engineers, architects, DevOps, SREs. We live here. We care about elegant design, manageable tech debt, and not getting paged at 3 AM. We need to know, “How is this built? What are the tradeoffs? How do I not break this when I deploy my feature next week?”

Sending a technical spec sheet to the CEO is noise. Sending a business-impact summary to an engineer is useless. You have to speak all three languages.

War Story: The Great Database Migration of ‘23

Let’s go back to that database migration. It was a beast. We were moving off a creaky, self-hosted PostgreSQL instance that a contractor had set up six years ago and then vanished. It was a ticking time bomb held together with duct tape and hope. Here’s how I should have communicated it.

Version 1: The “Please Don’t Cut My Budget” Email to the CEO

Subject: Fixing Our Database Problem: Cutting Costs and Reducing Outage Risk

TL;DR: We’re finishing the database migration. This move will cut our hosting bill by ~35% (saving ~$185k/year) and dramatically reduce the risk of another embarrassing Q3-style outage.

The Payoff:

• Cost Savings: We’re on track to save ~$185k this year by moving to a more efficient cloud setup. I expect that to hit closer to $220k once we fully decommission the old hardware next quarter.
• Stability: Remember the outage in July that hit our top 20 enterprise clients? This new architecture is built to prevent that specific failure. Our uptime should climb from a shaky 99.8% to a solid 99.95%, which lets us offer a real SLA.
• Future-Proofing: We can now handle the 5x user growth a new partner is projecting without another massive, last-minute engineering fire drill.

Version 2: The “I Have Good News” Slack Message to Product

Subject: The Dashboard is About to Get WAY Faster

Hey team, good news from the database migration. We’re seeing massive performance wins that will directly impact users:

• Dashboard Load Times: You know how the main dashboard can take 8-12 seconds to load on a bad day? It’s now consistently under 2 seconds. This should kill a whole category of customer complaints.
• Faster Search: The main search bar is about 4x faster. It feels snappy now.
• Heads Up: To get this done, we had to put the “advanced report filtering” optimizations on the back burner. It’s no slower than before, but it’s not faster yet. That’s a follow-up for next quarter. Let’s sync on where that fits in the roadmap.

Version 3: The “Here’s the Gory Details” Update for Engineering

Subject: PostgreSQL Migration to RDS is Done - Read This Before Deploying

The TL;DR: We successfully migrated the primary user DB from that self-managed Postgres nightmare to AWS RDS. The cutover had a few bumps, but we’re stable now.

The Nitty-Gritty:

• Architecture: We’re on an r6g.2xlarge RDS instance with Multi-AZ. We have two read replicas handling most of the dashboard and reporting queries. Connection pooling is now managed by PgBouncer.
• The “Gotcha”: We spent two days chasing a bizarre latency issue that turned out to be the old app server’s aggressive connection caching fighting with PgBouncer. We had to force-cycle the app servers to fix it. Watch out for that.
• Near Miss: The cutover plan was solid, but we almost got bitten by a stale DNS entry with a 24-hour TTL. We had a 10-minute partial outage for some users until we could force a propagation. A good reminder to double-check TTLs next time.
• Cleanup: There are still a bunch of hardcoded IP addresses in older parts of the monolith pointing to the old DB. I’ve ticketed them, but let’s be vigilant.

This Seems Like a Lot of Work (Because It Is)

I know what you’re thinking. “I don’t have time to write three different novels for every little update.”

I get it. At first, we just used a messy Google Doc with three sections as a template. It was a pain, but it was better than the glazed-over eyes. The difference was immediate. Our product manager started using our performance wins to close deals. The CFO started seeing our team as an investment, not a cost.

Eventually, the copy-pasting got old. We started looking for tools to help. We use a platform called BenefitGen now, where we plug in the technical details and it helps us draft the summaries for each group. It turns a 45-minute chore into a 10-minute task.

But the tool isn’t the point. The discipline is the point.

Whether you use a template, a tool, or just sheer willpower, you have to start translating. Your job isn’t just to write code. It’s to make sure the brilliant, difficult, and essential work you do is understood by the people who depend on it. Don’t let your best work die in a meeting nobody understands.