Shift — Engineering — Ethan McNamara

01

In plain English

What it is: A planning tool that shows what else needs to move when a key project date changes.
How it works: You would move a milestone and preview the affected deadlines. Dates tied to that milestone would follow; fixed bookings would stay put, with any clashes flagged before you approve the new plan.
Why it matters: To understand a schedule change before committing to it, including the bookings that need a conversation.

02

The product film

See the consequences before you move. A task, a deliberate gesture and its result, inside a reconstructed Signal Studio. It plays on its own while it is on screen; pause it, scrub it, slow it down, or read it as stills.

Scene rendered by preview-shift.js · 48s · 5 beats · 3 stills

03

What it is worth

A new date. Fewer surprises.

When a launch moves, the work around it changes too. See which dates can follow, which bookings need a conversation, and what the new plan would mean before you commit.

See the knock-on effectsRelated deadlines show where they would move.
Keep real commitments visibleA fixed booking stays in view when the plan changes.
Make an informed decisionUnderstand the clash before applying a new schedule.

04

How it is built

A launch moves by a week. Everything tied to it follows; one fixed booking does not. The gesture is a preview — the schedule has not changed, and the film refuses to pretend it has.

Position in the Shift gesture

ease-in-out cubic
cubic-bezier(0.65, 0, 0.35, 1)

The milestone moves: 1500ms
Dependent dates follow: 5000ms
The clash surfaces: 5000ms

Dependent dates move together on a shared transform so they read as consequence rather than as separate events. The fixed booking stays exactly where it was, and the collision is what the eye lands on.

The film ends unresolved. The preview is held, the current schedule is unchanged, and the value is a better-informed conversation — not an animation that makes every date change look safe.

This is the one film where the ending is a problem rather than a result. It is also the one that gets the most questions, which is the point.

05

The working model

Dates carry relationships. Moving a milestone should expose those relationships before it changes the plan.

The boundary that matters The scheduler can calculate and explain a conflict. It cannot renegotiate a fixed real-world commitment.

Two paths: Standard flow and A fixed commitment conflicts · 5 stages each

06

How it fits together

A person acts, the system checks, a result follows — and one other path, for when the check does not pass. This describes proposed responsibilities and decisions, not deployed infrastructure.

Read the diagram source

%% Director-friendly architecture. Maturity and limits are recorded in accDescr.
flowchart TB
  accTitle: How Project Shift works
  accDescr: A project manager proposes a milestone date. Signal calculates linked dates using the working calendar while keeping fixed commitments unchanged. The manager reviews the effects and resolves conflicts. An approved plan is applied only if its schedule and calendar are still current; otherwise a fresh preview is required. This scheduling architecture is proposed.
  A(["Project manager<br/>Moves a milestone"])
  B("Schedule preview<br/>Moves linked dates only")
  C(["Project manager<br/>Reviews changes; resolves conflicts"])
  D{"Approved plan<br/>still current?"}
  E("Project schedule<br/>Reviewed dates applied")
  X("Plan changed<br/>Review a fresh preview")
  A -->|Working calendar| B
  B -->|Fixed bookings stay| C
  C -->|Approve clear plan| D
  D -->|Still current| E
  D -->|Changed meanwhile| X
  classDef human fill:#faf7f2,stroke:#bf8c53,color:#24211c;
  classDef work fill:#ffffff,stroke:#a3a5ad,color:#25262a;
  classDef decision fill:#f3efff,stroke:#967bcb,color:#30244c;
  classDef result fill:#f0f6ff,stroke:#7b9dca,color:#1d365b;
  classDef exception fill:#fff5ec,stroke:#ce9b63,color:#64431e;
  class A,C human;
  class B work;
  class D decision;
  class E result;
  class X exception;

07

The case study

Rescheduling is a dependency calculation with exceptions, not a bulk date edit.

The problem

A launch moves two weeks. Relative preparation should follow it, but a fixed supplier booking should not. Shifting every deadline can make a plan look coherent while introducing real conflicts.

The insight

Make the relationship behind a date explicit, then explain each consequence before applying it.

The system

The proposed scheduler evaluates relative offsets over a validated dependency graph using an explicit working calendar. A preview separates moved dates, fixed commitments, and conflicts. Applying the result checks that the project has not changed since calculation.

The rationale

An explained preview makes schedule changes easier to discuss and helps teams see which commitments need negotiation.

Responsibilities

Milestone change: Proposed date, dependency rules, and working calendar.
Schedule calculation: Resolve relative dates and identify fixed-date conflicts.
Reviewed apply: Explain each movement and check the source revision.

The boundary

Shift calculates consequences; it cannot renegotiate a fixed commitment or infer which real-world dependency should take priority.

The trade-off

Explicit dependency modelling takes more effort than free-form dates. In return, the system can show why a date moved and where automatic movement must stop.

When it fails

Dependencies form a cycle

Identify the cycle and block calculation for the affected chain instead of producing an arbitrary schedule.

A fixed booking conflicts

Keep the commitment fixed and surface the conflict for a person to resolve.

The calendar changes mid-preview

Recompute using the current schedule and calendar version before allowing the changes to be applied.

Evidence Design proposal · local demonstration uses synthetic data

08

On the design side

Moving a date is the day surface under pressure. The day deck is where the run of show, the call sheets and the live afternoon were worked out.