Japanese management practices for better tech teams: 5 practical examples

Your team has discussed the same release problem twice. Customers still need help producing a report, work keeps waiting for review and another improvement action has disappeared into meeting notes. You need a way to investigate what is happening and make a change that can be checked.

Several management practices developed or popularised in Japan offer useful approaches. This guide focuses on five: kaizen, genchi genbutsu, nemawashi, hoshin kanri and Kanban. Each addresses a different question about learning, decisions or the flow of work.

These are specific practices associated with particular organisations and management traditions, including Toyota. They do not describe one uniform Japanese mindset. The examples below show ways a tech team could adapt them; adopting the names alone does not establish a new management system.

Choose the practice that fits the problem

Kaizen: what small change could make the work better, and how will you check it?
Genchi genbutsu: what can you learn by observing the actual situation?
Nemawashi: whose knowledge and concerns should shape the proposal before a decision?
Hoshin kanri: how should strategic goals, resources and team plans inform one another?
Kanban: where is work waiting, and what should the team finish or unblock next?

Throughout the guide, imagine a fictional software team building a customer-reporting product. Customers use it to prepare weekly operational reports. The situations, trial policies and proposed measures are teaching examples, not results from Georgia’s work or claims about Toyota.

Five practices, with examples you can use

Kaizen: test an improvement and follow it through

Purpose: Turn a recurring frustration into a change you can evaluate.

Kaizen is commonly explained as continuous improvement. The Lean Enterprise Institute’s kaizen guide describes improvement as a continuing process involving the people doing the work. A list of suggestions is a starting point; learning comes from trying a change and checking what happened.

Plan: inspect recent handovers and agree what problem the new field should address.
Do: trial the field within the existing release process.
Check: review missing information, clarification messages and the effort needed to maintain it.
Act: keep, adjust or remove the field based on what was learned.

This is a simple application of Plan, Do, Check, Act, often shortened to PDCA. Two releases provide early feedback, not proof that the change will work in every situation. If it helps, update the shared working agreement and check that the improvement lasts.

Question to take to your team: which recurring problem could you investigate with one small, reversible change?

Genchi genbutsu: understand the work at its source

Purpose: Improve the problem definition before committing to a solution.

Genchi genbutsu is associated with Toyota’s practice of checking conditions through direct observation. The Lean Enterprise Institute explanation stresses understanding the actual situation rather than relying entirely on reports from elsewhere.

The new question is: “Can customers identify the period covered by a report before exporting it?” The team can now investigate clearer date labels and time-zone information alongside other options.

For remote teams, direct observation can mean an agreed screen-sharing session with a customer or colleague. Ask them to explain what they are doing, note workarounds and separate observations from your interpretation. A few sessions can reveal questions worth testing; they do not establish how common the problem is.

Question to take to your team: what would you want to observe before approving the proposed feature?

Nemawashi: let consultation change the proposal

Purpose: Surface operational knowledge and disagreement before the decision.

Nemawashi concerns preparing the ground for a decision through discussion and information sharing. Toyota UK’s explanation describes seeking people’s views before formal changes. For a tech team, the useful lesson is to consult while the proposal can still change.

State the problem, the options and the decision needed.
Invite input from people affected by the work, including those who maintain it.
Record concerns, changes and unresolved objections in a shared note.
Name the decision owner and a proportionate date for deciding.

In a distributed team, offer an asynchronous way to contribute and include colleagues outside the most convenient time zone. Consultation should reveal disagreement, not turn an informal conversation into pressure to agree. A time-sensitive incident will need a different consultation window from a planned product change.

Question to take to your team: who will inherit the consequences of this decision but has not yet been heard?

Hoshin kanri: connect strategy with achievable work

Purpose: Make priorities and resource constraints part of the same discussion.

Hoshin kanri, often called strategy or policy deployment, connects organisational goals with coordinated plans and review. The Lean Enterprise Institute description includes dialogue between leadership and teams about objectives, available resources and what can realistically be achieved. That exchange is often called catchball.

Keep a visible connection between the desired outcome, the work chosen, the people responsible and the evidence to review. Here, useful evidence could include the proportion of new customers producing a usable first report, the time needed and the support effort involved. Agree definitions and a baseline before setting a numerical target.

An AI summary feature or a new chart should be assessed against the same goal and available capacity. Leadership must be prepared to change the plan when evidence or constraints change.

Objectives and Key Results, or OKRs, are a separate goal-setting approach. Using them does not by itself mean an organisation has implemented hoshin kanri. This example borrows a practical lesson about two-way alignment; it is not a complete implementation guide.

Question to take to your team: which commitment needs to change if the agreed goal is to remain achievable?

Kanban: manage the flow, including the waiting

Purpose: Use the workflow to decide what to finish, unblock or start.

Kanban has roots in production systems and has also developed into an approach for knowledge work. The May 2025 Kanban Guide covers a shared workflow, active management and improvement. A board represents the workflow; the agreements and decisions around it are essential.

Define when work starts and finishes, how work in progress is controlled and what permits an item to move. Count blocked items as started but unfinished work. Agree how genuine urgent exceptions are handled so that they remain visible.

Work in progress: items started but not finished.
Throughput: items finished in a defined period.
Work item age: elapsed time since an unfinished item started.
Cycle time: elapsed time from an item’s start to its finish.

These measures describe flow. In the reporting example, pair them with checks that the fixes resolve customers’ problems; a high completion count alone does not establish that benefit.

Question to take to your team: which waiting item needs attention before another item is started?

Keep respect for people in the improvement

Toyota’s current Toyota Way 2020 includes respect for people, thorough observation and continued improvement. Its production-system explanation also describes making work easier for the people doing it. Those elements belong alongside discussions of efficiency.

My recommendation for tech teams is to ask who benefits from a change and who takes on the extra work. A shorter delivery time is less useful if support inherits hours of manual repair or one specialist becomes the permanent bottleneck.

Make time for experiments within the team’s real capacity.
Invite junior colleagues and people closest to customer problems to contribute.
Allow people to report a failed trial without treating it as a personal failure.
Use any time released deliberately, including for quality, learning or reducing repeated overload.

The aim is to improve how the work happens. Do not use continuous improvement as a standing demand for everybody to work faster with fewer resources.

A one-page improvement brief

Choose one problem rather than launching all five practices at once. Use these prompts in an existing team discussion or shared note.

Situation: what is happening, for whom and in what context?
Evidence: what has been observed, and what remains an assumption?
Proposed change: what small part of the work will change?
People: whose input, permission or time is needed?
Check: what would indicate improvement, and what extra effort or harm will you watch for?
Review: who will review the trial, when, and what would lead to keeping, changing or stopping it?

For the fictional release handover, the brief would name the missing support information, the trial field, its owner and a review after two releases. It would check both fewer clarification requests and the effort of keeping the field current. The trial has not yet proved a benefit.

Choose one question for your next team discussion

Start with the issue your team can describe clearly. Observe a customer task, test one handover change or bring an overlooked colleague into a decision. Record what you expect to learn and make a date to review it.

You should leave the discussion with a concrete next action, someone responsible and a way to assess the result. That is a useful first step towards improving the work.

Sources and further reading

Updated 15 October 2026. Definitions were checked against the sources below, including Toyota’s current published philosophy and the May 2025 Kanban Guide. All software-team scenarios, trial policies and the improvement brief are original editorial teaching examples. They are not claims of measured results or a complete implementation of the source organisations’ systems.