In my past life before data architecture, I used to be a manufacturing engineer in the automotive industry. At the time, the popular approach was Lean Manufacturing and the Toyota Production System, driven by Toyota’s massive success in the United States.
Lean was—and still is—about increasing value to the customer by reducing and eliminating work that doesn’t add meaningful value. This spawned many tools and practices to surface inefficient habits. One that stayed with me was the concept of “going to gemba.” In Japanese, gemba means “the real place” where work actually happens. In practice, this meant that managers and engineers left the office and went to the shop floor. There they simply observed: stood and watched the work happening, and asked questions of the line operators in a curious and respectful manner. No decisions were made on the floor. Leadership took what they had learned back to the office and used those lessons to shape operational plans.
This concept came to mind as I read this post on LinkedIn:
From the Shop Floor to the Backlog
It’s striking how these practices reappear across different environments. In data and software engineering, many teams follow Scrum, which is based in part on Lean principles. Regarding “going to gemba,” two Scrum practices stand out to me.
User Stories: Keeping the Customer’s Voice
The first is the crafting of user stories. Many technical design documents dive deep into specific technical requirements but often overlook the actual value delivered to the consumer. User stories follow a specific template to keep the voice of the customer present:
As a <person who should benefit>, I want to <summary of the action taken>, so that <description of the benefit realized>.
After this comes a more technical description of the tasks that fulfill the requirement. In Scrum, we call this the “definition of done.”
The Product Owner as Gemba Proxy
The second practice is a team member role: the product owner. The product owner is the subject-matter expert who coordinates closely with the business users of the software. In the best setups, the product owner has already done their own version of going to gemba—sitting with the people who will use the system, watching how they actually work, and bringing that understanding back to the team. They prioritize the backlog by real business value rather than technical convenience, clarify the intent behind each story, answer the team’s questions about what “done” really looks like, and decide when a story has delivered the benefit it promised. That single, consistent voice reduces the chaos of conflicting requests from different stakeholders and keeps the team focused on outcomes instead of activity.
When the Message Gets Distorted
There is one danger, though, in funneling all customer connection through the product owner: it creates a communications bottleneck. This both slows responsiveness and distorts the message. The problem is especially acute with remote and distributed teams. I experienced this firsthand the first time I worked with an offshore development team. While online videoconferencing tools like Zoom existed, they had not yet achieved widespread use—this was several years before COVID. Between the limits of telephone conferencing and the language barrier, a growing gap emerged between what the product team wanted and what the developers actually delivered.
I learned a valuable lesson from that project: a remote team will always do what you tell them, but they won’t always do what you want.
It also reinforced a lesson that Scrum teaches: every member of a Scrum team should be cross-functionally proficient in the tasks the team performs. Specialization is valuable, but others need to be able to step in when circumstances require it.
Digging Deeper with the 5 Whys
That experience brought to mind another Lean tool that digs past surface symptoms to the real cause: the 5 Whys. The 5 Whys is a problem-solving method in which you keep asking “why” until you reach the root cause of the problem. In most cases, you arrive at the root cause by the fourth or fifth “why.”
I remember one incident. An account manager on the sales team asked me why one particular SKU didn’t appear on a dashboard. The investigation followed the structure of the 5 Whys:
- Why didn’t the SKU appear on the dashboard?
It was a child SKU to a pallet SKU that originated from a demand-plan extract. - Why didn’t the pallet SKU appear on the demand-plan extract?
The pallet SKU wasn’t available as a dropdown item in the demand-planning application. - Why wasn’t the SKU included in the dropdown list?
There wasn’t an open sales order in the demand-planning application. - Why wasn’t there an open sales order in the demand-planning application?
It wasn’t uploaded from the main ERP system. - Why wasn’t it uploaded from the main ERP system?
The order wasn’t entered correctly by the data-entry operator.
The root cause was a simple data-entry mistake, but by the time it surfaced as a missing SKU on a dashboard, it had already traveled through several systems and several teams. Each layer had done exactly what it was told to do with the data it received. The gap was not in the code or the pipelines; it was in the shared understanding of how the work actually happened upstream.
Closing the Distance
In technical roles, we spend most of our time one or more steps removed from the real work. We see tickets, requirements, schemas, and dashboards. Effective communication means closing that distance—asking the next “why,” watching the process that feeds the system, and confirming that what we built matches what the people doing the work actually need. Going to the gemba—whether that is the shop floor, the analyst’s desk, or the business user’s screen—is still the most reliable way to keep the message from getting distorted on its way from intent to outcome.