For your reaction, not your adoption

Emi's Operating System

How I'm thinking about running my piece — a light, flexible model that flexes between diagnosing a problem and building something new.

2 / 14

Framing

This role is ambiguous by design

I drop into very different initiatives, and the teams I direct change every time.
So this isn't a process to impose — it's a light operating system that flexes between diagnosing a problem and building something new.
Here's how I'm thinking about running my piece. Tell me where this breaks.

3 / 14

The authority boundary

What I own — and what I don't

I own

The framing
The sequencing
The visibility
The clean handover

Their manager owns

Their roadmap
Their people's time
The capacity trade-off when priorities shift

Which is exactly why the buy-in cascade exists: I secure the manager who owns the time, not just the person.

4 / 14

The spine

Six phases, two modes

A light lifecycle, not a heavy PMO — diagnose-mode and build-mode flex per initiative.

Intake

Gate, not inbox

Diagnose Build

Plan

Capacity cascade

Mobilise

Minimum spine

Execute

Exception only

Closeout

Signed handover

Portfolio

Generated view

Diagnose mode

Ends in a recommendation and a decision-maker

Build mode

Ends in a working thing and an owner

5 / 14

Phase 1

Intake is a gate, not an inbox

One front door, so work stops arriving ad hoc. The power isn't tidiness — it's the evidenced no.
Triage at the door: take / defer / decline / redirect, with a one-line logged rationale tied to current capacity.
Handover bar and receiving owner are co-authored here, at the start — not at the end.

Intake form

Sponsor & decision-maker

Problem in one sentence

Desired outcome and how we'll know

People available and their managers

Who loses something if this succeeds?

Handover owner (named now)

DIAGNOSE BUILD

Triage decision

TAKE DEFER DECLINE REDIRECT

6 / 14

Phase 2

Plan: capacity is borrowed, not owned

The buy-in cascade: leadership names partners → org-level buy-in → managers release the time.
A written, lightweight commitment per contributor — person, manager, [hrs/week], duration.
RAPID for the few decisions that matter; name the Decider. RACI only for delivery tasks.

01 — Leadership

Names the established partners

02 — Org level

Buy-in confirmed across divisions

03 — Management

Secures the manager who owns the time

RAPID — decision rights

Decider named explicitly

7 / 14

Phase 3

Mobilise: a minimum shared spine

A recommended five-folder default; the team can reshape it, as long as the decisions log and the handover folder survive.
Truly non-negotiable is tiny: one channel, one place decisions are logged, one definition of done.
Everything else the team shapes. The standard's only job is to make autonomy safe and kill status meetings.

01_Charter

Intake brief, sponsor, success metric

02_Plan

Sequence, milestones, roles

03_Working

The actual artefacts

04_Decisions & Actions

The log the status-scrape reads

Non-negotiable

05_Handover

Built continuously — closeout is assembly, not authorship

Non-negotiable

"I ask three things of a project so I never have to ask you for an update."

8 / 14

Phase 4

Execute by exception — no status meetings

The trade: keep three things current — decisions, open actions, blockers/risks — and I'll never book a status meeting.
The system surfaces exceptions, not status: slipped milestones, red RAID items, blocked dependencies, silence.
Silence is a signal. The most dangerous status is the absence of one.

Live exception feed

Taito onboarding

Updated 2 hrs ago · 3 actions open

On track

Inner-source model

Updated 4 hrs ago · milestone due Fri

On track

Contribution process

Milestone slipped 3 days · dependency open

At risk

Security sign-off

Blocked 5 days — auto-escalates to management

Blocked

Handover documentation

No update in 6 days

Gone quiet

9 / 14

Phase 5

Handover: a signed bar and an end date

Verify against criteria agreed up front — don't invent the bar under time pressure at the end.
Owner signs: accepted owner, SOP run once unaided, metric instrumented, escalation named, support window with an explicit end date.
For inner-source, the bar must also answer: who are the maintainers, what's the contribution and merge process, who owns triage — questions for you, not assumptions.

Handover checklist

✓

Named accountable owner has accepted

✓

SOP exists and owner has run it once unaided

✓

Success metric is instrumented and being watched

✓

Escalation path and on-call are named

✓
Support window defined — after [date], it is fully theirs
End date

Benefits-realisation check-back at [30/60/90] days — so did it work has an answer

10 / 14

Phase 6

Portfolio: generated, never maintained

One row per initiative; three flags only — health (RAG), a people heat-map, cross-initiative dependencies.
The heat-map flags anyone load-bearing on 3+ initiatives — the silent-bottleneck detector.
Learnings library is a by-product of every closeout, so Manufacturing can reuse AEC's playbook instead of relearning it.

Initiative	Mode	Phase	Handover
Taito onboarding	Build	Execute	Q3
Inner-source model	Diagnose	Plan	Q4
Contribution process	Build	Mobilise	Q4

People heat-map

Taito

Inner-src

Contrib

Person A

●

○

Person B ⚠

●●●

Person C

○

●

Person B load-bearing on 3 initiatives — silent bottleneck

11 / 14

The engine

One engine, three faces (what I'd build over time)

Ingest → Normalise to one schema → AI maps to a template → Standard output → the doc plus a 90-second clip.
Same engine powers Phase 4 status, Phase 5 handover and Phase 6 portfolio — just a wider window each time.
Conceptual future state, subject to your security review. Day one is a manual drop-zone: paste a transcript, get a brief.

Ingest

Drop-zone today · connectors later

→

Normalise

One schema, 7 record types

→

AI processing

Extractive, not generative — cites source

→

Standard outputs

Status · Handover · Portfolio — one engine, wider window

→

Human approves

→ Delivery: doc + 90-sec clip + assistant

cite-back to source on every generated line

12 / 14

Governance

Built to pass a security review, not to need an exception

Governed model

Runs inside Autodesk's approved stack — zero retention, no training on our data, no consumer accounts.

Inherited permissions

Derived artefacts inherit source permissions — if you can't see the team-site, you can't see its status.

Human in the loop

A human approves every leadership-facing output. Every line cites its source. The model is never the final author.

Manual
Heavy editing

Assisted
Spot-check

Exception-only
Review flags

The trust dial turns as accuracy is proven — starts at Manual and moves right.

13 / 14

The gap

There's no PM seat — this is how we cover it

The intake form, the scaffold, the doc-scrape status and the templated handover are the PM function, systematised.
I'm not asking for headcount on day one — I'm building the system so we don't need a full-time PM for routine coordination.
And so that a future Program Manager inherits a running machine instead of chaos.

Without the system

← Work lands on Emi
← Ad hoc status requests
← Handovers negotiated under pressure
← Bottlenecks invisible until too late

→

With the system

Emi orchestrates
Status pulled from the record
Handover bar agreed at start
Heat-map surfaces bottlenecks

14 / 14

The proof

You're not looking at a microsite — you're looking at Phase 6 early

Nobody reads the three-page doc; they skim half and ask again.
So the delivery is a short clip plus an assistant you can just ask. The site you've seen is that, working.
The portfolio learnings library and this assistant are the same thing seen twice: a record you can question.

Ask about the operating system

How do I keep visibility without holding a status meeting?

Ask

The medium proves the message

What I want from the team

Where does this model break against how you actually work?
What's the one standard worth making non-negotiable — and what should I drop?
Who owns the PM gap until we solve it? And what's the current state I should confirm before I harden anything?