Photo by Emma Gossett

Literally translating as “to go around the roots”, Nemawashi (根回し) historically described the farming activity of transplanting a tree from one location to another. Before transplanting, the tree’s roots are dug around and soil from the new location is introduced. This allows the tree to acclimate to its new environment prior to being moved, increasing its chances of survival.

In modern times, Nemawashi describes a process of laying the foundation for a proposal by first seeking consensus inside and outside the team informally - allowing others to give their opinions and contribute - before formally presenting the proposal. This increases the probability of the proposal being accepted and ultimately executed upon.

Although widespread in Japanese business, Nemawashi is perhaps most recognisable outside Japan as one of the 13 pillars of the Toyota Production System (from which Lean was partly derived).

Nemawashi and software development

Conversation about Nemawashi typically centres around the application of Lean to classical business activities and manufacturing. However, it’s also a technique that software development teams can make effective use of.

Getting buy-in

Consider a significant architectural change to an existing software system e.g. moving from a monolithic architecture to a microservices-based one.

An architect can dictate a design to the development team, handing it off to be implemented according to her vision or she can practice Nemawashi.

Nemawashi does not mean the architecture will be compromised as a result of design by committee, quite the opposite. By allowing the development team to examine the proposed new architecture in detail before architecture sign-off and provide their inputs and insights, buy-in amongst team members will be increased.

On a software development project of any complexity having a development team operating beyond the role of reluctant implementor can be a critical factor in maximising the probability of success.

Building consensus

Proposals may be organisationally or politically sensitive for a variety of reasons.

A proposal to move from manual infrastructure management on a project to Infrastructure as Code (IaC) might be viewed with a mix of suspicion, concern, and derision by an existing infrastructure team. Although there may be an element of self-preservation on the part of the infrastructure team, their views should not be dismissed as entirely unfounded.

Here, Nemawashi can be leveraged to build consensus with the infrastructure team - acclimating them to the proposal through positive engagement, assuaging their concerns, being open to feedback, and so on.

The goal

The goal is to see your proposal succeed.

Nemawashi provides a method for achieving this, recognising that by building consensus and offering inclusivity the art of persuasion is made easier.

Nemawashi is somewhat orthogonal to the model of traditional software team ‘leadership’, where forcefulness is viewed as a positive attribute and celebrated. (There can be little doubt this is partly because the software development industry is wholly under-representative of society.)

As development teams diversify - bringing new perspectives, approaches, and viewpoints - methods such as Nemawashi may become more prevalent and, I believe, recognised as a key attribute of high-performance software development teams.