Why do engineers (and other product team members) hesitate to talk to customers—and what can leaders, Scrum Masters, and coaches do about it?
In this conversation, we unpack a common pattern that shows up when organizations move from component teams to feature teams: people still think their job is “coding efficiently,” not “solving customer problems end-to-end.” That mismatch drives reluctance and pushback.
We explore the real reasons behind the hesitation—efficiency thinking (“let specialists do customer contact”), insecurity and fear of being judged, concern about losing technical growth time, avoidance of “politics” and “meetings,” and a narrow sense of responsibility (“my world is the code”). We also discuss why this is not just cultural, even though it can look different across countries.
From a LeSS perspective, the shift to feature teams changes the job fundamentally: the goal is not producing code, but creating outcomes by learning fast through feedback. “Talking to the customer” is defined broadly as building tight feedback loops—sometimes through direct conversations, sometimes through observation and real-world usage, and sometimes through engineering-driven validation (examples include autonomous driving and internet banking).
Key coaching handles include: making the change explicit (the old role disappears), creating shared context with whole-system education (instead of role-based training alone), management setting clear expectations (“it’s not optional”), and letting teams discuss and self-correct while improving the quality of collaboration and meetings rather than avoiding them. Finally, we challenge a common career myth: engaging with customers improves engineering quality by strengthening domain understanding and creating more coherent code.
