Why Does a New MBSE Hire Take Six Months to Become Productive?

Because a new MBSE hire is climbing three separate ramps at once: the tool, your model’s conventions, and your domain. A résumé can only prove the first one, and it’s the shortest of the three. The good news: none of this is the hire’s fault, and with structured onboarding you can compress the six-month ramp into six to eight weeks.

We’ve watched this play out on enough programs to say it plainly: the “slow” new modeler is almost never slow. They’re being asked to learn three things simultaneously while everyone assumes they only need to learn zero of them, because “they had five years of Cameo on their last program.”

What six months actually costs you

Put numbers on it before we diagnose it. A senior systems engineer with MBSE skills runs somewhere around $180K–$220K fully loaded. If they operate at roughly a third of full output for their first six months — which is typical when onboarding is “here’s your license, the model’s on Teamwork Cloud, ask Dave if you get stuck” — you’re paying for about $60K–$70K of ramp.

Add the drag on Dave. Every interruption-driven question costs your best modeler twenty minutes of recovered focus. Fifteen questions a week is a day of Dave’s output, every week, for months. The real cost of unstructured onboarding is closer to a full engineer-quarter across the two of them.

Ramp one: tool fluency (the one you interviewed for)

Cameo fluency is real and it matters — knowing how to structure packages, use the containment tree efficiently, wire an internal block diagram without fighting the tool. But it’s the most transferable of the three ramps, and the fastest to close for anyone with adjacent experience. A capable engineer coming from another modeling tool can get functional in Cameo in two or three weeks with decent instruction.

The trap is that tool fluency is the only ramp a hiring process measures, so managers assume it’s the whole ramp. It’s maybe 20% of it.

Ramp two: your model’s conventions (the one nobody plans for)

Every organization’s model is a dialect. Where do interface definitions live? Do you allocate behavior to parts or to blocks? What’s the naming pattern for ports? Which stereotypes are load-bearing and which are decoration from a previous methodology initiative? Is that package of unnamed diagrams from 2024 authoritative or abandoned?

None of this is written down on most programs. It lives in the heads of the two or three people who built the model, and a new hire discovers it by making “mistakes” that were never defined as mistakes anywhere. Each correction costs a review cycle. This ramp — not tool skill — is where months two through five usually go.

Take our drone demo model as a small example: a new modeler could reasonably attach the radio link’s data interface at the flight controller block, at a port on it, or via a proxy port on the enclosing air vehicle. All three are legal SysML. Only one matches how the rest of the model does it — and if that choice isn’t documented, they’ll learn it in review, three weeks after they made it, after copying the pattern eleven more times.

Ramp three: your domain

A modeler who doesn’t yet understand your system can transcribe what engineers tell them, but they can’t ask the question that catches the gap. Domain ramp is the slowest of the three and the least compressible — which is exactly why it should dominate your hire-or-train decision. If your existing engineers already have ramp three, teaching them ramps one and two is usually faster than teaching a tool expert your domain. We walk through that math in Should I Hire an MBSE Expert or Train My Existing Engineers?.

Structured onboarding: months into weeks

Four artifacts and habits, none of them expensive:

• A conventions document. Ten pages, not a hundred: naming patterns, package structure, which diagram types you use for what, the five stereotypes that matter, three worked examples of “we do it this way, not that way.” Writing it takes your lead a couple of days and pays back on every hire, every review, forever.
• A guided model tour. Two hours, lead modeler and new hire, screen-shared, walking the actual model: here’s the spine of the containment tree, here’s where requirements live and how they trace, here’s the authoritative area, here’s the legacy area you should ignore. This replaces roughly a month of archaeological guessing.
• Starter tasks with real deliverables. Not “read the model for two weeks.” Pick small, bounded, genuinely useful tasks: clean up traceability in one subsystem, model one new interface end-to-end, build one readable diagram for an upcoming review. Real work, small blast radius, fast feedback.
• A standing mentor hour. One scheduled hour per week with your best modeler beats fifteen ad-hoc interruptions. Questions batch up, answers get witnessed by the conventions doc (add every answer to it), and Dave keeps his focus the other four days.

Teams that do these four things get a new modeler to independent, review-passing work in six to eight weeks. That’s not a sales number; it’s just what happens when someone climbs one ramp at a time instead of three at once.

The uncomfortable corollary

If the conventions ramp is the long pole, then the cheapest “hire” is often already on your payroll. An engineer who knows your domain and half your conventions only has one ramp left — the tool — and that one is trainable in weeks. Before you open a req that will sit unfilled for a quarter, price out training two or three of your own people. It’s frequently faster, cheaper, and lower-risk, and you end up with redundancy instead of a new single point of failure.

Where to go from here

If you’re onboarding someone now — or deciding between hiring and training — CameoMagic runs training and advisory engagements built around exactly these ramps, including helping you write the conventions doc your model doesn’t have yet. The easiest first step is a free 30-minute model review: bring your model, and we’ll tell you honestly where a new hire would get stuck. Book it at cameomagic.com.