Take the
Baseline First

Someone tells you they cut a process in half. Ask them "compared to what?" and watch the room go quiet. They know it's faster. They can feel it. But nobody wrote down how long it used to take, so "half" is a guess wearing a number's clothes.

This is the most common miss in process improvement, and it happens before any of the actual work: nobody captures the starting point. You dive in, you fix the thing, and it genuinely gets better. Then afterward, when you want to say by how much, you're stuck estimating backward from memory, because the "before" is gone. The improvement was real. The proof never existed.

That gap costs you more than it looks like. Without a baseline you can't prove the change worked, so you can't defend the number when a skeptical CFO or a hiring manager pushes on it. You can't tell a real win from a hunch that felt good. And you can't decide what to fix next, because you don't know which of your changes actually moved anything.

The fix is unglamorous, which is exactly why people skip it. Before you touch the process, measure it. Time three or four real cycles with a stopwatch. Count how many of last month's entries had to be corrected. Write down how many steps and how many people a request passes through. It takes an afternoon, it feels like a detour when you're itching to start fixing, and it is the entire difference between "I think this helped" and "here is what it did."

There's an honesty ladder here, and it's worth being clear about where you're standing on it. The best position is a measured before and a measured after: you put both numbers on the table and let them speak. The next best is an honest estimate, clearly labeled as one, grounded in real knowledge of the work. The worst position, and the one that actually hurts you, is an impressive-sounding number you can't back up, because the moment someone asks how you got it, the whole claim collapses and takes your credibility with it. A precise result you can defend beats a big result you can't, every time.

I've learned this one the hard way. I've shipped work I knew made a process dramatically faster, watched a team go from hours to minutes on something, and then had someone ask, reasonably, "by how much?" And the honest answer was "a lot, but I didn't time the before, so I can only estimate." That's a weaker place to stand than I needed to be in, and it was completely avoidable. An hour of measurement up front would have turned a good story into a provable one. Now I take the baseline before I change anything, even when I'm sure the change will work. Especially then.

Because here's the asymmetry. Measuring the before costs you an hour you'll never miss. Not measuring it costs you the ability to ever prove the after, and that one you don't get back. Once the old process is gone, the baseline is gone with it.

So before you redesign the workflow, before you automate anything, before you get to the satisfying part: write down where you're starting. Take the baseline first. The result will still be there when you're done, and this time you'll be able to prove it.

← Back to all posts