Stop Starting, Start Finishing

I've run my own company for ten years. Managed teams, shipped products, delivered custom software for clients. You learn something in that environment that no book teaches you: the only thing that matters is done.

Not "in progress." Not "almost ready." Not "waiting for review." Done. Merged. Deployed. In the hands of users.

Over the years, I've seen the same pattern in team after team. Good teams, competent people, solid technical skills. Yet tickets sit in progress for weeks. Pull requests iterate for seven to fourteen days. Sprint boards never get cleaned at the end of a sprint. Estimates are reasonable, but a 3-point ticket takes a week, and an 8-pointer stretches across an entire sprint and beyond.

These teams aren't bad. They understand what needs to be done and can do it. They just never push to finish. Instead, they work day by day, steadily but without urgency toward completion.

If this sounds familiar, or if you recognize your own team in it, this post is for you. These are the principles that separate teams that ship from teams that are always busy but never done.

This isn't just opinion. Google's DORA research, the largest study of software delivery performance ever conducted, has been measuring thousands of engineering teams since 2014. Their data is clear: the best teams don't choose between speed and quality. They get both. The principles below are how.

This is the biggest mindset shift. Many teams optimize for perfection per pull request instead of incremental delivery. They want every PR to be complete, polished, fully tested, with every edge case covered. Noble goal. Terrible strategy.

Here's the truth: a merged, working, smaller change is worth more than a perfect change that sits open for two weeks. That open PR is a liability. It drifts from main. It blocks other work. It occupies mental space for both the author and the reviewers.

To be clear: this is not permission to merge bad code. Your team's quality bar (clean architecture, meaningful tests, readable code, proper error handling) is non-negotiable. The point is to distinguish between meeting the bar and gold-plating beyond it. A PR that solves the ticket cleanly and correctly is done. A PR that also refactors three neighboring files, adds tests for unrelated edge cases, and updates documentation for a different feature has lost focus.

Perfectionism disguised as thoroughness is still a blocker.

Amazon calls this "bias for action," one of their core leadership principles. The idea: most decisions are reversible. A wrong decision that ships today can be corrected tomorrow. A perfect decision that ships next month has already cost you a month of learning. Jeff Bezos famously distinguishes between "one-way door" decisions (irreversible, take your time) and "two-way door" decisions (reversible, move fast). Most engineering work is a two-way door.

Every day a feature sits unmerged is value lost. Not just developer time, but user value. If a feature delivers 1000 euros of value per month to users, and it sits in review for two weeks instead of two days, that's roughly 400 euros of value that never reached anyone. Multiply that across every PR in your pipeline. The cost of delay is invisible, which is exactly why teams ignore it.

If everything is "in progress," nothing is.

Look at your sprint board right now. How many tickets are in the "In Progress" column? If it's more than one per developer, you have a problem. Context-switching between multiple tickets destroys focus and ensures that none of them get finished quickly.

Push for a hard rule: one ticket per person, two at most. The natural consequence is that people finish things before starting new ones. This single change will transform your velocity.

The math is counterintuitive but proven: starting fewer things means finishing more things. Every Kanban practitioner knows this. Every team that ignores it pays the price in carried-over tickets.

This isn't a theory. It's a mathematical law from queueing theory, proven by John Little in 1961:

If your team's throughput is 2 tickets per week and you have 10 tickets in progress, each ticket takes an average of 5 weeks to complete. Cut WIP to 4, and the same throughput gives you a 2-week cycle time. Cut WIP to 2, and you're at 1 week. The throughput didn't change. The team didn't work harder. They just stopped starting and started finishing.

Pull requests should be reviewed within 24 hours. Not "when I get to it." Not "after I finish my own ticket." Within 24 hours.

A PR open for a week is:

• A context-switching tax on the author who has to revisit code they wrote days ago
• A merge conflict waiting to happen
• A blocker for downstream work that depends on it
• A signal that the team doesn't prioritize shipping

If your team struggles with this, measure it. Track the average time from PR opened to first review. Share the number in retros. What gets measured gets managed.

Consider a PR that needs two rounds of feedback. The total review effort is identical. The only variable is response time:

Same work. Same quality. But one approach delivers value ten days sooner. Now multiply that across every PR your team opens in a sprint.

Google's internal engineering data backs this up. Their research found that teams with review turnaround under 24 hours have significantly higher developer satisfaction and ship more reliably. It's not a trade-off. Faster reviews produce better outcomes on every axis.

This is different from ticket slicing. Your tickets might be well-sliced. The problem is what happens within a ticket: not knowing when the code is good enough to merge.

I see this pattern constantly: a developer picks up a well-scoped 3-point ticket. They implement the feature. Then they notice the surrounding code could use a refactor. Then they add extra test coverage for edge cases that aren't in the acceptance criteria. Then they update the documentation. Then they extract a utility function. Suddenly a 3-point ticket has become a week of work.

The discipline is knowing when to stop. Implement what was asked. Make it work. Make it correct. Make it safe. Then open the PR.

Everything else is a follow-up:

• "Refactor X module to use the new pattern." New ticket.
• "Add edge case coverage for Y." New ticket.
• "Extract shared utility from Z." New ticket.

Each of these is small, focused, and easy to review. Each ships independently. Each adds value on its own.

If a 3-story-point ticket has been in progress for more than three to four days, something is wrong. Either:

• The estimate was off (which is fine, re-estimate and communicate)
• The developer is stuck (which needs unblocking, not more time)
• The scope crept (which needs a conversation, not silent expansion)

Introduce the habit of raising a flag at the timebox boundary. Not as punishment. Not as micromanagement. As an unblocking mechanism.

If your team culture makes people feel bad for asking for help, you have a bigger problem than velocity. The fastest teams I've worked with are the ones where someone says "I'm stuck" and three people immediately jump in. Unblocking is a team sport.

PR review culture might be the hidden root cause of your slow cycle times.

If reviewers are requesting architectural changes or scope expansion during review, that's a planning failure being paid for in review time. Reviews should catch:

• Bugs and logic errors
• Security issues
• Readability problems
• Missing error handling for real scenarios

Reviews should not be the place where:

• The solution gets redesigned
• Scope gets added ("while you're at it, could you also...")
• Code style preferences get debated for days
• Theoretical edge cases get raised that aren't in the requirements

Push for alignment before the PR is opened. The review should be a final check, not a design session.

Never cleaning the sprint board normalizes carrying work over. Carrying work over normalizes not finishing. Not finishing becomes the culture.

Start doing proper sprint retrospectives with one honest question: "What didn't we finish and why?"

Not to blame anyone. To identify the pattern. Usually it's one of:

• Scope creep in PRs. Solution: principles 1 and 4
• Review bottlenecks. Solution: principle 3
• Too much WIP. Solution: principle 2
• No urgency to close. Solution: all of the above

Track your sprint completion rate. If you're consistently completing less than 80% of committed work, something systemic needs to change. The sprint boundary should feel real. It's a commitment, not a suggestion.

Google's DORA research classifies teams into four performance tiers: elite, high, medium, and low. The gap between elite and low performers is staggering:

The counterintuitive finding: elite teams are faster and more stable. They don't sacrifice quality for speed. They achieve both because of the principles in this post: small batches, fast feedback, limited WIP, continuous delivery.

These principles are easy to understand. The hard part is adoption. Here's what I've learned about introducing change in teams:

Before you preach any of this, live it. Ship small PRs. Review others' PRs fast. Close your tickets early. Let the contrast speak for itself. People notice when someone consistently ships while others spin.

In retros, ask questions instead of making statements. "What would help us get PRs merged faster?" lands better than "Our PR cycle time is terrible." Let the team discover the problem themselves. Solutions they own stick better than solutions imposed on them.

When you pair with someone, they absorb your pace naturally. They see what "pushing to done" looks like without a lecture. Pairing is the fastest way to transfer engineering culture.

Pick the highest-leverage change, probably the 24-hour PR review rule, and propose it as a two-sprint experiment. Measure the results. Let the data do the convincing. If it works, the team will want to keep it. If it doesn't, you've lost nothing.

Behind all seven principles is one idea:

Your team is probably working hard. They're putting in the hours. They care about quality. None of that is the problem. The problem is that effort without urgency toward completion produces motion, not progress.

A team that ships ten small, good PRs per week will always outperform a team that ships two perfect PRs per month. Not because the work is better, but because the feedback loops are faster, the integration pain is lower, and the momentum is real.

Stop starting. Start finishing. Everything else follows from there.

• DORA State of DevOps Reports

  Google's ongoing research program measuring software delivery performance across thousands of teams. The source for the elite vs. low performer metrics.

• Accelerate: The Science of Lean Software and DevOps

  Nicole Forsgren, Jez Humble, and Gene Kim's research-backed evidence that elite teams optimize for lead time and deployment frequency.

• Kanban: Successful Evolutionary Change for Your Technology Business

  David J. Anderson's foundational book on WIP limits, Little's Law, and flow-based delivery.

• Shape Up: Stop Running in Circles

  Basecamp's methodology for shipping meaningful work in fixed time frames with hard deadlines.

• Google Engineering Practices: Code Review

  Google's public code review guidelines and the basis for their 24-hour review culture.

• Amazon's Leadership Principles

  'Bias for Action': speed matters in business, and most decisions are reversible two-way doors.