Stop Starting. Start Finishing.
Why iteration beats multitasking — and how to build a culture that actually delivers
Recently, I assigned a colleague a small but well-defined task. The kind of task that delivers value on its own, can be shipped quickly, and doesn't cause any stress.
After a while, they tell me: «In the meantime, I also started working on tasks X and Y since they were related. That way I can include everything in a single PR».
Sounds efficient, right? Wrong. That’s how the mess begins.
The result?
A PR that’s too big to review properly
No way to release incrementally
Higher risk of introducing regressions
Slower release timelines
Slower, less accurate product feedback (too many scenarios to test)
Less focus, more effort
In the end, I asked them to revert everything and stick to the original scope.
The priorities had already been set, not just because that task mattered, but because releasing in small chunks lets us deliver value sooner. And more often.
The iterative approach
The iterative approach isn’t about “doing the bare minimum.” It’s about doing one thing at a time, doing it well, shipping it fast, and then moving on to the next.
It’s a strategy. Not a constraint.
The goal of this issue isn’t just to highlight the importance of an iterative approach or the benefits of early feedback. It’s about proposing and sharing practical strategies to strengthen this culture within the team.
Before delving into the strategies, though, I’d like to focus on something as important.
Multitasking: the myth that trips us all up
It’s often mistaken for efficiency, proactivity, or initiative. But most of the time, multitasking slows down the flow, scatters focus, and makes it harder to deliver value consistently. We end up juggling multiple things at once, but with less depth, more context switching, and results that arrive later. Often with more issues.
I bring this up because it’s often tied to the idea of “doing multiple things at once.”
I mentioned it briefly in the last issue but it’s worth repeating: starting a new task just because you're blocked on another comes with the same downsides we’ve already seen: lost focus, fragmented context, and delayed delivery. It’s not just inefficient. It’s risky:
If you’ve got 10 tasks open and none completed, you’re not making progress
Every piece of context you carry around drains your mental energy
The more things you start, the greater the risk: mistakes, slowdowns
More tasks in progress = less time (and clarity) to finish them
And if you don’t believe me, believe the science.
How to nurture an iterative culture?
The iterative approach isn’t something you install like a plugin. It’s built piece by piece. And like any culture, it takes concrete examples, ongoing course correction, and long-term consistency. Here are a few practical actions you can start putting in place right away.
Divide et impera
Not everything starts out as “iterable.” But almost anything can be made that way. A complex feature? Break it down into smaller tasks that make sense on their own. You’re not cutting corners. You’re reducing risk, improving focus, and building incremental value.
The feature cannot be split in smaller tasks? Not a big deal, you can have an iterative approach in any case. You can still release the feature in small, hidden steps that let you focus on a more manageable part of the problem.
This makes code review easier for your teammates, allows you to test in production with no immediate user impact, and only expose the feature when it’s truly ready.
QA and post-release testing also become less stressful and more focused, with a smaller scope to cover.
Give context to priorities
Saying «this comes first» isn’t enough.
Explain why something is a priority. I’ve already talked about priorities in the previous issue. I don’t want to repeat myself here but it is worth giving a look at it:
Step in early when things go off track
If someone takes the initiative to “do more” without alignment, don’t let it slide. Even if the intentions are good. Intentions don’t matter much if the result is an unmanageable PR or work that needs to be reverted. The more you let it happen, the more it sets a precedent and the harder it becomes to fix later.
Being direct helps in this case: «I know you meant well, but the way we work requires sticking to the defined scope. We talk first, not after».
The hardest part here is being able to find a good balance between stepping in and letting them taking initiatives.
Normalize the revert
A revert isn’t a punishment but a tool. It’s how we get back to a stable point when something goes off track. It’s a reminder that not everything needs to be salvaged: some things just need to be deleted and redone. Maybe better, and smaller.
If you treat a revert like a failure, people will start defending bad decisions just to avoid doing it. But if you normalize it, it becomes part of the learning process.
Visualize (and limit) the WIP
People often don’t even realize they’re juggling too many things.
Visualize the work in progress: use a task board, swimlanes by person, WIP limits per column. Showing how much is in progress but not done is the first step to building awareness.
Create short, regular release cycles
If you only release every two weeks, the team won’t feel any urgency. But if there’s an opportunity to ship to production every day, you start thinking in terms of shippable slices.
The focus shifts to delivered value, not just written code.
Make progress public, not just plans
Share with the team and the stakeholders what’s actually been shipped each week.
The more visible the value of frequent releases, the more the team will be motivated to work in small, shippable steps.
Building small habits that reinforce the right behavior helps a lot on this. The CEO of my current company already talked about something I introduced the first day I joined the new company: an #updates channel on Slack. want to know more. I covered the topic in one of my previous issues too:
TL;DR
Iteration takes discipline. It means accepting that doing less now allows you to do better later. And if you’re in a leadership role, it’s your job to protect the team from itself.
Don’t wait for culture to emerge on its own. Because every massive PR you don’t ship is a missed opportunity. And one more problem waiting for tomorrow.
Credits: Illustration 1
…and I am the teammate who messed it up 🙉🤣