- SalesforceChaCha
- Posts
- π Death by a Thousand Quick Wins πΊ
π Death by a Thousand Quick Wins πΊ
Why Enterprise Salesforce Releases Become Slower Over Time
Good morning, Salesforce Nerds! Who remembers βthe good old daysβ?
A new required field used to ship before lunch. β
Now the same change needs a user story, three approvals, a regression run, and a release window two sprints out. π
What happened?
In my experiences β¦ your team didn't get slower.
Your org got heavier.
Release velocity decay is structural. It compounds quietly, the way interest does, until an org that once moved in days moves in quarters. π
The forces behind it are boring and predictable. Name them, measure them, and you can fight them.
Ignore them, and they win by default. ποΈ

TABLE OF CONTENTS
π Death by a Thousand Quick Wins πΊ
INTEREST COMPOUNDS WHILE YOU SLEEP
DEBT NEVER SHIPS ALONE
Technical debt is not messy code. It is deferred decisions that someone, someday, pays back with interest. πΈ
Every shortcut you ship adds a small tax to every future change that touches it. One hardcoded ID. One trigger without a handler. One "we'll refactor later" that never arrived. β°
Individually, each is harmless. Collectively, they form a layer you must decode before you can safely modify anything.
That decoding is the real cost. A new engineer needs weeks to learn which automations fire on Account update, and in what order. π€―
Debt does not slow the change you are making. It slows every change you make near it.
The blast radius of a one-line edit grows with the debt around it. In a clean org you touch one thing. In an indebted one you touch one thing and pray. π
EVERYTHING TOUCHES EVERYTHING NOW
THE ORG ATE ITSELF
A young org has clean seams. A mature org has none.
Objects accumulate fields, validation rules, flows, triggers, and permission sets until everything quietly depends on everything else. πΈοΈ
This is metadata sprawl, and dependency entanglement is the symptom. Change a field's type and you may break a Flow, a formula, a report, and an integration you forgot existed.
The worst tangle lives in automation. Most enterprise orgs run a brittle mix of record-triggered Flows, Apex triggers, and legacy Process Builder logic firing in an order no one fully controls. π₯
That mix got more dangerous lately. Workflow Rules and Process Builder reached end of support on December 31, 2025, so existing automations keep running but no longer receive bug fixes from Salesforce.
You now maintain logic the platform has stopped maintaining. Every deploy near it carries risk you cannot fully test for, because the execution order is emergent, not designed. π¬
TESTS THAT NEVER END
YOUR TESTS GOT GREEDY
Salesforce makes a quiet promise that gets expensive at scale. Production deployments run your Apex tests, and you need 75% coverage to ship. β
In a small org that is a two-minute gate. In a large one it is a bottleneck with a clock on it.
Thousands of test methods, slow data setup, and serialized execution turn validation into a 30, 60, or 90-minute wait per deploy. β³
And coverage is a floor, not a guarantee. Teams chase the 75% number with assertion-free tests that prove nothing except that the code ran.
Worse, mature suites rot. Flaky tests fail at random and brittle assertions break on unrelated changes. Teams re-run pipelines hoping for green instead of fixing the cause. π
Now every release waits on the slowest, least reliable part of the system. Velocity rarely dies from one big failure. It bleeds out through a hundred re-runs.
TOO MANY COOKS, ONE PIPELINE
CONSENSUS IS THE NEW BOTTLENECK
Early on, one person owns the org and ships at will. That does not survive success.
As teams grow, the constraint shifts from writing the change to agreeing on it. π§βπ€βπ§
More contributors mean more merge conflicts, more shared metadata, and more release trains that must depart together or not at all.
Governance then arrives for good reasons: approvals, change advisory boards, and environments that must stay in sync. Each one adds safety and latency in equal measure. π¦
A single shared sandbox becomes a queue. A weekly release becomes a negotiation. The work is finished; it just waits for everyone else's work to be ready.
This is coordination overhead, and it scales with headcount, not with complexity. The bigger the team, the more of the calendar belongs to consensus. π
AUDIT, QUARANTINE, REPEAT
STOP THE BLEEDING FIRST
You will not reverse decay with a heroic rewrite. You manage it, the way you manage any chronic condition. π©Ί
Start by measuring it. Track lead time for changes and deployment frequency so decay becomes a number, not a feeling.
Then triage the worst offenders:
Quarantine flaky tests and parallelize the suite so validation stops gating every deploy. π€
Map automation order on your busiest objects before you touch them, and retire unsupported Process Builder logic deliberately. π€
Decouple release trains with source-driven development in GitHub and a tool like Gearset, so independent work ships independently. π€
Adopt FFLIB or a similar pattern to put seams back into the code, giving future changes somewhere safe to land.
None of this makes the org young again. It keeps a heavy org shippable, which at enterprise scale is the only victory that lasts. ποΈ
SOUL FOOD
Todayβs Principle
"A little debt speeds development so long as it is paid back promptly with a rewrite."
and now....Salesforce Memes



What did you think about today's newsletter? |