Great products are a team effort, echoing the Japanese concept of Nemawashi.
Translated as “going around the roots,” the term — borrowed from preparing a tree for transplant — has found its place in the tech world, signifying the sharing of information and involvement of all employees in the decision-making process.
This practice is more than a communication strategy; it embodies a deeper philosophy of decision-making and acts as a mechanism for cultivating harmony within an organization. By seeking input from relevant stakeholders, companies can navigate potential challenges and ensure widespread support for proposed initiatives.
Nemawashi’s influence is not limited to one country. It shapes decision-making globally — yet mantras are not one size fits all. Success looks different from company to company, and behind each lies a distinctive mantra uniting its team and propelling impactful engineering and development.
In a recent discussion with findhelp, Eventus Solutions Group and InspiringApps, Built In tapped into the unique approaches that drive each team toward success.
Findhelp connects people in need with the social care programs that serve them at findhelp.org.
Does your team or engineering org have a central ethos or mantra that drives how you develop?
Our mantra is “Pick Up Sticks.”
In a game of Pick-Up Sticks, the goal is to pick up each stick without disturbing any others. This is how we deliver high quality while keeping customers front and center.
We complete the quick and easy tasks first —picking up the sticks on top — while delivering on customer commitments, all without disturbing the other areas of code and clearing the way to safely tackle the next item. Just like when you near the end of a game of Pick-Up Sticks, tangled areas of code that were once deeply buried now lie clearly on the surface.
Simplistic policies such as requiring all touched code to have a given level of code coverage forces your developers to pick up all the red sticks first. Perhaps some of those red sticks are deeply buried and removing them first would disturb the entire pile. Each stick removed makes the code slightly easier to change. Since keeping customer commitments and fixing bugs requires changing the software, we can say that the definition of quality in software is that it is easy to change.
The trick is getting all those small changes aligned department wide and empowering your people to make them.
How do you put that ethos into practice? Share an example of a project or product that embodies that theme.
We began the modularity initiative after recognizing the need for deeper alignment in our existing code. I began building consensus through a request for comments followed by an architectural decision record. The concept of Nemawashi was very useful during this process.
One of our engineering principles is “refactor along the way.” Our engineers do so by making targeted tactical changes with every customer-related item while being sensitive to the business needs and the timescale at hand.
Like all software organizations, we have some legacy code. However, unlike many organizations, every developer knows our target modular structure and is empowered to make manageable changes that will get us to our target architecture on a reasonable timeframe. We have clear, collaboratively developed standards that guide us as we pick up sticks.
As engineering teams imagine possibilities for their culture, how can they ensure that the shared vision is inclusive, inventive and future-proof?
At findhelp, we decide where we are going through a collaborative process where all the engineer stakeholders are empowered to participate through RFCs to solicit early feedback, which eventually becomes ADRs that formalize and keep a historical record of those decisions.
Will Larson writes in his blog about technical vectors. Imagine four pull requests each lying on the unit circle since they all are of the same level of effort, but pointing in different directions due to a lack of architectural alignment. By placing them end-to-end, the total architectural movement was small. Without a shared understanding of where an organization is going, that's the best that can be done despite valiant individual efforts. When there is broad architectural alignment, the same level of individual effort produces a much larger architectural movement.
“When there is broad architectural alignment, the same level of individual effort
produces a much larger architectural movement.”
For example, we have decided to always align our work toward a target software modular architecture. A modular architecture is one in which dependence between internal components is limited to minimize coupling which makes our code easier to change.
Eventus Solutions Group helps its clients optimize how they engage with their customers in contact centers and digital channels.
Does your team or engineering org have a central ethos or mantra that drives how you develop?
Eventus' mantra for all of our projects is “Day 2 First.”
EVENTUS' APPROACH MANIFESTS ITSELF IN 3 WAYS
- Designing its software to make it easy to debug. You cannot guarantee bug-free code or that requirements were captured perfectly, but you can design in a way that allows issues to be easily and quickly isolated and resolved.
- Making maintenance a priority. Ensuring its design approach optimizes the day-to-day maintenance both in terms of how it is performed and how it’s accessed and by which groups. Eventus works hard to ensure IT is not required for common business-driven updates.
- Design for expansion. Eventus designs to accommodate expanded functions in the future. Sometimes this means designs that have components that clients don’t specifically request are included as part of its best practices around expanded capability in the future.
This became our mantra for several reasons. The first is that our company focuses on operations in addition to development. That operational mindset drives our team in this direction. The second is that we saw many situations where we were brought in to “clean up” other providers' work, and it became clear that “Day 2 First” is very effective.
How do you put that ethos into practice? Share an example of a project or product that embodies that theme.
There are three primary ways we put this mantra into practice.
The first way is by understanding both current and future goals for our clients. The first step is to focus our engagements on not just what clients need immediately, but their future goals, be it acquisitions, customer relationship management system enhancements or product line expansions.
The second way is by staying current on client and industry trends. We bring industry expertise and trends analysis into all of our engagements — conversational interactive voice response, multichannel, “Bring Your Own Telephony” and AI-driven automation.
The third way is by creating an overall architecture that leverages the appropriate design patterns. We keep a large library of design and service templates that are modified with industry trends and based on client needs, and we’re able to adapt these to our clients’ needs and provide them, in most cases, with scalability and supportability built in.
At a recent project at a large financial services company, we were able to create reusable modules and services that replaced over 100K lines of code with a solution with under 20K lines of code. This approach was quicker to develop but also consolidated operations and maintenance support from a team of six to eight people to a team of four.
As engineering teams imagine possibilities for their culture, how can they ensure that the shared vision is inclusive, inventive and future-proof?
Our “Day 2 First” approach requires constant reimagining. We structure our organization to include both upward and downward communication from our team members, as well as being self-reflective in our internal project reviews. Being our own biggest critic and involving the entire team in those discussions creates an environment that rewards “breaking glass.”
Trends change, and while some basic principles remain constant, many of our current mantra design principles have changed over the past five years, like the need to accommodate AI support and multi-channel integration with CRM, to name a couple. Nothing is future-proof, but staying ahead of trends and embodying a culture of 360-degree project evaluation has created a unique design ethic — one where we measure ourselves against not just the client requirements but also whether we delivered a solution that was ready for Day 2, Year 2 and beyond.
InspiringApps is an award-winning company that develops mobile apps and digital products that inspire how people live, work and play.
Does your team or engineering org have a central ethos or mantra that drives how you develop?
Let’s explore mantra and ethos separately.
Our mantra in recent years has been “Finish Line, Every Time.” We cite it as a guarantee in our proposals. Sadly, it has been differentiating. I say “sadly” because I’m surprised by the number of clients who come to InspiringApps after working with a team that hit a wall. Either the team didn’t have the skills to finish or underestimated the effort involved and couldn’t afford to finish. Our team knows that 70, 80 or 90 percent is not enough. At InspiringApps, we finish every project we start.
Our ethos is less overtly stated, but our team is very good about asking “why.” We pause to ask our clients and each other because building the right thing is so much better than building the wrong thing quickly.
“Building the right thing is so much better than building the wrong thing quickly.”
The seed of both was planted during over a decade of my experience working as an independent developer before founding InspiringApps and growing our team. Now that team has embraced those ideas, and they have become enduring characteristics of our culture.
How do you put that ethos into practice? Share an example of a project or product that embodies that theme.
Putting ethos into practice happens so routinely it is hard to showcase a particular example. Instead, I’ll share a story of our oldest client, one I’ve worked with for over 20 years, predating InspiringApps, when I was an independent software developer.
Scott described the value of my curiosity to his business in a way I hadn’t recognized in myself and have not forgotten since. Scott said, “If I ask you to bring me a rock, you don’t just bring me a rock. You’d ask me why I need it. Are we holding a stack of papers in place? Do you want to prop a door open? Do you want to break a window? Might a brick be a better solution?”
I see so many people in our industry who will retrieve a rock without question. I’m proud to have built a team of people whose curiosity leads to better products.
As engineering teams imagine possibilities for their culture, how can they ensure that the shared vision is inclusive, inventive and future-proof?
Finishing what we start knows no age, gender or ethnicity. We’re all rewarded with the satisfaction of shipping something and seeing it in the hands of users. Asking “why” requires more nurturing. Not everyone has the same level of comfort when it comes to speaking up. Striving to design and build the right thing means we look critically at requirements — not to be difficult but in search of the best product and the best user experience.
We lean on our individual skills and experience and our team’s collective institutional knowledge that comes from designing and building hundreds of web and mobile apps. A client may ask us to do X, but we consider Y and Z because we’ve done something similar for other projects.
My responsibility, and that of the rest of our team, is to encourage everyone to speak up. To remind them their input matters. And that a product shaped by diverse perspectives is bound to be more successful.
