My Daughter's Stair-Climbing Velocity Is Down 40%
On curiosity, innovation, KPIs, and why some of the most consequential, forward-looking work a team does may be the hardest to measure.
My daughter learned to climb the stairs at eight months old, hands flat on the step above, one knee up, then the other, driven by a fiery purpose that only she knows (we can’t figure out what’s so compelling about the upstairs). She refined this method over the course of a few weeks into something genuinely efficient.
By 11 months, she was fairly stomping up the stairs on her hands and knees, so fast my partner and I had to scramble to keep up. She had, in the way that babies do, solved the problem, and the solved problem was carrying her reliably from the bottom of the staircase to the top.
And then she stopped doing it.
One recent afternoon, she approached the bottom step and, instead of kneeling, she grabbed the banister with both hands and tried to step up with one foot. She couldn't do it. She got about halfway, wobbled, sat down, and tried again.
This went on for a while. It was slower and worse in every dimension. She had a method that worked, a proven approach she'd been executing successfully for weeks, and she abandoned it - voluntarily, without incentive, without instruction - to pursue something she couldn't yet do.
I've been thinking about this for a while now, because I think it might actually be important.
The question is simple: why would anyone abandon a working method to try a worse one?
She's fourteen months old. She doesn't have a product roadmap or a hypothesis about bipedal locomotion. She saw other people climbing stairs differently, or she felt something that suggested a different approach was possible, and that was enough. The possibility itself was the motivation. Not the efficiency gain, not some projected return on investment - just the open question of whether there was another way.
Alexander Fleming was studying staphylococci in 1928 when he left a petri dish uncovered, went on vacation, and came back to find that mold had contaminated his sample. The mold was killing the bacteria.
This is the part of the story everyone knows, and the part most people gloss over, because, really, the discovery of penicillin wasn't about the mold - it was about the fact that Fleming noticed the mold, and instead of throwing the dish away (which would have been tidy, efficient, and probably appreciated by his colleagues), he got curious about what it was doing and why.
He wasn't looking for an antibiotic. Nobody was looking for an antibiotic, because the concept barely existed. He was looking at staphylococci, and he saw something unexpected and followed it.
The discovery that would go on to save more human lives than perhaps any other medical intervention in history was, at the moment it occurred, a contaminated sample in a messy lab belonging to a researcher who should have cleaned up before he left town.
Tim Berners-Lee, a physicist at CERN, was trying to solve what seemed like a clerical problem: researchers at the lab couldn't easily share documents across different computer systems. He had an interest in hypertext, which at that point was an academic curiosity without much practical application, and he wrote a proposal for a system that would let people link documents together. His supervisor read it and wrote "vague, but exciting" on the cover page, which is both a supremely British response to a proposal and, in retrospect, one of the great understatements of the twentieth century.
CERN almost didn't fund it.
The infrastructure of modern civilization - every website, every online transaction, the entire information architecture of the contemporary world - began as a side project that a physicist pursued because he was interested in how information could be organized, and the institution that housed him nearly passed on it.
Claude Shannon, at twenty-one, wrote a master's thesis at MIT that connected Boolean algebra to electrical switching circuits. He'd been playing with symbolic logic and he noticed that the true/false structure of Boolean algebra mapped perfectly onto the on/off states of electrical switches, and he wanted to see where that mapping led.
Bell Labs, to their enormous credit, gave him room to explore – which is another way of saying they paid a junior fresh out of grad school to follow a mathematical hunch without any clear commercial application.
The entire digital age - every computer, every phone, every line of code that has ever been compiled - descends from that exploration. Shannon couldn't have told you where it was going, because there was no "where" yet; there was only the question, and the freedom to follow it.
The thing that connects these stories isn't genius, though all three of these people were brilliant. It's that none of them could see the destination from where they were standing.
The path, in every case, looked like waste - a contaminated dish, a vague proposal, a side-project in mathematics.
The only thing that carried them forward was the conviction that the question itself was worth their time… which is not a conviction that lately survives contact with a spreadsheet.
I lead a small, experienced development team at Driver Digital, a boutique, design-led Shopify Plus partner agency. We build thoughtful custom storefronts and private apps for fashion and luxury brands, which means our work lives inside a very specific set of constraints: brand directives, platform limitations, client timelines, billable hours, and the relentless arithmetic of agency economics.
Every hour has a dollar value. Every project has a scope. The incentive structure is clear and unambiguous: ship the thing, bill the hours, examine the retrospective, on to the next one, continually optimizing the process and deliverables as you go.
And inside that structure, we give our developers time to explore.
This is a deliberate choice, and I want to be honest about what it actually looks like - because from the outside it can look a lot like waste.
A developer spends an afternoon trying to solve a problem three different ways when the first way already worked. Someone goes deep on a new pattern they read about that may never make it into a client project. A new tool gets investigated, tested, partially adopted, and then set aside because the timing isn't right.
None of this shows up on a client invoice. From the perspective of utilization metrics - the way most agencies (including ours) measure the productive value of their team - it's unproductive time.
But what I've seen, over and over, and what I think most people who manage technical teams either already know or suspect: the developers who explore are the ones who solve the hard problems.
The ones who have gone down dead ends are the ones who recognize them faster the next time around. That afternoon six months ago that produced nothing billable is the reason the impossible client request this week got a creative solution in two hours instead of two days, because someone on the team had already been in that territory.
You can't draw a straight line from the exploration to the outcome, and that's the point. If you could see the line, it wouldn't be exploration; it would be execution.
Execution is important; it's how the work gets done, how the bills get paid, how the client gets their storefront launched on time. But execution depends on a reservoir of knowledge and experience-based intuition that is only constructed through the kind of undirected, curiosity-driven investigation that no one puts on the Gantt chart.
The hours spent are measurable, but you can't easily measure the compounding effect of a team that's been given permission to be curious. The artifacts appear in the quality of the solutions and in the speed and comprehensiveness with which genuinely difficult problems get resolved.
I don't think we talk about this enough in the agency world – partly because the economics of agency work make it uncomfortable to talk about, and partly because the vocabulary we've developed for measuring value - utilization rates, velocity, sprints - doesn't have a category for "learned something new today that might matter later, maybe?"
We have become extraordinarily good at measuring outcomes. OKRs, KPIs, velocity, utilization, ROI. The management philosophies of the last several decades have converged on a single, powerful idea: “if it’s important, measure it.” And this idea has done a lot of good, genuinely. It's forced organizations to be honest about what they're producing and at what cost, and it's killed a lot of projects that deserved to die.
But it has also produced a kind of tunnel vision, a slow narrowing of what we consider valuable.
And it’s stunning just how un-true the garbled contrapositive << if you can’t measure it, it’s not important >> actually is.
When every hour has to justify itself in advance, when every exploration needs a hypothesis and a projected return, we only pursue paths with visible destinations. We only optimize what already exists.
We get very good at going where we already know we're going, and we stop noticing the things that happen at the edges of our attention - the contaminated dish, the vague proposal, the mathematical coincidence - because those things don't have a line item, and they can't be planned for, and they look initially, from every measurable angle, like wasted time.
The danger isn't that measurement is bad.
The danger is that overfocusing on measurement bleeds your attention from things that can’t be easily measured, but which may be equally, or more, important.
This is especially true if you’re trying to produce conditions that create outlier levels of success (something creative, differentiating, or exceptional).
Measurement, taken as a first principle and prioritized above all else, can quietly eliminate the conditions under which innovation tends to occur.
We can't schedule flashes of insight, nor can we put "stumble onto something transformative" on a roadmap.
What we can do is create environments where people have enough slack in their schedules and enough trust from their organizations to follow a question when it catches their attention, even when they can't yet explain where it's going or why it matters.
This is not an argument against accountability or rigor.
It's a reminder to recognize that curiosity is a means, not an end - a way of moving through the world that constantly reframes the question, re-evaluates the approach, and wonders what else might be possible.
The value of that orientation is tangible, but it is cumulative and indirect, and it will almost always lose in a head-to-head with something that can produce a number by Friday.
My daughter is not walking yet, but she's close. She stands, she cruises along furniture, she takes those wobbly half-steps between the couch and the coffee table that make your heart seize up a little because you can see both the triumph and the fall happening simultaneously. The crab-walk stair method is, by every available metric, a regression. She is slower, less stable, less successful. If you'd been tracking her stair-climbing velocity on a sprint board, you'd have flagged it as a risk to the delivery date.
But she isn’t trying to climb stairs efficiently. She is learning Newtonian physics - building a model of balance and weight and leverage that has nothing to do with getting to the top of the staircase and everything to do with what kind of movement will be available to her next. The “worse” method is the foundation. It’s the exploration that will eventually make running and jumping and dancing possible.
I think about this when I consider how to build an organization that reliably produces genuinely excellent and exciting things, and when I read about the history of ideas that changed everything and notice that almost none of them emerged according to a plan.
The impulse to abandon what works in order to find out if something else is possible - to accept the temporary regression, the slower method, the afternoon that doesn't produce anything billable - is not inefficiency. It's the foundation of everything that comes after.
She'll walk soon, and she’ll eventually climb the stairs on her feet. She doesn't know that for certain, but I do.
If I could, I would impart that same knowledge of inevitability to engineering and design teams everywhere: curiosity and experimentation are the foundations of expertise and innovation.