skip to content

Search

Harnessing Kaizen: Continuous Improvement for Software Teams

Less than one minute read Updated:

Embrace the Kaizen mindset to drive small, incremental improvements that compound into major gains.

# product-management
# strategy
# leadership
# kaizen
Not in series

The best fix your team will ship this quarter costs nothing and takes ten minutes.

Toyota built an entire manufacturing philosophy on that idea. Kaizen, Japanese for continuous improvement, says small inefficiencies compound into technical debt if nobody names them, and small fixes compound into speed if somebody does. I have watched both directions play out on three teams, at Dell, at Pixis, and now at InMobi, where I own the system of record under a demand-side platform and ad exchange that processes 200M-plus devices’ worth of ad events a day.

Here is the proof that the small stuff matters. The month-end revenue close on that InMobi data went from 5 days to 12 hours. Nobody rewrote the product. Somebody kept fixing the small things until the big number moved.

So that’s today’s post.

Today’s Post

Five habits that turn kaizen from a poster on the wall into a number that moves, in order.

  • Start stand-ups with a blocker report, not a status report
  • Give process fixes their own backlog, or they never win a prioritization fight
  • Make quality everyone’s job, not one person’s job
  • Automate the boring step before you automate the interesting one
  • Measure lead time on purpose, in a retro built for exactly that

1. Start with blocker reporting, not status reporting

Most daily stand-ups answer one question: what did you do yesterday. That question produces a status update. It does not produce a fix.

Blocker reporting asks a different question: what small thing slowed you down today. An outdated library. A flaky test nobody owns. A Jira field three teams fill in differently. Each answer is a two-sentence story, not a report.

The habit only works if a blocker gets a next step in the same meeting, not a promise to look into it. Either someone commits to removing it before the next stand-up, or the team writes it down somewhere it cannot be forgotten. That somewhere is section 2.

2. Give process fixes their own backlog

A product backlog and a process backlog compete for the same sprint capacity, and the product backlog wins every time it is asked to compete. The fix is not willpower. It is a second backlog with its own prioritization, so a process fix never has to out-argue a feature for the same slot.

Kaizen backlog: a running list of process fixes, ranked the same way you rank features, by impact against effort. Low effort and high impact goes to the top, same as a product backlog, so the cheapest wins ship first.

Here is what a kaizen backlog item looks like when it pays off. At Pixis, my first mandate on the data platform under the AI was cutting data delay from 4 hours to under 15 minutes, for 400-plus enterprise customers. None of that demoed well in a sprint review. All of it is why the recommendations the product surfaced on top of that data were worth acting on at all.

Two backlogs, ranked the same way Low effort and high impact goes to the top of both lists. Only one of them ever ships the data-delay fix. Grey monospace text names the Pixis example that only survives on the kaizen backlog. RANK 1 RANK 2 RANK 3 PRODUCT BACKLOG KAIZEN BACKLOG Ship the new dashboard demos well in the sprint review Onboarding flow redesign a feature, competing for the same slot Reporting API v2 also a feature, also wins the argument Cut the data platform's delay never demos well, never wins a feature fight Pixis: 4 hours to under 15 minutes Give the flaky test an owner low effort, ranked on impact like a feature Fix the slow build cache cheapest win, ships first The item that only survives here Data delay for 400-plus enterprise customers, before and after the fix. Before 4 hours After under 15 minutes a feature the item that never wins a feature fight a process fix, ranked on the same terms
Ranked the same way as a product backlog, a data-delay fix wins a slot it would never win against a feature. PNG ↓

Nobody writes “reduce data delay” into a sprint goal next to “ship the new dashboard” and expects it to win. Give it its own list, and it does not have to.

3. Make quality everyone’s job

A siloed team treats process health as one role’s problem: a QA lead owns bugs, a DevOps engineer owns pipelines, a PM owns backlog hygiene. Kaizen culture removes the “not my job” boundary. Everyone on the team owns quality, efficiency, and the eventual outcome, together.

That shift shows up as effort, not as a policy. At Pixis, a 20-person team took the AdRoom product from $0 to $10 million ARR in five months. A team that size cannot afford a dedicated process-quality role. The only way it works is if the engineer who hits a slow build fixes the build, and the designer who spots a confusing onboarding step flags it in the same stand-up as a blocker, not in a separate design review three weeks later.

The two-week onboarding sprint that produced $800K ARR in two months, across four automotive and consumer-tech brands, ran the same way. Nobody assigned one person to own activation. The whole team watched the one metric that mattered and fixed whatever stood between a brand and its first live ad.

A team without a “that’s not my job” sentence in its vocabulary is a team that ships kaizen for free.

4. Automate the boring step first

Automation is where kaizen compounds the fastest, because a fix you automate keeps paying out after the person who made it has moved to a different problem. The trap is automating the interesting step before the boring one. CI pipelines and linting matter, but the highest-leverage automation is usually the manual step nobody wants to talk about because it is tedious, not because it is hard.

The InMobi close is the clearest example I have. Finance could already see every line of revenue from 200M-plus devices’ worth of daily ad events. Dashboards were never the constraint. The constraint was a manual reconciliation step that took days. Automating that step, not adding a new chart, is what took the close from 5 days to 12 hours.

The InMobi month-end close, before and after automation Finance could already see every line of revenue. The constraint was a manual reconciliation step, not a missing dashboard. Bars are proportional to hours; the close covers 200M-plus devices' worth of daily ad events. Before 5 days manual reconciliation, run by hand After 12 hours the reconciliation step, automated time to close the month, proportional to hours
The dashboard already existed. The win was automating the manual step underneath it. PNG ↓
A blocker named once, closed once, remembered once Stand-up names it, the kaizen backlog holds it, the team ships it, the retro records it, and the loop feeds the next stand-up. Scroll slowly, this plays once. Grey monospace text names what changes at each stage. Stand-up A blocker gets named out loud, not filed away "the data delay slowed us again" Kaizen backlog It lands on its own list, ranked by impact and effort not competing with a feature Team ships the fix Whoever hit it owns the fix, not a process owner 4 hours to under 15 minutes Kaizen retro Records what changed, separate from the sprint retro lead time reviewed on purpose feeds the next stand-up the trigger, out loud a step of the loop the record that closes it and reopens it
The loop only compounds if the retro's record makes it back to the next stand-up. (animates as you scroll to it) PNG ↓

CI/CD and static analysis still belong on the list. They catch defects early and keep code standards consistent. Rank them the same way as everything else on the kaizen backlog: by what they save, not by how interesting they are to build.

5. Measure lead time, on purpose

Kaizen without measurement is a vibe, not a system. The metric that ties every habit above together is lead time: how long an idea takes to reach production. Every fix in sections 1 through 4 should shorten that number, and the only way to know if it did is to look on purpose, not by accident.

Kaizen retro: a retro scheduled separately from the sprint retro, with one job, reviewing process health instead of the sprint’s output. A sprint retro asks what happened this sprint. A kaizen retro asks whether the team is faster than it was last quarter, and it only gets an honest answer if someone is tracking lead time between the two.

The habit that makes this stick is small: put “did we get faster” on the calendar with the same seriousness as “did we ship.” A number that nobody reviews on a schedule is a number that nobody trusts.

Takeaways

Five habits that make kaizen a number, not a poster From a stand-up question to a lead-time retro, in the order they compound Hoshank Ailani · hoshank.vercel.app 1. Blocker reporting Stand-up asks what slowed you, not what you did Each answer is a two-sentence story A next step in the same meeting, not a promise unnamed friction gets routed around silently for weeks the fix costs nothing and takes ten minutes 2. A backlog of its own Ranked by impact against effort, like a product backlog Never has to out-argue a feature for the same slot Pixis data platform, 400+ enterprise customers 4h → <15min the fix that only survives on this list 3. Shared ownership No "not my job" boundary between roles The engineer who hits a slow build fixes it AdRoom, a 20-person team, five months $0 → $10M ARR too small a team for a dedicated process role 4. Automate the boring step The tedious step, not the interesting one, first Keeps paying out after the fix is forgotten InMobi month-end close, 200M+ devices/day 5 days → 12h a reconciliation step, automated, not a new chart 5. Measure lead time, on purpose 1 A kaizen retro, scheduled separately from the sprint retro 2 One job: is the team faster than it was last quarter 3 "Did we get faster" on the calendar, same as "did we ship" a number nobody reviews on a schedule is a number nobody trusts this is the metric that ties the other four habits together The best fix your team will ship this quarter costs nothing and takes ten minutes. Pick the habit your team is worst at, and see what lands on the kaizen backlog by Friday. Full post: hoshank.vercel.app/posts/kaizen Takeaways
The whole post on one card. Save it, share it, argue with it. PNG ↓

Five habits, one per section. Pick the one your team is worst at and start there this week.

Final Words

Kaizen is not a program you launch. It is a habit of naming small friction out loud and giving it somewhere to go. Start with one stand-up where blockers get named instead of statuses, and see what lands on the kaizen backlog by Friday.

Reply and tell me what you found. I am collecting the small fixes that turned into big ones.

Cheers, Hoshank