How to Put Cycle Time Improvement Strategies Into Practice: A 6-Step Guide for Startup Engineering Teams

Cycle time improvement strategies only work when they target the stage where your work actually waits, and most startup teams have never measured that. This guide takes you from a vague sense that delivery is slow to a baseline cycle time, a stage-by-stage breakdown, and a short list of changes you can test over the next few weeks.

Before you start, make sure you have read access to your Git host (such as GitHub) and your issue tracker (such as Linear). You also need a team willing to try small process changes and give them a fair run.

Step 1: Define cycle time for your team and pick start and end points

Cycle time is the elapsed time from the start of active work to its completion. The ambiguity is in "start" and "end," and tools define them differently, so choose yours deliberately and write it down where the whole team can see it.

Common start events:

• First commit: closest to when coding began, but it ignores any time spent before the first push.
• PR opened: easy to pull from GitHub, though it hides the coding phase.
• Issue moved to In Progress: captures the full effort, but only if people update the board reliably.

For the end event, use PR merged or deployed to production. If you deploy on merge, merge is the right end point and keeps the data simple. If you batch releases, use the deploy event, otherwise finished work that sits waiting for a release will look faster than it really is for customers.

Keep this metric distinct from its neighbors. Lead time runs from the request to delivery, so it includes the time an idea sits in the backlog. DORA's change lead time runs from commit to production. Your cycle time may overlap with both, which is fine as long as you say which clock you are running.

The most common mistake is starting the clock at ticket creation. A ticket that sat in the backlog for five weeks and took two days to build would look like a 37-day cycle, mixing a prioritization question with an engineering one. Backlog wait is worth examining, but separately.

A good written definition fits in one sentence, for example: "Cycle time is the time from first commit on a branch to the PR being merged to main."

Step 2: Pull your baseline from GitHub and Linear data

Export every merged PR from the last 60 to 90 days. For each one, capture these timestamps: PR opened, first review, approval, and merge. Also record the first commit time if that is your start event. Where your branch names or PR titles include Linear issue IDs, match PRs to issues so you can see which work type or project each belongs to. You can do this with the GitHub API or CLI and a short script, or with a spreadsheet for a small team.

Clean the data before you summarize it:

• Exclude bot-authored PRs and automated dependency bumps, or segment them into their own group.
• Remove reverted work and PRs that were closed without merging, since they distort the picture of normal delivery.
• Flag long-lived draft or epic branches, which can sit open for weeks without reflecting review delays.

Then report the median and the 85th or 90th percentile, not just the mean. A handful of PRs that stayed open for three weeks will drag the average up and tell you little about a typical change. The median shows what usually happens, and the percentile shows how bad the slow tail gets. Those two numbers together are your baseline.

Small teams produce few data points. A team of four might merge 30 to 50 PRs in a quarter, so a single stuck PR can swing a weekly figure dramatically. Use the longer window, and resist reacting to week-to-week movement. If you cannot tell whether a change is signal or noise, wait for more data.

Record the baseline somewhere durable, with the date range and the definition from Step 1. You will compare against it in every later step.

Step 3: Break cycle time into stages to find where work waits

A single cycle time number tells you how slow you are, not why. Split each PR's elapsed time into four stages:

1. Coding time: first commit to PR opened.
2. Pickup time: PR opened to first review.
3. Review time: first review to approval, including revision rounds.
4. Merge or deploy time: approval to merged, or to running in production.

Calculate the median for each stage and see what share of the total each one holds. In many teams, the waiting stages (pickup, review, and merge) account for more elapsed time than the coding itself. That is a common pattern worth checking, not a guarantee, so let your own numbers decide.

Find the single stage with the largest share and focus there first. Improving a stage that holds 10% of the elapsed time cannot move the total much, however much effort you put in.

Consider a simple example. A PR is opened Tuesday morning, gets its first review Thursday afternoon, and is merged Friday. The code took a day or so to write, but the change spent roughly two days waiting for someone to look at it. That is a pickup problem, not a coding problem, and telling the developer to code faster would change nothing.

Look at the distribution too. If pickup is fast for most PRs but terrible for a few, find out what those few have in common: a particular reviewer, a particular repo, large diffs, or PRs opened late on Fridays.

You can build this breakdown by hand in a spreadsheet. Progress produces it from your GitHub and Linear activity automatically, flagging stalled work and change pressure so a lead does not have to rebuild the analysis each time they want to check.

Step 4: Shrink batch size and pull request scope

Large changes wait longer for review, because reviewers postpone them until they have a free hour, and they get reviewed less carefully when they do. Smaller changes are easier to start on, easier to understand, and cheaper to revert.

Start by setting a working norm for PR size. A practical one is "reviewable in one sitting," meaning a reviewer can read and understand it without blocking out a chunk of their day. Treat it as a guideline, not a hard rule. Some changes, like generated code or a mechanical rename, are legitimately big.

Before you push this on the team, test it against your baseline. Sort your PRs by lines changed or files touched, then compare pickup and review time for the smallest and largest thirds. If the link is there, as it often is, you now have a case drawn from your own repositories instead of an opinion about best practice.

Three techniques make smaller PRs possible:

• Slice work vertically. Deliver a thin end-to-end piece of a feature rather than "all the backend, then all the frontend." Each slice should be mergeable on its own.
• Use feature flags. Flags let incomplete features merge safely behind a switch, so work does not pile up on long-lived branches.
• Separate refactors from behavior changes. A PR that moves code around and changes logic at the same time is hard to review. Put the refactor in its own PR, merge it, then build on top.

Expect some friction. Developers who are used to shipping a feature as one unit may feel that slicing adds overhead. A short planning conversation at ticket kickoff, asking "what is the first piece we can merge?", usually solves most of it.

Step 5: Speed up review pickup and merge with team agreements

If Step 3 pointed to pickup, review, or merge time, the fixes are mostly about agreements and automation rather than individual effort.

Agree on how reviews get requested and answered

Set a review-response expectation, such as "first response within the same business day," and make requests visible. That can be GitHub review requests with notifications turned on, or a dedicated Slack channel where authors post PRs that need eyes. Use CODEOWNERS and auto-assignment so nobody has to guess who should review a change. Unclear ownership is a quiet source of pickup delay, because everyone assumes someone else will take it.

Automate the slow parts

• Keep CI fast. If checks take 25 minutes, every revision round costs half an hour or more of waiting.
• Run linters and formatting checks in CI so reviewers do not spend comments on style.
• Turn on auto-merge or a merge queue so an approved PR lands without someone having to come back and click the button.
• Fix flaky tests. Every unexplained rerun adds waiting time, and flaky suites quietly add hours to merge time while teaching people to ignore red builds.

Protect review quality

The mistake to avoid is rewarding speed by lowering the bar on review. If approvals start arriving in minutes with no comments on substantial changes, you have not improved the process, you have removed a safeguard. Track rework, bug reports, and reverts alongside cycle time so you notice if quality slips. A faster number that produces more hotfixes is a loss.

Write the agreements down in a short team doc and revisit them after a few weeks. Agreements that nobody can find tend to fade.

Step 6: Run one change at a time, then review the trend and team health

Treat each improvement as an experiment. Pick one change per two to four week window, such as a same-day review expectation or a PR size norm. Name the stage metric you expect to move (pickup time for the review agreement, for instance), then compare the result with your baseline median and percentile. Changing several things at once leaves you unable to tell which one worked.

Watch for side effects while the experiment runs:

• Change failure rate, meaning the share of deployments that cause a problem needing remediation.
• Reverts and hotfixes.
• Reopened tickets or bugs traced to recently merged work.

If any of these climb as cycle time falls, speed has come at a cost, and you should adjust before continuing. If you want outside reference points, check the current DORA report for how it words its metrics and benchmarks before quoting them, and treat any industry figure as context rather than a target.

Numbers alone miss the human side. Pushing cycle time down while a team is stretched leads to burnout, shortcuts, and eventually slower delivery. Check how people feel about the pace through retros, one-on-ones, and any momentum or morale signals you have. Progress reads team momentum (whether work is accelerating or slowing) and morale from your development activity, and can generate an on-demand summary, which helps you catch strain or a slowdown early rather than discovering it in a missed deadline.

Finally, keep cycle time a system metric. Do not rank individuals by it. Developers differ in the type of work they take on, and a leaderboard invites gaming, such as splitting PRs artificially or rushing approvals. Confirm that this framing matches your team's norms, and say it out loud when you share the data.

Keeping the Gains: A Monthly Rhythm for Your Next Bottleneck

Revisit your baseline once a month, using the same definition and the same cleaning rules so the comparison stays fair. Keep the stage breakdown visible to the whole team, in a shared doc or a recurring slot in your retro, so improvement stays a team habit rather than a lead's private project.

Choose the next bottleneck only after the current change has shown a measurable effect. If pickup time dropped but review time now holds the largest share, that is your next experiment. If nothing moved, keep the change in place for another cycle or try a different lever on the same stage before moving on.

Learn more about our services