When a hire pays off

A seller costs money for months before they make any. Nobody at the company could say how many months, or tell you at month three whether a given hire was going to get there. We hired fifteen to twenty of them a year.

The pieces of the answer existed. The revenue system knew what every seller booked, the CRM knew what they did to book it, and HR knew when they started. No two of those systems shared an identifier, so every question that sat across them stayed unanswered.

That shaped what leadership talked about. Revenue was reported monthly because revenue was reportable, and activity was not, so the executive review ran on lagging indicators alone: what had already happened, discussed once it had finished happening.

Reproducing even the basics by hand ran four to five hours a week, and some of it could not be reproduced at all. I asked IT to join the three systems and the answer was no, because a multi-year ERP programme already owned their development backlog. So I built it myself, in spreadsheets.

None of the three systems carried a shared key, so the first thing I built was one: a synthetic seller ID, and a mapping from every record in every source onto it.

That sounds procedural until you look at what the CRM held. One person could appear three times, and a join on name would have counted them as three sellers and split their revenue across all three. Identities had to resolve to human beings before anything above them could be trusted.

What sat on top was deliberately ordinary. Raw exports landed untouched in their own sheets, a joined fact table sat above them at one row per seller per month, and pre-aggregated rollups fed the reporting layer so it never had to touch the raw rows.

The first version joined the three sources inside the BI tool and would not hold under testing. The join belonged a layer down, at the spreadsheet, and rebuilding it there cost weeks and fixed it.

The first thing it produced was a relationship nobody had been able to state. Revenue and pre-sales activity had lived in separate systems, so no one had ever shown that a change in call volume translated into a change in closed campaigns and booked revenue. Once the two sat on one timeline the link was visible, and activity stopped being the thing managers nagged about and became the thing that predicted the number.

Then the benchmarks. Restricted to sellers hired after the revenue panel opens in 2020, where the full history is observable, a new seller reached $50,000 in cumulative net revenue in a median of seven months, $100,000 in ten, and consistent profitability at around eight. Anyone hired before that window shows the distance from their hire date to the start of the data rather than a ramp, so a company-wide average including them would mean nothing.

I designed twelve metrics and wrote down why each one existed. Eleven got built; our CRM could not produce the twelfth.

Some of these had been possible before, through manual work across systems that nobody had time to do weekly. Others had never been possible at all, which is why nobody was asking for them.

Four things, and none of them were mine to decide.

Hiring. I presented the ramp analysis split by experience class. The rookies matched or beat the experienced hires to the early and middle benchmarks and fell slightly behind on the two longest, on cells of one to nine sellers, which I said plainly when I presented it. It was enough to make the case that the premium we paid for prior sales experience was not buying faster time to revenue. The profile changed: we began screening for communication skills and appetite for a high volume of sales activity ahead of years on a sales floor.

The executive review. Leadership moved from reviewing lagging indicators alone to reviewing leading and lagging together.

Management practice. Local managers shifted from hammering on revenue to working the leading indicators with their teams, and new training was ordered and delivered to support the change.

The systems the company bought. The dashboard and its metrics were used as a filter during the ERP and CRM migrations that followed, and both projects were amended so the systems they delivered could carry the measurement the spreadsheet had been carrying.

That last one still surprises me. The function that declined to build this wrote it into the specification for the systems that replaced it.

Three things, and they are all the same thing: I built for the data I could get instead of arguing for the data that existed.

I had transaction-level records going back to 2013 and I used monthly aggregates, because Google Sheets caps at ten million cells and the transaction detail did not fit. Selling patterns, industry-level trends, product-level trends: all of it was sitting in the export and none of it reached the model. Learning a real warehouse would have cost me a week I did not think I could spare, and it would have repaid that week almost immediately.

The refresh stayed manual for the life of it. Every month I re-pulled and reorganised the exports by hand, an hour or two each time, which put a company-wide reporting layer on one person's calendar. That is a single point of failure, and it existed because the automated export was the thing IT had already declined.

So I would make the warehouse, the volume headroom and the automated pipeline part of the original ask rather than accepting the fallback and building around it. I got a working answer out of the fallback. I left a much larger one in the export.