DEV Community: Nurdan Güngör

Global Teams Don’t Struggle With Time Zones. They Struggle With Context

Nurdan Güngör — Mon, 25 May 2026 12:52:07 +0000

Remote work is no longer an alternative model in tech. Especially in SaaS, consulting, and product teams, distributed work has become the default operating model. Today, a consultant in Türkiye, a product manager in London, a developer in India, and a client team in the US can all be part of the same operation simultaneously.

From the outside, this structure is usually described in terms of speed, flexibility, and access to global talent. But in practice, the hardest part of global collaboration is rarely the technical complexity itself.

The real challenge is that people are not operating in the same operational context.

In distributed teams, people do not share the same sense of urgency, the same risk perception, or even the same communication norms. Sometimes, they do not even share the same definition of "done." After a while, you start realising that distributed work is largely a coordination problem.

Time Zones Don’t Just Create Time Differences

Time zones are usually treated as a scheduling problem. But at a certain scale, they directly shape operational structure.

You feel this most clearly during release cycles, incident management, or cross-team dependencies. A small issue that could be solved in minutes inside the same office can take hours, sometimes an entire day, in distributed teams.

One team goes offline.
Another team has not started the day yet.
The person who needs to make the decision is in another timezone.

The technical problem stays the same, but the coordination cost increases.

And at some point, teams realise something important: in distributed systems, coordination is no longer a side effect of the work. It becomes the work itself.

Most Communication Problems Are Not Language Problems

Most communication issues in global teams are not actually related to English proficiency. They are usually caused by people interpreting messages through completely different operational backgrounds.

In some teams, making fast decisions is seen as professionalism. In others, moving too quickly without enough evaluation is considered risky. Similarly, direct disagreement can be interpreted as efficiency in one culture and unnecessary aggression in another.

That is why two people can leave the same meeting with completely different conclusions.

Because people do not read messages based only on the words themselves. Company culture, previous work experience, risk tolerance, and even hierarchy perception become part of communication in invisible ways.

This is where friction in global teams usually starts.

This Is Why Async Work Became So Important

I think this is also why async-first work models became more valuable in recent years. People are starting to realise that keeping everyone online at the same time is not sustainable.

In global organisations, relying too heavily on meetings eventually creates context loss. The same topics get repeated, decisions disappear inside conversations, dependencies become harder to track, and people spend most of their day trying to stay synchronised.

That is why documentation in strong distributed teams is no longer “nice to have". It becomes part of the operational system itself.

A well-written ticket, clear ownership, or a concise meeting summary can sometimes become more valuable than another meeting. Because in distributed systems, verbal knowledge does not scale.

At some point, documentation stops being a storage mechanism. It becomes operational memory.

The New Skill in Modern Tech Teams: Context Management

One of the most interesting things about global work is that technical knowledge eventually stops being enough on its own.

The ability to move between different working styles, reduce context loss, and manage asynchronous coordination becomes a real professional skill.

Because in modern tech organisations, the challenge is no longer just “getting work done".

It is being able to collaborate across different operational systems with minimal friction.

And I think this is what actually separates strong global teams from the rest.

The answer is not more meetings. It is lower communication friction.

Grounded AI in CRM: The Architecture Behind Reliable AI

Nurdan Güngör — Mon, 09 Mar 2026 11:35:14 +0000

Most discussions about AI focus on the model.

Which LLM is better?
Which embeddings are more accurate?
How large is the context window?

These questions dominate many AI conversations. But in real CRM systems, they often miss the real problem. In practice, most failures come from the architecture around the model. CRM systems are a good example of this.

The Two Data Worlds of CRM

CRM systems contain two fundamentally different types of information.

One world is structured and deterministic, governed by schemas, access controls, and workflows. This type of data drives automation and operational decisions.

Examples include:

case status
account tier
SLA level
product version

The other world consists of contextual knowledge that primarily exists as text. This information carries important business context but is rarely organised at the data-model level. Both worlds coexist in the same system, but they operate very differently.

Examples include:

knowledge articles
emails
chat transcripts
internal documentation

Why This Is Hard for AI

Large language models primarily operate on text. They are highly effective at interpreting natural language and generating responses based on written knowledge. But CRM decisions rarely depend on text alone.

For example, a knowledge article may contain the same solution for every customer. However, the correct operational response may depend on structured data such as:

account priority
SLA commitments
contract obligations

The knowledge itself does not change. But the correct decision does.
This creates a gap between how language models operate and how CRM systems actually work. Grounded AI attempts to bridge that gap.

Grounded AI in CRM

Grounded AI connects structured CRM data with unstructured knowledge. Instead of generating responses solely from text, the model receives additional operational context. This allows the system to reason over both structured data and textual knowledge. In real systems, grounding is not a single step. It is a pipeline that builds context under multiple constraints.

How Grounding Works in Practice

A simplified grounding pipeline in a CRM environment usually looks like this:

A simplified grounding pipeline in CRM systems.

Query preprocessing
The system interprets the user request and determines intent, role, and context.
Embedding generation
The query is converted into vector representations.
Hybrid retrieval
The system searches across knowledge sources using semantic search, keyword search, and metadata filters.
Access control filtering
Retrieved results are filtered according to user permissions.
Context construction
Relevant fragments and structured CRM data are assembled into the model’s prompt context.
LLM response generation
The model produces an answer based on the constructed context.
Each stage ensures the model receives information that is both relevant and authorised.

Where Grounded AI Often Fails

Grounding pipelines often look clean in diagrams and demos. In production environments, however, several architectural problems appear repeatedly.

1. Audience separation

Knowledge bases often mix:

customer-facing explanations
internal troubleshooting instructions
escalation procedures

Humans understand the difference.
Models typically do not.

Without explicit tagging in the data model, retrieval may expose internal information.

2. Access model mismatch

CRM systems enforce strict permissions.

Users do not see the same:

records
fields
internal notes

If the retrieval pipeline ignores these rules, the model may surface information that the user should never see. This is not a hallucination. It is an architectural failure.

3. Outdated indexes

Knowledge bases change constantly.

Policies change.
Products evolve.
Procedures change.

Embedding indices are usually refreshed on schedules.
When these cycles drift apart, the system may retrieve knowledge that is valid but no longer current.

4. Context collisions

A common assumption is that more context improves accuracy.
In CRM systems, this often creates the opposite effect.

Large knowledge bases contain:

multiple versions of the same solution
outdated instructions
conflicting policies

If too many fragments enter the prompt context, the model receives conflicting signals. More context can sometimes mean more noise.

Grounded AI Is an Architecture Problem

Many discussions about AI focus on model capability.

Bigger models.
Better embeddings.
Larger context windows.

But production systems reveal a different reality.

Reliable AI requires:

clean audience segmentation
access-aware retrieval
index freshness discipline
controlled context construction

CRM systems are deterministic.
LLMs are probabilistic.

Grounding acts as the interface between these two worlds.
When that interface is poorly designed, AI systems may produce answers that are technically correct but operationally risky.

What This Means for AI Architecture

Grounded AI is often described as a feature. In reality, it is a signal of architectural maturity.

In CRM environments, reliable AI is not created by larger models.It is created by systems that carefully control how knowledge, access rules, and operational data enter the model’s context.

In other words:

AI reliability is not a model problem.
It is an architecture problem.