Stop Saying “Improved Performance”

 

Stop Saying “Improved Performance”




Say What You Actually Changed

Early in my career, I used to write lines like:

  • Improved performance

  • Built a scalable system

  • Optimized cost

  • Enhanced reliability

They sounded good.

They were also meaningless.

Over time, I realized something uncomfortable:

Vague language makes strong engineering look average.

And strong engineering deserves precision.

Why “Fuzzy” Engineering Hurts You

When you say:

“Improved performance”

No one knows:

  • By how much?

  • Compared to what?

  • Under what load?

  • With what trade-offs?

It forces the listener to guess.

And when people guess, they assume small impact.

In reality, engineering impact is almost always tied to:

  • A number

  • A constraint

  • A trade-off

If those are missing, your work feels shallow even when it is not.

The Rule I Follow Now

I do not describe work unless I include at least one of these:

A number.
A constraint.
A trade-off.

That rule changed how I communicate.

Instead of saying:

“Improved API performance”

Say:

Reduced P95 from 850 ms to 120 ms by tuning WebFlux thread pools and adding Redis caching.

Now people understand:

  • The baseline

  • The outcome

  • The technical lever used

  • The impact

Instead of saying:

“Built scalable architecture”

Say:

Stabilized P99 under 450 ms for 2,500+ monthly sign-ups by converting blocking endpoints to reactive flows and introducing blue-green deployments.

That sentence communicates scale, reliability, and architectural maturity in one line.

Why This Matters More Than You Think

This is not about resumes.

This affects:

1. Standups

“Working on performance improvements” is vague.
“Investigating DB fan-out causing 30 downstream calls per request” is actionable.

2. Code reviews

“Refactored for clarity” is fuzzy.
“Removed duplicate validation logic across three controllers to prevent inconsistent error responses” is specific.

3. Architecture discussions

“Let’s make it scalable” leads to endless debate.
“Let’s target 10K concurrent sessions with P95 under 300 ms” aligns everyone instantly.

Specific language reduces ambiguity.
Ambiguity is where engineering friction lives.

The Psychology Behind It

Numbers build trust.

Constraints show maturity.

Trade-offs demonstrate judgment.

When you say:

“We chose X over Y because it reduces latency but increases memory usage”

You are signaling that you understand engineering is not about perfection. It is about balance.

That is what senior thinking looks like.

The Hidden Benefit: Better Thinking

There is a second-order effect here.

When you force yourself to attach numbers to your work, you are forced to measure it.

And once you measure something, you start improving it intentionally.

If you cannot quantify impact, you probably did not define success clearly.

That is not a communication issue.
That is a thinking issue.

Try This Exercise

Look at your last three accomplishments.

Rewrite them using this template:

  • What was the baseline?

  • What changed?

  • What metric moved?

  • What constraint mattered?

If the sentence becomes stronger, you were being fuzzy.

If the sentence becomes uncomfortable, you were avoiding precision.

Final Thought

Strong engineers do not just build systems.

They understand impact, constraints, and trade-offs.

And they communicate them clearly.

If your work is meaningful, it deserves specific language.

So next time, do not say:

“Improved performance.”

Say exactly what improved.

___________________________________________________________________________________

Written by Sharath Chandra Odepalli

LinkedIn 

Comments

Post a Comment

Popular posts from this blog

Stop Building: Why Less Is More in Software Development

  Stop Building: Why Less Is More in Software Development The biggest waste in software isn't bugs, technical debt, or slow deployments. It's building features nobody uses. Research reveals a sobering truth: 45% of features are never used, 19% are rarely used, and only 36% are used regularly or often. Translation: nearly half of engineering effort creates zero value. Think about that for a moment. Half of all the sprints, all-nighters, code reviews, bug fixes, and deployment stress—wasted on features that users will never click. This isn't a small problem. It's the silent killer of engineering productivity and product success. The Three Forces Driving Waste Force 1: Engineers Love Solving Hard Problems We're wired to seek complexity. When faced with a problem, we instinctively reach for the sophisticated solution. A simple notification system? Why not build a real-time WebSocket infrastructure with Redis pub/sub and horizontal scaling? A basic reporting feature? Obv...
Read more

Clarity: The Most Underrated Skill in Technology

Image
There’s a quiet truth in the engineering world that people only discover after years of writing code, leading teams, and shipping systems: Your value in tech is measured far less by what you build and far more by how clearly you think. This isn’t intuitive. In a field obsessed with new frameworks, new architectures, and now new AI models—clarity feels almost… old-fashioned. But here’s the irony: The more complex the industry becomes, the more clarity becomes a competitive advantage. Complexity Isn’t Hard. Simplicity Is. If you’ve spent long enough in engineering, you’ve seen this pattern: A senior engineer writes code that works—but nobody else wants to maintain it. A team ships a feature—but half the customers don’t understand how to use it. A brilliant system is designed—but onboarding takes three meetings and an internal wiki. We call these “engineering problems,” but they’re actually  clarity problems . The hardest parts of building software aren’t the algorithms, the databases...
Read more

The Transparency Era: What California's New AI Law Means for Tech Builders

Image
  Yesterday marked a pivotal moment in technology regulation - one that signals we've crossed a threshold from which there's no turning back. Governor Gavin Newsom signed  SB 53 , California's first major AI transparency law, requiring the world's largest artificial intelligence companies to publicly disclose their safety protocols and report critical incidents within 15 days. This isn't just another piece of legislation lost in the noise of regulatory bureaucracy. It's a watershed moment that redefines the social contract between technology companies and the public they serve. From Voluntary to Mandatory: The Shift Nobody Saw Coming For years, AI safety has been a gentleman's agreement. Companies like OpenAI, Anthropic, Google, and Meta have made voluntary commitments to safety testing and responsible development. They've published research papers, formed ethics boards, and publicly discussed the importance of alignment and safety. But voluntary commitm...
Read more