The silo is dead: Why every engineer now needs customer skills

You have probably sat in a planning meeting where an engineer shrugged off a feature request with "not my cup of tea" or "that's a product problem". The phrase sounds harmless. It costs millions. When technical staff treat customer insight as someone else's job, velocity dies in handoff queues, rework doubles and the gap between what you ship and what users need becomes a chasm that no amount of agile ceremony can close.

Grab, the Southeast Asian super-app that handles ride-hailing, food delivery and payments for hundreds of millions of users, decided that gap was no longer acceptable. The company now requires every engineer to develop customer-facing skills alongside their technical craft. The shift reflects a broader reckoning in software organisations: the functional silo, once a tidy way to organise expertise, has become the most expensive structure in the building.

What happened

Grab's leadership observed that engineers who understood only code were shipping features that solved theoretical problems rather than real friction. Product managers translated user pain into tickets, designers mocked up flows and engineers implemented the spec. By the time a feature reached production, it had passed through so many interpretive layers that the original customer need was unrecognisable. The company responded by embedding customer research, usability testing and support-ticket analysis into engineering workflows. Developers now spend time in user interviews, shadow customer-service agents and review behavioural analytics before they write a line of code.

The change is structural, not cosmetic. Engineers at Grab are assessed on their ability to articulate customer problems as clearly as they debug a stack trace. Sprint planning begins with user stories told by the people who will use the feature, not by a product owner reading from a backlog. When a bug surfaces, the engineer who fixes it also reads the support thread and, where possible, speaks to the affected user. The goal is to collapse the distance between the person who writes the software and the person who lives with it.

Why silos persist

Functional silos emerged because specialisation works. A payment engineer does not need to know how the recommendation algorithm ranks restaurants, and a front-end developer does not need to understand database indexing strategies. Division of labour lets people go deep. The trouble starts when depth becomes isolation. Engineers who never hear a customer complain begin to optimise for elegance rather than outcome. They refactor code that already works, bikeshed variable names and argue over architecture while users churn because the onboarding flow takes eleven taps.

Silos also protect egos. If you only own the implementation, you can blame poor results on bad requirements. If the feature fails, it was product's fault for writing a vague ticket or design's fault for ignoring technical constraints. Accountability diffuses across handoffs, and no one is responsible for whether the thing actually solves the problem. Grab's model makes that dodge impossible. When the engineer has sat in the user interview and seen the frustration firsthand, "not my cup of tea" stops being an option.

What this means for L&D

Learning and development teams that still run separate tracks for technical skills and soft skills are designing for a world that no longer exists. The engineer who can write performant Rust but cannot explain why latency matters to a driver waiting for a ride is only half-trained. Organisations need curricula that treat customer empathy, systems thinking and communication as core competencies, not electives for people who want to move into management.

That means embedding customer exposure into onboarding. New engineers should spend their first week not in a codebase tour but in support queues, user research sessions and product analytics dashboards. It means pairing technical workshops with field visits. Teach someone to optimise a database query, then show them the warehouse worker whose scanner times out because the query is slow. It means rewarding engineers who can translate a customer complaint into a root-cause hypothesis as readily as they can write a unit test.

The silo is dead because the cost of maintaining it – in rework, in churn, in features that miss the mark – now exceeds the efficiency it once provided. Grab's approach is a signal that the next generation of engineering excellence will be measured not by lines of code but by how closely the code aligns with the life it is meant to improve. Learning leaders who recognise that shift early will build teams that ship less and solve more.

Sources:

• CIO