Your client is in Chicago. The platform team is in São Paulo. The integration developer is in Bengaluru. The architect is in Toronto. This is what a modern ServiceNow program looks like, and it is only getting more common.
We pour energy into technical quality. Clean Flow Designer, an accurate CMDB, CSDM done right, ATF coverage, a tidy data model. But on a distributed ServiceNow project, the most expensive defects are rarely in the code. They are in a requirement that everyone "agreed" to and nobody pictured the same way.
You know the scene. A story goes through refinement. The developer nods, says "yes, clear," and the team moves on. Three weeks later, UAT shows the catalog item behaves nothing like the business analyst intended. Nobody lied. The "yes" meant "I will work it out." The gap was invisible until it was expensive.
That gap is not a personality flaw and it is not a skill gap. It is a predictable cross-cultural communication mismatch. Here is the data on what it costs, the framework that explains it, and a fix you can put into your delivery process this sprint.
This is a measurable cost, not a soft skill
Poor communication costs US businesses an estimated $1.2 trillion a year, about $12,506 per employee, according to Grammarly and The Harris Poll. In a separate Economist Intelligence Unit survey, 44% of respondents said miscommunication had directly caused a project to be delayed or to fail.
On a ServiceNow program, that abstract number has very concrete faces. A module half-built to the wrong spec. A go-live slipped a sprint because a "done" story was not done. A CSDM model that has to be reworked because the offshore team and the onshore architect meant different things by "application service." None of it is a coding problem. All of it is a communication problem.
Why it happens: the Culture Map
The clearest explanation comes from Erin Meyer's "The Culture Map" (2014), which plots cultures along eight scales. ServiceNow delivery teams tend to straddle the widest gaps on the scales that matter most for software work.
Look at where a typical US client sits versus a typical LATAM or India based delivery team.
↳ Communicating: the US is the most low-context culture in the world. Words are taken at face value. Brazil, India, and China are higher-context, where meaning lives in tone, relationship, and what is left unsaid. ↳ Trusting: the US is task-based. Trust comes from reliable delivery. Brazil and India are relationship-based, where trust is built person to person first. ↳ Scheduling: the US runs on linear time, where the date is a commitment. Many delivery cultures run on more flexible time, where the date is a strong intention. ↳ Evaluating: how direct or indirect negative feedback is given varies widely, and it is where code review and design review quietly go wrong.
When a low-context manager and a high-context developer leave the same refinement call, they often leave with two different understandings, and neither knows it.
How it actually shows up on a ServiceNow project
This is where the theory meets your backlog. The same mismatch appears in five predictable places.
Requirements and refinement. This is the Yes-Wall. A quiet nod in refinement reads to a US lead as full understanding. To a developer from a high-context, hierarchical culture, staying quiet and saying yes is the respectful default, even when the story is unclear. The misunderstanding is not discovered until the demo.
Design and architecture decisions. A junior developer spots a problem with a proposed CSDM or data model approach, but the architect proposed it, so they do not push back. The flaw ships into the foundation, and foundations are the most expensive thing to rework in ServiceNow.
Code review and config feedback. A US lead writes "this is wrong, redo it." To them that is normal, efficient, and not personal. To an indirect-feedback culture it can land as a public insult. In reverse, a developer says "maybe we could consider another approach," which is the strongest objection they will voice, and the US lead hears a casual idea and moves on.
Standups and status. "On track" that is not on track, because naming a blocker feels like admitting failure. By the time it surfaces, the sprint is gone.
Estimates and go-live dates. Linear time versus flexible time. One side reads the committed date as contractual. The other reads it as aspirational. Both are acting in good faith.
The fix: a closed-loop playback, built into the workflow
Across the research, the conclusion is consistent. Cultural awareness training on its own does not fix this. The fix is structural. Meyer puts it plainly: "Multicultural teams need low-context processes."
The most reliable structure is closed-loop communication, the read-back rule that aviation and medicine have used for decades. The receiver repeats the message back before anyone moves. Here is what that looks like translated into ServiceNow delivery.
↳ Requirements playback. Before a story moves to In Progress, the developer restates the goal, the scope, and the acceptance criteria in their own words, plus one thing they will deliberately not do. It goes in the story, not in a private chat. ↳ Decisions get a written record. Architecture and CSDM decisions get a short note: what we decided, what we rejected, and why. Searchable, not living in one person's head. ↳ Demo-driven confirmation. Show working config at the end of every sprint. A demo is a playback the whole team can see and correct. ↳ Rotate the recap. A different person summarizes the agreed next steps each ceremony, so understanding is not assumed from the loudest voice in the room. ↳ Reward the early blocker. The Yes-Wall is built on the fear of looking incapable. A team that openly thanks the person who raises a risk on day two takes the wall down.
None of this asks anyone to memorize which culture is direct and which is indirect. It replaces a silent "yes" with an artifact the whole team can check.
One honest caveat
Cultural maps are useful and also easy to abuse. Reducing a teammate to a national average is exactly the wrong move, and serious researchers warn about it. Meyer says it best: "Culture sets a range, and within that range each individual makes a choice." Use the map as a hypothesis about the person, never as a label. The blunt, punctual Brazilian developer exists. So does the American who hates being rushed. The map tells you where to look, not what you will find.
The takeaway for ServiceNow teams
The platform rewards teams that hand off cleanly, catch defects early, and hit go-live. On a global ServiceNow program, cross-cultural communication is not an HR nicety. It is delivery infrastructure, as real as your branching strategy or your test coverage. Map the differences, build the playback into your process, and most of the rework simply stops happening.
A question for the community: where on your ServiceNow projects has a "yes" turned out to be a "maybe," and what did you change to catch it earlier? I would like to hear how other teams handle this.
Written by Guilherme Batista da Silva, founder of GBS, ServiceNow Rising Star 2024 and 2025, and organizer of the ServiceNow Developer Meetup Brazil.
Sources
- Grammarly and The Harris Poll. The State of Business Communication. 2022. US businesses lose an estimated $1.2 trillion a year to poor communication, about $12,506 per employee. https://www.businesswire.com/news/home/20220125005525/en/Grammarly-and-Harris-Poll-Research-Estimate...
- Economist Intelligence Unit. Communication Barriers in the Modern Workplace. 2018. 44% of respondents said miscommunication caused a project delay or failure. https://www.prnewswire.com/news-releases/miscommunications-at-work-impact-the-bottom-line-study-find...
- Meyer, Erin. The Culture Map: Breaking Through the Invisible Boundaries of Global Business. PublicAffairs, 2014.
- Grand View Research. Latin America IT Services Outsourcing Market Size & Outlook, 2030. Market context for nearshore ServiceNow delivery. https://www.grandviewresearch.com/horizon/outlook/it-services-outsourcing-market/latin-america
