March 9, 2026
Seven principles that turn competent teams into high-performing ones. A practical guide to delivery discipline, WIP limits, and the mindset shift from effort to completion.
14 min read
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.
The shipping mindset
Before opening a PR, ask yourself: "Does this work? Is it correct? Is it safe? Does it meet our quality standards?" If the answer to all four is yes, ship it. The additional refactor of surrounding code, the extra test coverage for edge cases not in the acceptance criteria, the broader cleanup you noticed along the way? Those are follow-up PRs. File a ticket, move on.
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.
| WIP Approach | Typical Outcome |
|---|---|
| No WIP limit | 5 tickets started, 0 finished by mid-sprint |
| WIP limit of 2 | 2 tickets finished in week 1, 2 more started |
| WIP limit of 1 | Fastest cycle time, highest completion rate |
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.
Spotify's squad model learned this the hard way
When Spotify scaled their engineering organization, their squads struggled with exactly this problem: too many things in flight, nothing landing. They introduced strict WIP limits per squad, and cycle times dropped without hiring a single additional engineer. The throughput was always there. It was just buried under too much parallel work.
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:
Make it a ritual
The simplest implementation: make PR reviews a morning ritual. First thing you do when you sit down, check if anyone needs a review. Before you start your own work. Every day. It takes 15-30 minutes and it unblocks the entire team.
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:
| Fast reviews (24h) | Slow reviews (weekly) | |
|---|---|---|
| PR opened | Monday | Monday |
| First review | Tuesday | Next Monday |
| Author addresses feedback | Wednesday | Next Tuesday |
| Second review | Thursday | Monday after |
| Merged | Thursday | Monday after |
| Total calendar time | 4 days | 14 days |
| Total review effort |
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:
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:
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:
Reviews should not be the place where:
Align before the PR
If a PR gets more than two rounds of significant feedback, the review process isn't the problem. The alignment before the PR was. Invest in quick design chats, pairing sessions, or a 5-minute Slack thread before someone starts coding. The cheapest time to change direction is before the first line is written.
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:
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:
| Metric | Elite | Low |
|---|---|---|
| Deployment frequency | On demand (multiple per day) | Monthly to biannually |
| Lead time for changes | Less than one hour | One to six months |
| Change failure rate | 0 to 15% | 46 to 60% |
| Time to restore service | Less than one hour | More than six months |
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.
Microsoft: same engineers, different culture
Under Satya Nadella, Windows moved from a 3-year release cycle to continuous delivery. The result wasn't chaos. It was fewer bugs, faster fixes, and happier developers. The same engineers, the same codebase. The only thing that changed was the delivery culture. If Microsoft can do it with Windows, your team can do it too.
Where does your team stand?
You don't need to be elite tomorrow. But you should know where you are today. Start tracking four numbers: how often you deploy, how long from commit to production, how often deployments fail, and how fast you recover. These four DORA metrics will tell you exactly where to focus.
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.
Google's ongoing research program measuring software delivery performance across thousands of teams. The source for the elite vs. low performer metrics.
Nicole Forsgren, Jez Humble, and Gene Kim's research-backed evidence that elite teams optimize for lead time and deployment frequency.
David J. Anderson's foundational book on WIP limits, Little's Law, and flow-based delivery.
Basecamp's methodology for shipping meaningful work in fixed time frames with hard deadlines.
Google's public code review guidelines and the basis for their 24-hour review culture.
'Bias for Action': speed matters in business, and most decisions are reversible two-way doors.
| ~1 hour |
| ~1 hour |
