“A Software Engineer must know how to solve problems.” True, but vague. Concretely, which problems are we talking about? The spontaneous, almost reflexive answer always points to the same ones: those discovered in production, reported by customers, the worst thing that can happen, or detected through monitoring. Yet these visible incidents are only the tip of the iceberg. Long before anything ships to production, a host of organizational and technical problems slow teams down day after day, without ever triggering a single alert. The Gemba Walk, a practice born from Lean, is precisely the tool that makes them visible.
The invisible problems, the ones that truly cost
Shipping to production is already an end in itself. Even before getting there, the journey is strewn with obstacles that slow down value creation:
- a User Story poorly specified from the start, forcing back-and-forth between the Product Owner and one or more Software Engineers, sometimes all the way to the customer;
- piles of Pull Requests stacking up waiting for review;
- a degraded feedback loop caused by a slow or temperamental local environment.
All these frictions share one thing in common: they generate Muda. The term is borrowed from Lean and designates the waste of time and resources produced during the production process. “Waste” should be understood in the broad sense: anything not necessary to value creation. A developer waiting ten minutes for tests to run locally, a feature rewritten three times because the need was fuzzy, a review sitting idle for two days: all of it is time taken away from what really matters.
The danger of this waste is that it is diffuse. It causes no incident, it wakes no one up at night. It settles silently into the daily life of teams, and that is precisely what makes it so hard to eradicate. So how do we detect these problems in order to address them?
The Gemba Walk: going to see where the work happens
The Gemba Walk consists of going to where value is created to observe the actual work, not the work as we imagine it. Gemba (現場) means “the real place” in Japanese, the spot where things actually happen. The founding idea is simple: you don’t understand a problem from a meeting room or a dashboard, you understand it by going on the ground, alongside those doing the work.
The goal is continuous improvement: accompanying and observing colleagues on the ground in order to identify the problems they face which, directly or indirectly, generate Muda.
”But they’re problem solvers, right?”
The objection comes naturally: these are problems engineers are supposed to detect and solve on their own. Didn’t we hire problem solvers precisely for that? That is indeed the ultimate goal, but it is rarely reached right away, for several reasons:
- A lack of mastery or expertise to identify and solve the problem at hand. You can’t fix what you can’t name.
- Each person’s seniority, maturity, and experience come into play: the same obstacle will be perceived as a problem by some and considered perfectly normal by others.
- It’s all a matter of habit. A problem encountered too frequently eventually turns into a triviality, then into an inevitability. People stop seeing it as a flaw to fix; it becomes the scenery.
This is exactly where the value of an outside perspective lies. The Lead’s role is not to point out incompetence, but to bring back into the light what habit has made invisible.
How a Gemba Walk unfolds
The practice comes down to a few simple principles, but the order and the mindset matter as much as the steps.
Setting a supportive frame
Nothing works without a frame of trust. The Gemba Walk is neither an inspection nor a disguised evaluation. Its ultimate goal is to put colleagues in a position to succeed and to develop, across the team, a genuine problem-solving culture. If the exercise is experienced as surveillance, it produces the opposite of the intended effect: difficulties get hidden instead of exposed.
Observing alongside the colleague
The Gemba Walk is led by a Senior or a Team Lead, who teams up with a member of their team and observes how they work. Pair programming or mob programming sessions are excellent levers for this observation: they naturally place the Lead next to the colleague, in the real flow of work.
Identifying problems in silence
At first, the Lead’s role is to identify, in silence, the problems that prevent the colleague from moving faster or that generate frustration for them. Silence here is a deliberate discipline: you observe without correcting, without commenting, without taking over. The goal is to capture the work as it actually unfolds, not as it reconfigures itself the moment a superior steps in.
Debriefing and kicking off the resolution
Observation only has value if it leads to action. Once the session is over, a debrief makes it possible to discuss the problems observed. This is the starting point of a resolution process, for instance a PDCA cycle (Plan-Do-Check-Act): you formulate a hypothesis, you experiment with one or more solutions, you check the results, and, if the solution works, you spread the knowledge to the rest of the team.
It’s this last step that turns a simple observation into continuous improvement: a problem solved for one colleague and shared with the others becomes a gain for the whole organization.
Conclusion
The Gemba Walk rests on a simple conviction: the most costly problems are not always the most spectacular. Production incidents grab attention, but it’s often the daily frictions (silent, normalized, invisible from a dashboard) that erode a team’s productivity the most. Going on the ground, observing the actual work, and listening to those who do it remains the most reliable way to flush them out.
For a Team Lead, it’s also a shift in posture: you no longer steer improvement from the metrics, you root it in the daily life of the teams. Every Muda eliminated, every solution shared takes you one step further up the climb of continuous improvement.