There's a piece of advice that sounds wise and is mostly useless: do the hard thing first. Eat the frog. Tackle the difficult task while your willpower is fresh.
As a productivity tip it's fine. As a way of running real work it's imprecise in a way that quietly causes most of the trouble — because it confuses two things that aren't the same: difficult and uncertain. And it's uncertainty, not difficulty, that decides whether a piece of work goes smoothly or falls apart in the final stretch.
Difficult Is Not the Same as Uncertain
A task can be hard but certain. Migrating ten thousand records by hand, writing the exhaustive test suite, wiring up the hundred screens that all work the same way — laborious, tiring, genuinely difficult. But you know exactly how it will go. There are no surprises waiting inside it. Difficulty like that is just cost; it can be scheduled, parallelised, ground through whenever.
A task can be easy but uncertain. A small integration with a system you've never touched. A format you've never had to produce. A two-day spike on whether an approach even works. Little effort on paper — but you have no idea what you'll find, and what you find might invalidate everything built around it.
The instinct most teams follow is to sequence by difficulty, or really by its shadow: they do the legible work first. The parts they understand. The screens, the CRUD, the comfortable build that produces visible progress and a good demo. It feels like momentum. And they leave the uncertain parts — the scary integration, the unproven approach, the thing nobody's sure about — for later, "once we're set up for it."
That ordering is exactly backwards, and the reason is about time, not virtue.
Why Uncertainty Goes First
Being wrong is cheap early and expensive late.
When you confront an unknown at the start of a piece of work, you have the most of the one resource that matters: time to respond to what you learn. If the integration turns out to be a nightmare, if the approach doesn't hold, if the format has an edge case that breaks your whole model — you find out while there's still room to change course, rebuild, renegotiate scope, or raise the alarm. Being wrong, at that point, is survivable. It's even useful: it's the cheapest information you'll ever buy about the shape of the work.
Confront the same unknown at the end and it's no longer information — it's a catastrophe. The runway is gone. Everything else has already been built assuming the uncertain part would just work. And now it doesn't, and there's no time. The legible work you front-loaded, all that visible progress, turns out to have been built on a foundation nobody had checked. This is the single most common way good teams arrive at a hard date in flames: not because they were lazy, but because they spent their abundant early time on the comfortable known and met the genuine unknown when they could least afford to.
Uncertainty doesn't get cheaper by waiting. It gets more expensive, because the cost of being wrong about it rises with every dependent thing you build on top while pretending it's settled.
Why It's a Discipline
If this is so logical, why doesn't everyone do it? Because doing the uncertain thing first is genuinely unpleasant, and every incentive in the moment pulls the other way.
The uncertain work is where you look incompetent. You start, and you fail, and you backtrack, and at the end of the first week you have nothing shiny to show — just a wall of things you now understand slightly better. Meanwhile the legible work would have produced a screen, a feature, a demo, something you could point at and feel good about. Confronting uncertainty first means trading visible early progress for invisible early learning, and choosing to look like you're going slowly when you're actually de-risking the whole endeavour.
That's why it's discipline and not just good sense. It's the same family as the unglamorous reps that buy you calm in a crisis, and the same family as holding a steady rhythm when breaking it would feel more productive. In each case the disciplined move is the one that feels worse now and is worth far more later — and the undisciplined move is the one that produces a comfortable feeling of progress while quietly storing up the real reckoning for the end.
Speed and the appearance of speed are different things. A team building legible work first looks fast and is accumulating hidden risk. A team confronting the uncertain core first looks slow and is retiring the risk that would have killed it. Only one of them is actually moving toward done.
In Practice
The move is simple to state and hard to do. At the start of any significant piece of work, before you let the comfortable build begin, ask the uncomfortable question: what here do we understand least, and what happens to everything else if we're wrong about it? Then go there first. Spike it, prototype it, integrate the scary system, produce the format you've never produced, prove the approach on the smallest real case. Buy the information while it's cheap.
You'll know you've found the right thing to do first because you won't want to. The part you're tempted to defer "until we're ready" is almost always the part you most need to confront now — because the not-wanting is the tell that it's where the uncertainty lives.
Prepare what can be planned, so you can meet what can't. The corollary, for any work big enough to matter: find what genuinely can't be planned yet — the real unknown — and go and meet it first, while being wrong is still cheap. Everything else can wait. That can't.
Thomas Riboulet is a Fractional VP of Engineering working with European tech companies. He writes about engineering leadership, team structure, and sustainable delivery at insights.wa-systems.eu.