How long before you run a deployment yourself

"First deployment" means three different things, and conflating them is why estimates feel wrong. Nobody enters alone; everybody enters the room early.

Entering the room — sitting in customer meetings and on site, taking notes, asking questions. This should happen in the first two weeks. A team that keeps new FDEs at their desks for a month is not protecting the customer, it is hiding an onboarding gap.

Owning a module — responsible for one slice of a live deployment, with a name attached. Typically months two to four for someone with engineering background, longer for a career changer building the technical half at the same time.

Running a deployment end to end — scoping, sponsor, readout, handover. Usually after two or three deployments with a senior person present, so somewhere in the second half of year one. This is the honest timeline and it rarely compresses much, because it depends on having seen enough ways projects die.

What decides the pace

Whether the team has a method. A team that runs the same artefacts every time — discovery bank, metric table, readout — can put a new person inside the method in weeks. A team that improvises each deployment is transmitting folklore, which takes years.

Whether you are allowed to be wrong cheaply. The first readout a new FDE gives should be one where a senior colleague has already seen the numbers. If the first one is a high-stakes meeting, onboarding took the form of exposure.

Whether the customer-facing half is taught at all. Most teams teach the stack and assume the rest. The half that takes longest to learn is the half nobody writes down: how to decline a scope without insulting anyone, when to escalate, what to say when the data does not exist.

The domain. A deployment in a domain you already know is dramatically faster. This is why the most common good path into the role is domain first, technology second.

What a good first ninety days looks like

Weeks 1–2: in the room, on site at least once, reading the last three deployments' readouts and runbooks. Only reading that has decisions in it.

Weeks 3–6: co-delivering a slice of a live deployment with a named senior partner, responsible for a specific artefact rather than a general contribution. The artefact should be one that gets criticised in public — a metric table or a readout — because that is where the learning is.

Weeks 7–12: owning a small slice end to end, including one customer conversation without backup. The conversation is the milestone, not the code.

Signs the ramp is stuck

Three, all visible by week eight. You have not been on site. You have not presented anything to anyone who could disagree. Your work has never been reviewed against a number.

Any of those means the deployment experience is not accumulating, and more months in the same position will not fix it. The remedy is unusually direct: ask for a named artefact and a named customer conversation, in writing, this quarter.

The shortcut that actually works

Learn the metric table before you learn the stack. It is the one artefact that appears in every deployment, gets argued about every time, and cannot be faked. An engineer who can produce a defensible metric table in week one is treated as a colleague; one who can produce an impressive prototype but no measurable claim is treated as a resource.

The timeline above is a norm, not a rule, and it varies with company size and with how much of the method is written down. What does not vary: the role is learned in rooms with customers, and any ramp that avoids those rooms is not a ramp. How the capability it builds is described in hiring is in the capability model.