Two teams solving the same problem separately

Somebody on your team spends three weeks building something. Near the end, in a meeting about something else, a person from another team says they built a version of it last year.

The phrase people use is almost always the same. I didn't know you were also working on that. It is the cheapest failure in this whole series to prevent and the most expensive to discover late.

This is the last of four cross-team failure modes. The argument they hang on is here.

Blame the conventions before you blame the systems

The first explanation everyone reaches for is tooling. Their team lives in a different system, so of course nothing crosses.

Sometimes that is true. More often the two teams have compatible tools and incompatible habits, and a tooling project is about to be commissioned to solve a problem that a half-day conversation would fix. Check which one you have before anybody writes a business case.

Find the real confusion point. Sit down with your counterparts and compare how each team actually uses the systems you share. Where do they put decisions? Where do they put drafts? What does "done" look like in their workflow? Agreeing one convention is faster, cheaper, and more likely to survive than migrating anybody.

Standardize where you genuinely can. One set of tools for project work, communication and documents. Fewer places to look beats better tooling, every time.

Connect what you cannot standardize. Where each team has to keep its own system for reasons that are real, integrate them rather than asking people to check both. Any process that depends on a human remembering to look in two places will fail at the worst moment.

When the process itself is missing

The second version has nothing to do with tools. Both teams do the same kind of work in different ways, and the difference is invisible until the outputs have to meet.

Write down what good looks like. Document the workflows that work and share them across both teams. What you want is a description of how the thing is actually done by the people who do it well, which is a different document from a policy.

Review how the work actually runs, together. Hold one session on the shared process, find the duplication, and adopt one version where it helps. Note the qualifier. Forcing a single process on two teams whose contexts genuinely differ creates compliance theater and a quiet second process that nobody documents.

Agree how data moves between you. Define how shared data is collected, stored and passed. This is dull and it prevents the specific argument where two teams read the same number differently and each believes the other is wrong.

Set one standard for quality and access. Consistent definitions are what stop that argument from recurring every quarter with new participants.

When nobody knows who to ask

The third version is the one people mention most in conversation and complain about least formally, because it feels like a personal failing rather than an organizational one. It is not. In a large organization nobody can hold the map in their head.

Build a directory, and accept that it decays. Names, areas of expertise, and what each person actually owns. It will be out of date within a quarter unless somebody owns keeping it current, so decide who that is before you build it or do not build it.

Pair people across the boundary. Give each person on your team a named counterpart on the other side. A named human does not decay the way a directory does. Pairing returns far more than the directory, by a wide margin.

Invite the other team to your town hall. Have them describe their remit and their expertise in their own words rather than through your summary of it.

Swap roles for a while. Formal or informal. Time spent inside the other team builds the network and the awareness that no document can. Nothing else on this page changes what people know rather than where they can look it up.

How you know it worked

The duplication test is the clean one, and it takes a quarter to run. Count the number of times somebody discovers work that was already being done elsewhere. If that number does not fall, the directory is stale or nobody is using the pairing.

The faster proxy: pick a specialist question your team needed answered last month and ask whoever needed it how long it took to find the right person. Ask again in thirty days.

The exercise

Ask three people on your team to name the person they would go to on the other team for help, and what they would go to them for.

You are looking for two things. Whether the three answers name the same person, which tells you whether you have a single point of failure. And whether anyone hesitates, which tells you the map does not exist outside your own head.

Both answers are useful, and neither requires anyone's permission to find out.