Before I look at a single number, I walk the floor. That's the habit I picked up as an industrial engineer. And I've never lost it. I followed the material from the first station, where raw input arrives, to the last, where a finished output rolls off the line. Everything in between is a process: the machines, the operators, the sequence someone deliberately designed, etc.

In a perfect world, that's the whole story. You set the same input, the same process, and you get the same output, every time. Unfortunately, it rarely is that way. A machine drifts out of calibration. A supplier's batch varies. Sometimes it doesn’t even make any sense, like the same operator operating the same machine and performing double digits poorly on the night shift compared to the day shift.

That’s the noise. It’s a group of variables nobody built for, nobody accounts for, and, many times, nobody even acknowledges they exist. You can’t control the noise. Thus, you can't fully control the output, no matter how good the process is. The only thing you can actually build is a process disciplined enough to keep that noise small, visible, and survivable.

The sales organization of a startup is not that different from a manufacturing floor as it might sound, at least not in systemic terms. Before taking credit for this analogy, it’s worth citing The Lean Startup concept, coined by Eric Ries. He borrowed ideas directly from the discipline of high-performance manufacturing systems from Toyota and applied them to how young companies validate ideas. In both cases, you have an input, a process, and an output, and in both cases the whole point of building the system is to control the output.

In manufacturing, that output might be the number of finished units shipped in a month. In sales, it's the number of deals closed, or the revenue behind them. To control the output, you need to control both the input and the process feeding into it, and there is always a random variable acting on both. Some prospect's fiscal year changes. A champion gets reorganized out of their role. A competitor's pricing lands lower for reasons that have nothing to do with your product. That's noise, and no amount of good management removes it. So instead of wasting energy trying to eliminate the randomness — you can’t! — you should figure out which variables affecting your inputs and your process you can actually control.

That’s the role of the telemetry. Before diving deeper, let’s first introduce ten reasons why it matters enough to build deliberately, rather than bolt on after the fact:

Telemetry separates the rep from the system. Without it, a bad quarter reads as a bad rep by default. With it, you can actually see whether the failure belongs to the person or to the process underneath them — and coach the right one.

Today, I want to walk through what telemetry actually is, and why it matters for a sales organization specifically, borrowing some frameworks that tech and sales leaders have already built out in adjacent disciplines.

Managing a sales organization well comes down to making better decisions, and better decisions rest on four steps, each one a prerequisite for the next.

Everything starts with information — and specifically, accurate information about the inputs that actually matter to your business. The tricky part is that you may or may not already have that data, and if you don't, someone has to go create it. This is where a lot of sales organizations get into trouble. Many sales leaders at large companies invest heavily in generating as much data as possible, because more data means more ways to compare reps and diagnose performance. In the best case, technology quietly logs calls, meetings, and account activity in the background. In the more common case, it means reps filling out forms, spreadsheets, and CRM fields by hand — which does produce more data points, but at a real cost: every minute a rep spends on data entry is a minute they're not spending on the job the data is supposed to help them do. It's a strange trap. Managers spend real energy chasing reps to fill in fields, time that could have gone into coaching or training instead — and then, worse, they draw firm conclusions from data that was incomplete or inaccurate to begin with. Good telemetry design starts by being honest about this tradeoff, not by assuming more fields always means more insight.

Once you have data, you convert it into something you can monitor — a metric. In a sales organization, metrics generally fall into two families: activity and performance. Activity metrics are the leading indicators — accounts contacted, calls made, messages sent — the things a rep does before an outcome exists. Performance metrics are the lagging indicators — the ones that tell you, after the fact, how the process actually performed. You need both, and each has an obvious failure mode. Activity metrics alone are shallow: a raw call count says nothing about whether those were the right accounts, or whether the conversation had any real quality to it. But without activity, your pipeline simply doesn't grow. Performance metrics, meanwhile, are the ones that should genuinely change your understanding of the process — a shift in a real performance metric should tell you something actionable about how the system is doing, not just how one person's month went.

Here's where most sales orgs quietly go wrong, and it's a lesson straight out of Statistics 101: correlation does not imply causation. Pulling data together and converting it into a metric is still just data — on its own, it doesn't tell you anything. To turn a pattern into an actual understanding of your business, you need a causal model: some theory of why the pattern exists, not just confirmation that it does.

The parable I keep coming back to here — even though, in the interest of honesty, most of the specific details of it are almost certainly an urban legend rather than a documented case — is the famous "diapers and beer" story often attributed to Walmart. The claim goes that a retailer's data mining turned up a strong correlation between diaper purchases and beer purchases on Friday evenings, and that the initial, naive read of the data was baffling: what would connect the two? The explanation that made the story famous was that young fathers, sent out to buy diapers on their way home from work, picked up a six-pack for themselves while they were at it. Diapers and beer aren't causally connected at all — the real causal link runs through a third variable, the young father, who independently decided to buy both. Judea Pearl, in The Book of Why, built an entire framework around exactly this kind of confounding — the idea that you can't read a causal arrow directly off a correlation until you've accounted for the hidden variable sitting behind both effects. Whether or not Walmart's version of the story really happened this way, the structure of the lesson is real, and it shows up constantly in sales data.

Here's a live version of the same trap. Conversation-intelligence platforms like Gong have published data showing that top-performing sales calls tend to land around a 43:57 talk-to-listen ratio — the rep talking 43% of the time, the prospect talking 57% — while calls that end up lost tend to drift toward the rep talking well over 60% of the time. It would be easy to draw the naive conclusion: reps who talk less close more. But that's confusing the symptom with the cause. A rep who mechanically forces herself to talk less, without changing anything else, won't suddenly close more deals. What actually drives the outcome is what's happening underneath the ratio — whether the buyer is genuinely opening up and sharing real information, and whether the rep is asking questions sharp enough to get there. Talk time is the correlation. The causal model is what the conversation is actually accomplishing. You can't tell the difference by measuring the clock alone.

With reliable data, metrics that actually measure it, and a causal model that translates the data into real understanding of your business, you're finally in a position to make better decisions. But even here, every manager runs into the same wall: the real world is a world of imperfect information. You will have all of the above and still be missing pieces of the puzzle. At that point, you're not looking for certainty — you're placing a bet with the information you have. Annie Duke's Thinking in Bets draws exactly this distinction, and it's worth holding onto: a guess and a bet are not the same thing. With a bet, you go in aware of your own limitations, you decide anyway, and you adjust based on what actually happens — rather than either freezing until you have perfect information, or convincing yourself after the fact that the outcome proves the decision was right (or wrong). That second trap — judging a decision purely by its outcome — is what Duke calls resulting, and it's the same failure mode that shows up when a manager reads a rep's bad quarter as proof of bad performance without ever checking whether the underlying process was sound.

This distinction matters more today than it used to, in an era of abundant data and AI systems that can process it faster than any human team. The risk isn't a shortage of correlations — it's mistaking any correlation you find for something meaningful. The talk-time example above is exactly this trap in miniature: a real, well-documented pattern that still requires a causal model before it becomes a decision you can actually act on.

The word telemetry comes up constantly in software operations, and it's worth borrowing properly rather than just gesturing at it. The core problem is simple: no single person operating a complex system can see the whole of it at once, or fully understand how every piece fits together. The only way around that limitation is to build enough visibility into the system — logs, metrics, traces — that the behavior of the whole becomes observable, even though no one person could hold it all in their head directly.

There's a finding from operations research that I think about often: the best-performing technical organizations aren't better because they have fewer incidents — they're better because they diagnose and fix incidents faster, using what's sometimes called a culture of causality. High performers use real telemetry to narrow down contributing factors before acting. Lower performers, lacking that visibility, default to blunt, low-information fixes — rebooting a server and hoping, rather than actually knowing what had gone wrong. The parallel to sales is almost too clean: a sales leader without real telemetry into their pipeline is the manager rebooting the server. Reassigning a territory, running a new spiff, replacing a rep — all of it can be a version of rebooting blind, if it isn't grounded in an actual diagnosis of where the process broke.

The underlying goal of good telemetry is worth stating plainly: it isn't just to know that something is wrong. It's to be able to quickly determine what's wrong and make an informed decision on how to fix it — ideally long before anyone downstream is affected. And there's a second, quieter benefit buried in that same idea: telemetry helps you build your best current understanding of reality, and just as importantly, it tells you when that understanding turns out to be wrong. Applied to a sales organization, that's the whole point of the 5Cs and the metrics underneath them — not a scoreboard for reporting upward, but a live check on whether the model of your own funnel still matches what's actually happening in it.

There's also a point about silos that translates directly into revenue teams. For decades, technical organizations ended up with information trapped in silos — development logging only what developers cared about, operations only monitoring whether systems were up or down — so that when something broke, no one could see across the boundary to understand why the whole system had failed. Sales organizations build the identical silo by default: marketing tracks its own funnel, sales tracks its own pipeline, customer success tracks its own renewals, and the handoffs between them are exactly where visibility disappears. Centralized telemetry, in a sales context, means instrumenting those handoffs deliberately — Capture and Contact sitting at the marketing-to-sales boundary, Convert sitting at the sales-to-customer-success boundary — rather than letting each team optimize its own local number and call it done.

One more idea from the DevOps world is worth carrying over directly: not every signal deserves the same level of alarm. Kim's book describes a hierarchy of logging severity — DEBUG, INFO, WARN, ERROR, FATAL — specifically so that teams don't drown every real signal in noise, or worse, treat every anomaly as a five-alarm fire. A sales organization benefits from the same discipline. A rep's Contact % dipping two points in a single week is closer to a DEBUG-level signal — worth noting, not worth a meeting. A Capture % that's dropped ten points across an entire segment for a month is closer to an ERROR — something that needs an actual root-cause conversation, this week, before it becomes next quarter's missed number.

None of this makes revenue fully controllable, and it was never going to. The output of any process — a factory line, a software system, a sales organization — carries real noise, and no amount of instrumentation makes that noise disappear. What telemetry buys you is something more modest and, I'd argue, more valuable: the ability to see your own system clearly enough to know where it's actually breaking, instead of guessing, resulting, or rebooting blind.

I've laid out the concepts here deliberately, before getting specific, because I think the ideas need to be understood on their own before they're useful anywhere in particular. In the next few pieces, I want to take this same telemetry lens and apply it to the individual areas inside a sales organization where it matters most — business development, closing, onboarding, and renewals — and show what good instrumentation actually looks like at each of those stages, not just in theory.