Problems at the Boundary

I’ve been thinking about a particular type of disagreement that happens when people or teams with different expertise work together.

Inside our own area, we have a reasonably good idea of what to ask. An engineer knows which technical questions are suspicious. Someone working with customers knows which comments in a meeting might matter. A security expert notices risks that other people probably don’t even see.

The interesting problems happen at the boundary.

A decision is partially technical and partially commercial. A customer request affects architecture. An implementation decision changes what can be promised later.

Then something strange can happen.

Two people can both be competent, both have relevant information, communicate regularly, and still miss something that looks completely obvious afterward.

I’ve started noticing several versions of this problem.

1. What is obvious depends on where you are standing

Imagine two specialists working on the same problem.

Person A knows:

Person B knows:

And together:

The difficulty is that neither necessarily knows that the other person’s information is relevant.

After the problem appears, the missing conversation looks obvious.

A might say:

Why didn’t you tell me about Y?

B might respond:

Why didn’t you tell me about X?

Both can be reasonable questions.

The uncomfortable part is that before the problem appeared, neither person necessarily knew what they needed to ask.

This is different from someone withholding information or failing to communicate something they knew was important. It also means the usual solution — “communicate more” — doesn’t completely solve it.

You can ask:

Is there anything you need from me?

and get an honest:

No.

The problem is not always the answer.

Sometimes the missing piece is the question.

And after the fact, each side can find the other’s failure almost incomprehensible because the missing fact was obvious from inside their own world.

That is one kind of problem at the boundary.

But there is another version. Even when two people are looking at exactly the same thing, expertise can make them see different problems.

2. Expertise changes what looks like the same problem

Consider something outside work.

Someone without children might suggest:

Why don’t you just stay another hour?

From the outside, one hour is one hour.

The difference between leaving at 7:00 and leaving at 8:00 may seem almost irrelevant.

A parent of a young child may see a completely different problem.

7:00 might mean getting home before the child is exhausted, having enough time for the normal bedtime routine, and ending the day relatively peacefully.

8:00 might mean the child falls asleep in the car, wakes up when carried inside, refuses to go back to sleep, and turns one extra hour at dinner into a night of chaos.

To the person making the suggestion:

To the parent:

Neither person is necessarily being unreasonable.

One person sees an additional hour.

The other sees everything that hour interacts with.

That knowledge is rarely written down anywhere. Parents accumulate it by repeatedly seeing what happens when routines, sleep, hunger, transitions, and timing interact.

After enough experience, some apparently small changes become associated with much larger consequences.

They become obvious.

And because they are obvious, it can be surprisingly difficult to remember that they are not obvious to everyone else.

The same thing happens in professional expertise. After seeing enough failures, dependencies, and edge cases, some differences become immediately meaningful.

The danger is forgetting that the meaning came from experience, not from the object itself.

An engineer may decompose a problem into different structures, validation requirements, evidence requirements, and failure modes.

Someone closer to the customer may simply see different instances of the same problem.

Both views can be useful.

If we are estimating engineering effort, the differences matter enormously.

If we are understanding the customer’s problem, treating every instance as an unrelated technical system may cause us to miss the common workflow they are actually trying to solve.

Expertise doesn’t only give us more knowledge.

It changes which differences we consider important.

One person sees four instances of the same thing. Another sees four different problems.

And both representations can be useful.

The question is: useful for what?

3. Expertise changes the apparent size of a problem

The same thing happens with apparently small changes.

Someone asks:

Can we add one field?

From the outside, the change is one field.

And again, that isn’t an unreasonable description.

But inside the implementation, that field might touch:

This creates a familiar conversation:

It’s just one field.

versus:

It’s not just one field.

I increasingly think both statements can be true.

At the product interface, it may literally be one field.

Inside the system, it may create additional dependencies.

The mistake is assuming that because something is small in one representation, it must also be small in another.

And the reverse happens too.

Engineers can spend considerable effort on an architectural improvement that is genuinely sophisticated and difficult, while from the user’s perspective almost nothing has changed.

Technical complexity does not automatically create equivalent product value.

So expertise affects more than what looks different.

It can also affect what looks large.

In 2025, Cloudflare made a change to permissions in one of its database systems. The change altered the results of a metadata query elsewhere in the system, which changed a configuration file used for bot detection. That file was automatically distributed across Cloudflare’s network, where it exceeded a limit in the software processing web traffic and contributed to a major outage.

At the point where the change was made, it was a database permissions change.

At the level of the system, it changed an assumption several layers away.

The size of a change is not determined only by what was changed.

It also depends on everything downstream that assumed the old behaviour would remain true.

The boundary is the interesting part

I used to think about some of these situations mostly as communication problems.

Someone needs to explain the technical issue more clearly.

Someone needs to provide better business context.

Both are useful.

But I think there is something deeper happening.

Specialization doesn’t simply mean that two people know different facts.

It means they have spent years learning:

• which differences matter;
• which things can safely be treated as equivalent;
• which questions are worth asking;
• which consequences are likely to appear later; and
• which apparently small details are signals of a much larger problem.

That knowledge changes perception.

This is why an expert can look at something and immediately say:

Those are not the same thing.

while someone from another field looks at exactly the same objects and asks:

Why aren’t they?

Neither perspective necessarily contains the entire problem.

4. How do we address these problems?

I later found some useful research on knowledge boundaries.

Paul Carlile describes specialized knowledge as becoming localized around the problems that different groups repeatedly solve. That specialization is valuable, but when groups depend on each other it can also create boundaries: what is obvious, relevant, or consequential in one function may not be obvious in another.

Another related idea is interactional expertise, from Harry Collins and colleagues. Roughly, it means becoming fluent enough in another specialist’s language to interact intelligently with people in that field without becoming capable of doing their job yourself.

That distinction matters.

The solution cannot be:

The whole reason specialization exists is that this is impossible and inefficient.

The more realistic goal is something like:

That second part is harder than it sounds.

It means learning enough to occasionally think:

There may be something here that I don’t see.

Or:

This looks simple to me, but is it simple from your side?

Or:

These look completely different to me. Is there a reason they look like the same problem to you?

Those are much better questions than trying to guess the answer from the other person’s domain.

And once the boundary is visible, we can do something with it.

We can draw the architecture. Map the workflow. Compare the documents. Write down assumptions. Build a prototype.

These things are useful not simply because they contain information.

They are useful when they expose differences and dependencies that were previously visible to only one side.

So perhaps the useful question for a cross-functional artifact is:

Does this expose the differences and dependencies that matter to the decision?

That may be the part I want to keep from all of this.

The goal of cross-functional work isn’t to eliminate different perspectives. Those perspectives exist because specialization is useful.

The goal is to get better at recognizing when a problem sits between them.

Sometimes the other person knows something I don’t.

Sometimes I know something they don’t.

And sometimes the real problem is neither of those things.

It is that neither of us realizes yet that the two things need to be connected.