Build the engine before you hire the drivers

In 2013 I rolled out a CRM for a company that did not have a sales team to use it yet.

Everyone thought I had the order backwards. Build the system, then hire the people? You hire the people first, the logic goes, and then they tell you what system they need.

That is the consensus. It is also wrong.

We built the machine first - the data model, the order flow, an Android promoter app nobody asked for. Then we hired into it. Backorder efficiency doubled. Lost sales dropped 35%. Turnover grew 40% in the first year.

The reps who joined did not inherit a mess to untangle. They inherited a machine that already worked. Their onboarding was learning the system, not inventing it under pressure while quota ran.

I have done RevOps the same way for eleven years now, across three countries and three industries. The sequence does not change:

• Build the machine first. Routing, data model, instrumentation.
• Make it report on itself before anyone touches it.
• Hire into a system that already works.
• Hand the rote, stable paths to agents instead of headcount.

Most RevOps is staffed before it is built. Teams hire reps, bolt process and tooling onto the chaos afterward, and call it scaling. They spend the first year reverse-engineering their own mess.

I call it engine-first RevOps. The order is not a preference. It is the whole game. A machine built before the team is one the team trusts on day one - and one you can increasingly hand to an agent instead of a req.

Strongly believed, loosely held. Now and then the right first hire beats the right first system. But almost never.

Building the Vandfort routing agent before we built the website was the same move, eleven years later. The machine earns the right to the team.