diff --git a/linkedin-posts/personal/deploy-freeze-fridays.md b/linkedin-posts/personal/deploy-freeze-fridays.md
new file mode 100644
index 000000000..d5fc997d2
--- /dev/null
+++ b/linkedin-posts/personal/deploy-freeze-fridays.md
@@ -0,0 +1,58 @@
+---
+title: "Your Friday deploy freeze is teaching your team to ship risky code on Thursday"
+lane: personal
+pillar: teach
+author: paul-keen
+voice: peer
+persona: ravi
+opener_archetype: observation-led
+icp_test: Does the "a deploy freeze is a deploy bottleneck, not a quality control" take land with tech leaders, senior engineers, and CTOs, and do they share the freeze they would drop first?
+image: ""
+first_comment: |
+  (value post - no link; reply-CTA only)
+utm_campaign: ""
+utm_content: deploy_freeze_fridays
+status: draft
+stage: future
+proposed_for: "2026-09-03 17:00 CEST"
+notes: |
+  Pillar: teach (the 70% value; NO course link). Audience for this task: technical
+  senior specialists, tech leaders, CTOs. This is the SECOND reader in the t_bd379f8c
+  series (Maya / senior specialist posted as PR #614) - this one targets Ravi, the
+  tech leader (EM / Director / VP Eng) who must turn a principle into team behavior
+  and is tired of advice that dies in standup. Reuses the same "tips & tricks +
+  use case + what works vs what doesn't" shape, grounded in a VERIFIED story-bank
+  case (the $40k Upwork MVP audit: recurring availability errors, message-freelancer
+  -> negotiate-a-fix -> wait days loop) so the sourcing gate is cleared - no
+  hypotheticals. Peer register, no em dashes, close is a real question, no CTA/link/JT.
+  Image: left empty on purpose - text-only is a valid Holub-register choice for a
+  blunt take, and the repo's native-upload attach step is Paul's manual gap per the
+  README known-tooling-gap note. Queued (stage: future) for pre-verify; scheduled_for
+  stays Paul-gated per doctrine.
+---
+
+A deploy freeze does not make your code safer. It moves the risk to the last open day before the freeze.
+
+The team I audited had a hard rule: no production deploys on Friday. Sounds responsible. What it actually did was push every release into a Thursday afternoon rush. Big batches, skipped review steps, "we will watch it Monday" as the test plan. The Friday quiet was bought with a Thursday pile-up.
+
+The real pain was not the calendar. It was recurring availability errors and the loop of message the freelancer, negotiate a fix, wait days. The freeze was not the control for that. Better monitoring and smaller, more frequent deploys were.
+
+Here is the test I run before adding any process gate. Write one sentence: "If we removed this rule, the failure we would fear is ____." If the blank is "a bad deploy ships unnoticed," the fix is a canary and a rollback, not a calendar block. If the blank is genuinely "people stop caring about quality," that is a culture problem a freeze will not touch. Run that sentence on your next ceremony-before-shipping proposal.
+
+Use case: the same team dropped the Friday freeze and switched to small deploys with a health check and a one-click rollback. Availability errors still happened. Now they shipped a fix in under an hour instead of waiting three days for the next "safe" window. The freeze had been hiding the slow fix loop, not preventing the bugs.
+
+What is working:
+
+- Small, frequent deploys with automated health checks. The blast radius of any bad change stays tiny, so "when can we ship" stops being a meeting.
+- On-call ownership of the deploy it ships, not a separate ops team that catches the fall. The person who wrote it watches it land.
+- A real rollback path tested before the deploy, not a hope.
+
+What is not:
+
+- A freeze as a substitute for deployment safety. It relocates risk to the day before and rewards big-batch Thursday pushes.
+- Treating "no deploys on Friday" as a maturity signal. Maturity is shipping small on Friday and not caring, because the blast radius is one customer at most.
+- Adding a ceremony (approval, sign-off, meeting) to fix a tooling gap. The gap was observability and rollback, not discipline.
+
+One claim I would not stake my name on yet: my read, not a measurement, is that most "deploy freezes" are inherited from a release era that no longer matches how the team ships, and nobody revisited them. Test it on your own process before you quote it.
+
+Which freeze or approval gate would you drop first if you had a real rollback, and what would actually break?