The friction is the relationship forming, and most teams read it at exactly the wrong time.
The owner's manual for a new engine tells you, in bold, not to redline it for the first few hundred miles. Most people read that as legal caution, the manufacturer covering itself. It isn't. It's one of the most precisely understood phenomena in mechanical engineering, and it has a name: run-in, or break-in. And what's happening during those first few hundred miles is the single most important, and most misread, part of the machine's entire life.
Put two metal surfaces together under load and slide them, and they do not start at their final friction. Microscopically, no surface is smooth; it's a landscape of peaks called asperities, and at first only the highest peaks touch. Those high spots carry enormous local pressure, so they plastically deform, flatten, and wear away while the surfaces conform to each other's true shape. On a tribometer, the lab rig that measures this, you watch the friction coefficient, μ, fall sharply over the first 10² to 10⁴ meters of sliding and then level into a plateau. That plateau is the number engineers quote as "the" friction of the pairing. Everything before it is a transient, a separate measurement, explicitly not the steady-state value. As the tribology literature puts it flatly: steady-state μ is defined only after the plateau.
Here's the part that turns the whole thing inside out. The low-friction steady state isn't something the run-in gets out of the way of. The run-in produces it.
During break-in, the rubbing itself manufactures a protective layer. In a lubricated engine, the anti-wear additive ZDDP reacts under exactly the heat, pressure, and shear of asperity contact to grow a glassy phosphate film, a tribofilm, directly on the rubbing steel. In some engines a friction-reducing coating forms in situ on the cylinder bores during break-in, documented well enough to hold patents. The mechanism is the point: the film forms because the surfaces rub. Suppress the rubbing, baby the machine, never load it, and the film never forms, so you never reach the low-friction regime you were trying to protect. The high-friction transient is the price of admission to low-friction operation. There is no other door.
Two more facts from the run-in curve matter before we leave the lab. First, most of the wear happens during run-in and then drops to a low steady rate, a result modeled since at least a 1977 study of surface-roughness transients in bearings. The period everyone wants to skip is precisely where the relationship between the surfaces is being physically shaped. Second, run-in numbers are noisy: tribology is notorious for run-to-run scatter, with μ varying ±10% routinely and ±30% in marginal lubrication. The earliest measurements are the highest-variance, least-trustworthy points on the entire curve.
Now hold that whole picture (the falling transient, the film built by friction, the noisy early signal, the plateau that alone counts as steady-state) and look at what happens when an engineer joins a team.
A new hire is not one surface meeting another. They're one surface meeting two: the codebase and the team. Three contact partners, all conforming to each other at once. The asperities are the high-pressure points of first contact: clashing conventions, mismatched tacit knowledge, an unfamiliar build system, the function that everyone "just knows" not to call on Fridays. And the tribofilm, the thing that makes low-friction work possible later, is the shared mental model: calibrated trust, a recovered map of why the system is shaped the way it is, the accumulated knowledge of the installed base. It builds during the friction, over a window that looks startlingly like the physical one.
The data lines up almost embarrassingly well. Studies of engineering orgs report that, without structured onboarding, developers take three to six months to reach full productivity; with good onboarding, eight to twelve weeks. One survey across 80 engineering organizations put average full ramp at three to nine months. (Treat these as directional industry figures rather than universal constants; the shape is consistent everywhere it's measured.) The productivity curve is a J-curve: low and slow, then accelerating, the social image of the μ-transient. The conformance milestones are even legible as discrete events. First commit lands in one to three days for the strongest onboarding setups and two to three weeks at the industry median; a first independent pull request within a couple of weeks; a shipped feature by the end of month one; genuine independence by month three. Those are asperities deforming, one contact at a time.
It is, to be clear, a structural map and not an identity, and the one place it breaks is the most useful part, so I'll come back to it. But once you see onboarding as a run-in transient, the two classic ways teams wreck it become the same two ways an engineer wrecks a bearing.
Six weeks in, the new hire is slow. They ask questions with obvious answers. They clearly don't grasp the architecture yet. Someone influential says the dangerous sentence, "I'm not sure they're a fit", and the team starts, quietly, building the case.
In tribology, that's declaring a bearing failed on its first revolution. You are reading a transient as if it were the steady state, at the one moment the curve is guaranteed to look bad, because high friction during conformance is the mechanism itself, not a defect. And you're doing it at the noisiest point on the entire trace, where the scatter runs ±30%. If a tribologist tried to publish a friction coefficient measured in the first hundred meters of sliding, a reviewer would reject it on sight: that's not steady-state μ, that's warm-up. Yet teams make hire/no-hire judgments on exactly that data, all the time, and feel rigorous doing it.
The deeper error is an attribution mistake. The friction at week six is real and informative, but it is not telling you whether this person will carry load. It's telling you about the surface chemistry of both partners: the hire's specific gaps and your system's specific roughness. A hire generating a lot of run-in friction is partly measuring how rough your conventions, the documentation, and the undocumented tribal knowledge actually are. If every new hire grinds for the same six weeks on the same three things, that is not five separate fit problems. That is one reading of your surfaces.
The opposite error is rarer in the discourse and at least as destructive. It's the senior engineer who skips conformance on principle. "I'm too experienced to sit and read the existing code. I don't need to learn your conventions; I have my own. Run-in is for juniors."
A bearing run without break-in doesn't get a head start. It runs in permanent boundary lubrication, the regime where the protective film never formed, asperities grind directly against asperities, wear is high, and it stays high forever. (That's as far as I'll take the regime map; it's a whole subject of its own, here it's just the name for "no film ever formed.") The senior who skips run-in produces exactly that signature: high wear and debris everywhere. The debris is broken conventions, surprised teammates, a confidently-written module that re-solves a solved problem in a style nobody else can maintain. They never build the shared-model tribofilm, so the friction never drops, and, crucially, they almost always misattribute it. "This codebase is a mess. This team is dysfunctional." No. You never ran in. The roughness you're feeling is the roughness of two surfaces that never conformed, and you decided in advance that conforming was beneath you.
Conformance is beneath no one. The film is what makes the low-friction work possible, and there's no seniority exemption from the physics.
Then there's the pattern that haunts engineering managers: the hire who was great for three or four months and then, somewhere around month five or six, crashed. Output fell. Engagement dropped. They started looking elsewhere. The team's story writes itself: we misjudged them; the early promise was a honeymoon. The HR data even seems to name it: a third of new hires leave within six months when onboarding is poor; surveys find new engineers take six to seven months just to feel settled.
But look at when the crash lands, because the timing indicts the system, not the person. The honeymoon ends, by most accounts somewhere between a few weeks and a couple of months, when two things happen at once: real workload arrives, and structured support is withdrawn. Training wheels come off exactly as the hill gets steep. In run-in terms, the contact had conformed enough to coast at low friction while the load was light and the lubrication was generous. Then the operating point moved: load up, support down, together. The contact dropped out of the comfortable mixed regime into boundary, and friction spiked. The hire didn't degrade. The duty cycle changed, and nobody engineered the transition.
This is the oldest piece of wisdom in bearing engineering, and it's the line to keep: a bearing never fails, a system fails a bearing. A bearing run in the regime it was designed for routinely exceeds its rated life many times over; run outside that regime, it fails at a fraction of it. The component didn't choose its operating conditions. The system either provided the run-in conditions and a sane load ramp, or it didn't. "They crashed at month five" is, far more often than teams admit, a confession about the duty cycle wearing a verdict's clothing.
The constructive move isn't another 30-60-90 template. It's reading friction correctly and then engineering the conditions. Three things follow directly from the physics.
Don't measure fit during the transient. Define steady-state only after the plateau. That means deciding, in advance, when the run-in window closes for a given role and level, and treating everything before it as warm-up data, diagnostic but not a verdict. If you wouldn't quote a friction coefficient from the first hundred meters, don't make a retention decision from the first six weeks. Watch the early signal; just don't mistake its variance for a person's ceiling.
Don't skip run-in, and don't let your seniors skip it. Reading the existing code, learning the conventions, asking the obvious questions, that is the film forming. A culture that treats conformance as a junior activity is manufacturing boundary-lubrication seniors and then blaming the codebase they never bonded with.
Engineer the duty cycle, especially the cliff. Ramp load as the film builds, the way a break-in procedure ramps an engine instead of redlining it or garaging it. And do not withdraw support at the exact moment load rises; that post-training cliff is self-inflicted, and it's the direct cause of the month-five crash. Overlap the two transitions instead of stacking them.
Here's where the analogy breaks, and it breaks in your favor. Metal surfaces conform by blind mechanical wear; there's nothing you can do to hurry it. People conform through intent, feedback, and learning, which means the human run-in is designable in a way a bearing's never is. That's precisely why structured onboarding can compress a three-to-six-month ramp into eight-to-twelve weeks: good docs, deliberate pairing, and a sane load ramp don't cheat the transient, they shape it. The bearing has to take whatever break-in it gets. You get to choose yours.
So the next time a new hire is generating friction, resist the two reflexes: the verdict ("not a fit") and the over-protection ("shield them from real code so the numbers look smooth"). Both are misreadings of the same curve. The friction is not noise to suppress and it's not a fit signal to act on. It's the relationship physically forming, building the film that low-friction work will later run on, and it's telling you, honestly, about the surface chemistry of both partners. Read it for what it is, give it the window it needs, and engineer the load. Break in the new engine on purpose: not redlined, not garaged.
A rating taken during the transient is warm-up data, not a verdict.
The same trap catches AI agents: a new agent, tool, or model judged on its first noisy interactions gets a reputation it never earned the chance to disprove. Agent Rating Protocol accumulates an agent's reputation over its whole operating history with the variance attached, so a rating reflects steady-state behavior past the plateau rather than the highest-scatter points on the curve. Rate the bearing on its rated life, not its first revolution.
pip install agent-rating-protocol · npm install agent-rating-protocol
vibeagentmaking.com