First 90 days, written before day one.
The seats I want most are the ones where the platform's current scope is limited and the mandate is to expand it. That's a different prompt than "join an existing system and keep it running" — it asks for judgement about where to spend the first twelve weeks when most things you'd like to fix can wait. Here's how I'd spend them.
This is a plan written with no internal context. The real one will be different in the specifics — but the working method, the platform shape, and the order of operations are what I'd bring on day one.
Listen, map the actual seams
- What
Shadow two quants and one technical trader, full days. No code.
WhyThe JD says the framework has limited scope; the cheapest way to learn where is to watch where the workarounds live, not to read what the previous engineer wrote.
SIGNAL →A written list of the top ten friction points, ranked by daily incidence × time lost — shared back to the people I shadowed for ground-truth before any of it becomes a roadmap.
- What
Read the registry, the build system, and the deploy pipeline end-to-end. Map every place a model can be defined or modified.
WhyA framework with limited scope tends to have several "secondary frameworks" sitting next to it. Knowing where they are is half the job.
SIGNAL →A diagram of the current platform with the boundaries drawn at the seams I'd actually defend, not the ones the org chart implies.
- What
Set up an alpha-bench-equivalent of "rb run" against the existing framework — a single command path I can pull into a notebook and demo.
WhyEarning the right to opinionate requires being a confident user of the thing first.
SIGNAL →Run an end-to-end backtest of an existing model from a clean clone in <30 minutes, without asking anyone for help.
Ship one small but real thing
- What
Pick the highest-rank friction point from week-2 list. Build the minimal fix. Ship it behind a flag to a single owning team.
WhyTrust is bought with shipped fixes that move a number a teammate cares about. Trying to redesign the platform before that is how research engineers lose the room.
SIGNAL →One named user on one team saying, unprompted, that the old way is now annoying. That's adoption; it precedes scope.
- What
Add a leakage-check at the framework boundary if it isn't already enforced — refuse to register any model whose embargo gap is shorter than max(feature lookback, target horizon).
WhyMost teams have a leakage-checking convention. Conventions wear off; boundary checks do not.
SIGNAL →A measurable count of "would have registered, refused" events in the first week, and an after-action with whoever wrote those models.
- What
Stand up a baseline observability board for one active model — the freshness/calibration/PnL pattern, owned by the registering team.
WhyEasier to argue for the pattern with one running example than with a slide.
SIGNAL →A trader on the floor knows which board to glance at when they're curious about a specific model.
Earn scope, write the contract
- What
Propose the deploy contract: what every promoted model must declare (feature graph hash, training window, embargo, owner, eval report). Run an RFC with the heaviest users.
WhyThe JD wants the framework to become "the global standard way of training, consuming, combining, and transforming any data source." That doesn't happen by writing more code; it happens by writing the contract and then defending it.
SIGNAL →One RFC merged with named approvers from at least two teams, and one model promoted through the contract end-to-end.
- What
Start the notebook-as-code pairing program with the two most prolific notebook-driven quants. Two weeks, side-by-side, twice a week.
WhyYou can't ship a quant-facing UX from a desk. You ship it next to the quants who would otherwise refuse it.
SIGNAL →Two named quants using the framework's promote path for at least one model each, without prompting.
- What
Document the platform in three pages — one diagram (the system map), one contract (the deploy spec), one pager (how to use it as a quant). Pin them where they can't be lost.
WhyThe platform's scope is whatever its documentation defends. Three pages, written once and maintained, beats fifty undermaintained ones.
SIGNAL →A new quant onboarding refers to the pager in their first week and lands their first registered model in their second.
Rewriting any existing component. A new engineer rewriting in their first quarter is mostly paying off their own taste; it rarely pays off the firm's. The plan is to ship one small thing, win the room, and earn the scope to make bigger calls in quarter two — with the context that only quarter one can buy.