Beyond the Basics: Kaizen

You’ve heard about kaizen. Continuous improvement. Small changes that compound over time. It sounds brilliant. Who wouldn’t want their team constantly getting better?

But here’s what actually happens: teams read about kaizen, get excited, announce they’re “doing kaizen now,” have a few retrospectives, maybe create a suggestions box… and within three months, it’s business as usual. The kaizen initiative joins the graveyard of well-intentioned process improvements that didn’t stick.

The difference between teams where kaizen becomes genuinely embedded versus those where it becomes another forgotten buzzword isn’t about enthusiasm or good intentions. It’s about understanding that kaizen isn’t a programme you implement. It’s a fundamental shift in how your team thinks about work.

The Development Context

Technical considerations

Right, let’s start with something most kaizen guides overlook entirely: the technical environment shapes what kinds of improvements are actually possible.

Imagine a team wanting to improve their release process. They’d embraced kaizen, held regular retrospectives, identified dozens of improvements. But nothing changed because their codebase was a mess. Tightly coupled, minimal test coverage, and a deployment process that required three people working simultaneously to avoid breaking production.

Every improvement they proposed ran into the same wall: “We can’t do that without refactoring X first.” But they couldn’t prioritise refactoring because they were too busy firefighting issues from their fragile codebase. Classic doom loop.

Here’s what they should’ve done: instead of trying to kaizen the process around a terrible technical foundation, they made improving that foundation the kaizen focus. Small, incremental technical improvements that made everything else easier. Added tests for the most brittle components. Decoupled the most entangled modules. Automated the most error-prone manual steps.

Three months later, the deployment process improvements they’d identified initially would become trivial to implement. The technical groundwork would enable continuous improvement everywhere else.

The lesson: your technical context determines what improvements are feasible. If your architecture, tooling, or technical practices create friction, that’s where kaizen needs to start. Everything else builds on that foundation.

Debt compounds in both directions: technical debt makes future improvements harder. Technical investment makes them easier. Every small improvement to your codebase, tests, tooling, or infrastructure expands the possibility space for future improvements.

At a SaaS company I worked with, we implemented a rule: every sprint, at least one “technical quality” item alongside feature work. Not big rewrites, but small, targeted improvements. Better logging for a problematic service. Tests for an uncovered module. Documentation for a confusing API.

Individually, these were minor. Collectively, over six months, the accumulated improvements transformed how quickly the team could move. Features that used to take weeks to ship safely now took days. Bugs that used to require hours of investigation were obvious from logs. New engineers could contribute productively within weeks instead of months.

That’s kaizen working with your technical context instead of fighting it.

Team dynamics

This is where kaizen really lives or dies: whether your team actually feels safe suggesting improvements and believes they’ll be taken seriously.

Maybe it will sound familiar: a team where retrospectives had become theatre. Everyone knew the real problems: unclear requirements from product, last-minute priority changes, one senior engineer who’d veto any architectural suggestions. But nobody mentioned these in retros. They stuck to safe topics like “we should update our documentation” or “maybe we need better coffee” (ok, the last one is actually important).

Why are they stuck with safe topics? Because the one time someone had raised a genuine issue about the product process, they were told it was “out of scope for engineering” to comment on. Another time, someone suggested a different approach to a technical decision and the senior engineer spent 20 minutes explaining why they were wrong in front of the whole team.

You can imagine how much continuous improvement happened in that environment.

Here’s the uncomfortable truth: kaizen requires psychological safety, and psychological safety requires actual safety. If people get shut down, ignored, or made to feel stupid when they suggest improvements, they’ll stop suggesting improvements. You can’t kaizen your way out of a culture problem.

It’s good to establish a simple principle: every suggestion gets a serious response. Not necessarily “yes, we’ll do that,” but a genuine consideration of the idea with clear reasoning about the decision.

Someone suggested moving from Jira to Linear because they found Jira overwhelming. No need to implement it, but we also don’t dismiss it. Discuss what specifically about Jira is problematic, whether Linear would actually solve those problems, and what the switching cost would be. Then you could decide to stick with Jira but simplify the workflow configuration to address the core concern. The person who made the suggestion feels heard, even though the team didn’t do what they proposed.

That’s what creates the conditions for kaizen: people see that suggestions lead to actual consideration and sometimes real change.

The manager’s role is critical: if you’re leading a team, your response to suggestions sets the tone. Thank people for identifying problems. Ask clarifying questions. Be honest about constraints and tradeoffs. And most importantly, implement some suggestions, especially early ones. Nothing kills kaizen faster than seeing every idea disappear into a void.

I’ve also seen the opposite problem: teams with great psychological safety but no follow-through. Everyone suggests improvements, all ideas are welcomed enthusiastically, retrospective actions are captured… and then nothing happens. That might feel better than being shut down, but it’s equally corrosive to kaizen because people learn their suggestions don’t actually matter.

You need both: genuine openness to ideas AND actual implementation of improvements. One without the other doesn’t work.

Implementation Approach

Best practices

Let me share the approaches that actually work for embedding continuous improvement, based on teams I’ve worked with directly rather than management theory.

Make improvement part of the work, not separate from it: The fatal mistake is treating kaizen as an additional thing your team does on top of their real work. “We’ll spend Friday afternoons on improvements!” Sounds good, never works. Friday afternoon improvement time gets sacrificed whenever there’s pressure, which is always. Or- work on Friday is always a bad idea, am I right or am I right? Anyway…

Instead, build improvement directly into how you work. At that SaaS company, we had a simple rule: every pull request could include improvements to code it touched, even if unrelated to the primary change. Fixing variable names while you’re in there? Great. Adding a test? Even better. Cleaning up confusing logic? Perfect.

This meant improvement happened continuously as a natural part of development, not as a special activity requiring dedicated time. Over a year, the accumulated small improvements transformed the codebase without ever having a “refactoring sprint.”

Start with pain, not perfection: Don’t try to improve everything. Ask your team: “What’s the most annoying part of our current process?” Whatever comes up consistently that’s where to focus.

A team I worked with was drowning in documentation debt. Every new feature needed to be documented, but nobody ever had time, so it piled up. Eventually, nobody trusted the docs because they were so out of date.

We didn’t solve this with a “documentation sprint” to catch up. Instead, we made the process tolerable: created templates that were actually easy to fill in, set up automatic screenshot tools so documenting UI wasn’t tedious, and most critically, made docs a release gate so they couldn’t be postponed.

Documentation went from constantly in arrears to actually current. Not because the team suddenly cared more about docs, but because we removed the friction that made it painful.

Measure what matters, not what’s easy: Many teams track kaizen by counting improvement tickets completed or retrospective actions closed. This creates terrible incentives, because teams start suggesting trivial improvements that are easy to implement instead of meaningful ones that actually matter.

Better approach: measure outcomes. Is deployment getting faster? Are bugs decreasing? Is time from commit to production shrinking? Are new engineers productive sooner? Is the team’s sprint velocity more predictable?

These metrics reflect whether your improvements are actually improving anything. You can close 50 “improvement” tickets that don’t move these numbers at all.

Create feedback loops shorter than your planning cycle: If it takes a sprint or more to see whether an improvement worked, you’ll never iterate effectively. Build in ways to get fast feedback.

Fast feedback lets you adjust quickly. If an improvement isn’t working, you find out soon enough to fix it. If it is working, you can double down.

Tooling and process

Let’s be specific about the mechanics of making kaizen operational, not just aspirational.

Retrospectives that don’t suck: Standard retros often become either complaint sessions or empty rituals. Here’s what makes them valuable:

Focus on one or two specific topics, not everything. “How did deployment go this sprint?” is more useful than “what went well and what didn’t?” The latter is too broad. You get scattered observations that don’t lead anywhere.

Always leave with one concrete action with a specific owner and deadline. Not “we should improve our documentation,” but “Alice will create doc templates by next Wednesday, then we’ll try them for a sprint and reassess.” Specificity creates accountability.

Review previous actions at the start of each retro. This prevents the “we keep identifying the same problems but never fix them” syndrome. If an action hasn’t been completed, either finish it, schedule it properly, or explicitly decide it’s not worth doing and drop it.

Make improvement visible: The SaaS team I mentioned maintained a simple “improvements this sprint” section in their sprint review. Just a mention showing the non-feature work that made the team better. This served two purposes: it made improvement feel like real work worth doing, and it helped stakeholders understand that not every sprint delivers only features. By the way: beware of becoming a feature-factory. But that’s another topic for another time.

Some teams maintain a shared document of improvements implemented over time. Looking back over six months of accumulated changes is powerful. Individually minor, collectively transformative. Like an eternal log of improvements. Really cool.

Budget time explicitly: If your sprint planning allocates 100% of capacity to features, improvement won’t happen except accidentally. We typically reserved 20-30% of capacity for tech debt, refactoring, tooling improvements, and process changes.

This isn’t “wasted” capacity. It’s investment in making future work faster, safer, and more pleasant. Teams that don’t budget for improvement slow down over time as technical debt and process friction accumulate.

Use the right tools for your context: teams successfully do kaizen with everything from sophisticated project management platforms to a shared document with a list of improvements. The tool matters far less than whether people actually use it and act on what’s in it.

That said, some characteristics help: easy to add suggestions (if it’s complicated, people won’t bother), visible to everyone (transparency builds buy-in), clear ownership and status (prevents things languishing in “maybe someday” limbo).

The mobile team used a simple Trello board: suggested improvements, planned for next sprint, in progress, completed. It took five minutes to set up and perfectly met their needs. No complex workflows, no elaborate tracking. Just enough structure to make things happen.

Scaling What Works

Growth considerations

Right, here’s where it gets interesting: how does kaizen change as your team grows from 5 people to 50?

At small size, everything’s informal. You don’t need process because everyone knows what everyone else is doing. Improvements happen organically through conversations. Retrospectives are relaxed discussions about what could be better.

This breaks somewhere between 15-25 people, depending on your setup. Suddenly, improvements in one team don’t propagate to others. Good practices emerge in pockets but don’t spread. What worked for the small group becomes chaotic at scale.

The wrong response is bureaucracy. Standardising everything, requiring proposals for improvements, creating improvement review committees. That kills kaizen faster than anything. Well, to be honest, it kills other things too. Like your soul.

The right response is creating structures that preserve autonomy while enabling learning across teams. Never over-do things.

Cross-team learning mechanisms: A cool idea: monthly “lessons learned” sessions. Each team would share one improvement they’d implemented, why they did it, and how it worked out. Other teams could adopt what seemed useful.

This isn’t mandatory or top-down—just an opportunity to learn from each other. Some improvements spread widely, others stayed team-specific. The key was making knowledge transfer easy without forcing standardisation.

Consistent principles, varied implementation: Instead of dictating specific practices, we established some quite obvious principles: “Every feature must be tested,” “Code should be reviewed before merging,” “Deployments should be automated.” How each team achieved those principles was up to them.

This let teams kaizen their own processes while maintaining baseline quality standards. One team used mob programming for code review, another used traditional PR reviews, a third did pair programming. All valid implementations of the same principle.

Platform teams that enable improvement: As teams scaled, it’s a good idea to create a platform team focused on building internal tools and infrastructure that make everyone more productive. This is kaizen at a different level. Improvements that affect multiple teams, like CI/CD pipelines, observability tooling, development environment setup automation.

The platform team’s roadmap come from other teams’ pain points. This creates a feedback loop: individual teams identify problems, platform team builds solutions that enable more improvements.

Maintaining quality

Here’s the tension: continuous improvement implies constant change. But constant change can destabilise things. How do you kaizen without breaking what already works?

Distinguish between experimental and proven improvements: When trying something new, treat it explicitly as an experiment with a defined evaluation period. “We’re trying this approach for three sprints, then we’ll assess whether it’s better than what we had before.”

This framing makes it safe to try things as everyone knows this isn’t permanent unless it proves valuable. It also prevents the “we’ve always done it this way” trap because the default is to periodically question whether current practices still serve you.

Time for a story. The team tried a new code review process where reviews were done live in pairing sessions instead of asynchronously. After three weeks, they evaluated: faster feedback, better knowledge sharing, but scheduling overhead became annoying. They kept live reviews for complex changes but went back to async for routine ones. That selective adoption was only possible because they’d treated it as an experiment from the start.

Improve incrementally, not radically: Small changes are less risky and easier to evaluate. Instead of “let’s completely redesign our sprint planning process,” try “let’s adjust how we estimate story points” and see if that helps. If it does, consider what else might improve. If it doesn’t, you’ve only changed one small thing.

I’ve been in a team that blow up their entire development process because they decided to adopt everything from a new methodology at once. Nobody could tell which changes were helpful and which were causing new problems because everything changed simultaneously. They eventually reverted to their old process, learned nothing, and became skeptical of all improvement.

Maintain backwards compatibility for shared practices: When changing something multiple teams depend on: infrastructure, tooling, shared services, do it gradually with migration paths. Let teams adopt improvements when it makes sense for them rather than forcing synchronised changes.

The platform team I mentioned earlier maintains both old and new versions of their deployment system during transitions. Teams could migrate when ready, which meant the new system got battle-tested before everyone depended on it. If problems emerges, they are caught early with limited blast radius.

Document current state before changing it: This sounds obvious but teams rarely do it. Before implementing an improvement, explicitly document how things work currently and why you’re changing them. Future you will thank past you when you’re trying to understand whether the change actually helped.

The SaaS team maintained a changelog of process improvements with before/after descriptions and rationale. Six months later, when they considered reverting a change that felt cumbersome, they could look back at why they’d implemented it. Turned out they’d forgotten the problems it solved.

Key Takeaways

Let me distil this into what you can actually apply:

• Build on solid technical foundations first: Kaizen is nearly impossible if your technical context creates constant friction. Prioritise improvements to codebase quality, tooling, and infrastructure as prerequisites for improving everything else.

• Psychological safety isn’t optional: People must feel safe suggesting improvements and believe their suggestions matter. This requires both welcoming ideas and actually implementing some of them. One without the other doesn’t work.

• Make improvement part of the work, not separate: Don’t create special “improvement time” that gets sacrificed under pressure. Build improvement directly into normal development workflow so it happens continuously.

• Focus on pain points, not perfection: Ask what’s most annoying about current practices and address that. Relieving genuine pain creates momentum for further improvement. Theoretical optimisation doesn’t.

• Measure outcomes, not activity: Track whether improvements actually make things better. Faster shipping, fewer bugs, happier team. Not just whether you’re doing improvement activities. Results matter, not the ritual.

• Start experiments explicitly as experiments: Frame changes as trials with defined evaluation periods. This makes it safe to try things and easy to assess whether they’re actually improvements.

• Preserve autonomy while enabling learning: As teams grow, create mechanisms for sharing what works without mandating standardisation. Consistent principles, varied implementation.

Final Thoughts

Kaizen isn’t a programme you implement or a methodology you follow. It’s a mindset: the work isn’t just the features you ship, it’s also improving how you ship them.

The teams that excel at this don’t have special frameworks or sophisticated tools. They’ve just created conditions where people naturally identify friction, suggest improvements, and actually implement them.

This takes time. You won’t transform overnight. But if you consistently chip away at pain points, build on solid technical foundations, and maintain an environment where improvement is normal and valued, you’ll look back in six months astonished at how much better things are.

Start with one thing that genuinely annoys your team. Fix it properly. Build from there. That’s kaizen.

Have questions or thoughts? Get in touch - I’d love to hear from you!