Right now, somewhere, a founder is threading their sprint on X. Four tickets closed. One demo shipped. A comment section full of people who have no idea whether the thing being built is the right thing. The velocity is real. The audience is real. The question nobody is asking out loud is whether the destination justifies the speed.
That founder isn't doing anything wrong, exactly. They're doing what the current playbook says: build in public, show momentum, make your progress legible to investors and peers. The problem is that performative output and real progress look identical from the outside... until they don't. And by the time the gap becomes visible, the runway is usually almost gone.
I watched this same pattern before it had a social media soundtrack. Before "building in public" was a strategy, before sprint velocity was a metric you could post. I watched it inside Nokia's gaming division, on a flagship phone that was already being manufactured while the software it was supposed to run was still in flux. And I watched what happens when nobody says stop -- because everyone has decided, without saying so, that the chaos is just the job.
In 2011, I was working on Nokia's next flagship phone -- what would eventually become the Lumia, Nokia's pivot toward Microsoft. I had come up through Nokia's gaming organization during the N-Gage to Ovi transition. When that unit was restructured and a mass layoff followed, I was moved to the new project. The leadership brought in to run it came from the game development world, and they imported the culture with them: compressed timelines, impossible deadlines, and a tolerance for chaos that the gaming industry had normalized over decades. When things felt insane, nobody said so. Insane was the baseline, because for most of the people in that room, it always had been.
The phone we were working on was supposed to be a flagship. The bodies were already being manufactured. Touch hardware was in production. And the SDK we were building the user experience against was still in flux -- changing not in refinements but in full reversals, every six weeks or so. New interaction patterns. New visual styling. New rules. Each cycle, the thing we had just designed against was no longer what we were designing for.
I was brought in on what was framed as a one-week assignment: an alignment and gap analysis, assessing where all the design work stood against the UX patterns. A tidy scope. A clear deliverable. What I found when I started pulling on it was something else entirely.
After six months of work, the team had been building against a moving target the entire time. What everyone had been calling "visual polish" was actually structural re-engineering -- deep, foundational work that needed to be redone, not touched up. The gold master, the moment the software gets imaged onto the device at the factory, the hard stop, the point of no return, was four to five weeks away.
There were moments six months earlier when it was apparent to me -- a plebe, way down on the food chain -- that this was not ready. I said as much to my closest working partner. We were skeptical, quietly, of how it was all going to come together.
There is something I have not said cleanly about that period. Skepticism did have a channel — I just chose not to use it. Nokia had always been an open culture; in my first nine months, anyone's number was fair game for a text if you had a question. But this team had closed that down. Don't talk about where we work. Don't talk about what we're doing. A contact in another group — someone who had been at Nokia long enough to know what normal looked like — had been signaling to me that the gyrations inside our team were not normal. I took that signal in and played it close to my chest. Nokia was mid-strategy-collapse, trying to straddle old and new at the same time, and I genuinely didn't know which version was going to survive. The secret project might still become the future of the company. I wasn't willing to bet against the room I was sitting in — not while I still might need it. So I matched the silence with silence and called it prudence.
A year after I was reassigned, I was still having conversations with people in adjacent teams — reassuring them that I hadn't been one of the VP's people, that my Nokia loyalty was still intact, that the association wasn't what it looked like. The work of separating myself from that team's reputation took longer than it should have, because I'd stayed quiet long enough that people weren't sure. I wasn't blocked from speaking when it mattered. I made a calculation, and I paid for it in a different currency than I expected.
Every time the concern surfaced, we heard the same thing from above: "It'll be fine. We have it under control."
So the team worked Saturdays. Not one Saturday. Multiple Saturdays, spent re-engineering huge swaths of interactions that had already been completed, approved, and moved past. Not because the work was bad. Because the target had moved again. Because the SDK had changed again. Because the thing we had spent the week building was no longer the thing we were supposed to be building. And still the phrase held: it'll be fine. We have it under control.
The problem was not that we worked Saturdays. There are moments when a team chooses to surge. The problem was that sacrifice had become a substitute for confronting whether the plan still made sense.
Nobody pushed back. The game dev culture had already answered that question before anyone asked it: this is just how it works. Keep moving.
Here is what I understand now that I didn't then: the performance of confidence and the actual presence of it are not the same thing. And from the outside, they look identical. My interpretation afterward was that leadership was managing the appearance of control rather than confronting the condition of the work. I cannot know exactly what the VP understood or intended, but the reassurance did not match what the teams closest to the product were seeing. "It'll be fine" may have been sincere. It may have been narrative management. What I know is that it stopped us from asking the question that mattered.
The version we had been building did not launch as planned. Much of the industrial and engineering work was redirected as Nokia's Microsoft strategy took over. The burning platform memo had already been published internally. Three years of industrial design, engineering, and UX work, erased. Those Saturdays paid for nothing.
Founders who inherit this pattern don't usually inherit it from Nokia. They inherit it from the startup ecosystem itself, which has its own version of game developer time: the idea that chaos is the job, that the whiplash of a two-week sprint is just what building looks like. Your team normalizes it because they've been told it's normal. You normalize it because you're moving too fast to question the baseline.
The first thing the velocity trap costs you is clarity. When you're shipping at speed, the question "are we building the right thing?" becomes a luxury you can't afford. The Jira board is full, the sprint is burning, the demo day is three weeks out. That pressure, real pressure, legitimate pressure, functions exactly the way a gold master deadline functions in hardware: it becomes the product. The deadline becomes the only destination. Everything else gets subordinated to hitting it.
The second thing it costs you is the truth from your own team. There is a gap -- I've come to think of it as the plebe gap -- between what frontline people know and what leadership is willing to hear. The term is borrowed from military culture -- the lowest rank, the person with no leverage and the clearest view of the ground. In every organization I have worked in, the plebes see the problems first. The people closest to the work see the problems earliest. But they've also learned, quickly, whether the organization rewards speaking up or punishes it.
At Nokia, the mechanism was simple. Most of my colleagues had been brought in by the VP. They owed him their positions. They were being paid well. The cost of saying "stop, we are sprinting off a cliff" was too high. So they kept sprinting.
Founders create this dynamic without meaning to. When a team senses that the founder's confidence is load-bearing -- that the whole narrative of momentum depends on nobody saying the quiet part out loud -- they go quiet. The alarm stays off. And the plebe gap widens with every sprint.
The third thing the velocity trap costs you, and this one doesn't show up in your burn rate calculation, is the team's trust in your judgment after the crash. At Nokia, leadership didn't own what those Saturdays cost us. The next crisis was already waiting. The trust that gets spent in those moments -- the willingness of good people to give 110% when it actually matters -- doesn't refill on its own. You spend it once. Then you find out what you have left.
I'm not going to tell you to slow down. Founders don't have that option, and I wouldn't have listened to that advice at Nokia either.
What I've learned building inside organizations at every scale is that the question isn't how fast you're moving. It's how quickly you're learning whether you're moving in the right direction.
Three things I'd tell a founder standing where I was standing:
Ask the kill question before the sprint begins. What would have to be true for us to stop this sprint and change direction? Not after the demo. Before it. If your team can't answer that question, or looks at you like it's a strange thing to ask, the gold master is already running. You've already decided the deadline is the destination. This doesn't have to be a meeting. It can be one question in Slack before you kick off. The point is to ask it before the sprint answers it for you.
Find your plebes and actually listen to them. The people closest to the work know what's going wrong before you do. The question is whether you've built a culture where they'll tell you. This doesn't require a formal retrospective or a structured process. It requires asking -- plainly, in a one-on-one -- what are we not talking about that we should be? And then being the kind of leader who doesn't make people regret the answer. One conversation. One honest question. That's the whole process.
Measure something that isn't activity. Velocity is an activity metric. Tickets closed, sprints completed, demos shipped: all activity. What are you measuring that tells you whether users are actually adopting the thing, returning to it, getting the outcome you promised them? If the answer is "we'll figure that out after launch," the trap is already set. You don't need an analytics platform to start. You need one metric that isn't about output.
None of this is slow. All of it is aimed.
The phrase I've carried from Nokia, the one I can't shake even fifteen years later, is this: if you're shipping the wrong thing faster, you're not gaining efficiency. You're just shortening the distance to regret.
Founders don't go fast because they're reckless. They go fast because the pressure is real, the runway is finite, and the market doesn't wait. I understand that. I lived it. But Nokia didn't fail because it moved too slowly. Nokia's collapse had many fathers: platform strategy, ecosystem decisions, the weight of a hardware company trying to compete against a software one. But inside the part of the company I could see, one thread of that failure was this: we moved at full speed toward a destination that was no longer stable -- and kept the alarm off long enough that by the time the crash came, there was nothing left to do but send the memo and watch the talent leave.
You can't always know in advance whether you're building the right thing. That's the honest truth of early-stage product work. But you can build a company where the people closest to the work feel safe enough to say so when the target is moving. And you can build a team where the kill question isn't a threat. It's just Tuesday.
The goal isn't to arrive at regret more slowly. It's to make sure the destination is worth arriving at fast.
Simon Carney is Founder and Principal UX Strategist at Consortium UX, a boutique UX strategy consultancy serving VC-backed founders in complex, regulated markets. He has spent thirty years diagnosing the gap between what founders think is wrong and what's actually wrong. This is Part 1 of The Performance Trap series.