The Problem No One Talks About

Let me tell you what I see.

I work inside a fast-growing company. Multiple departments, clear roles, an org chart that makes sense on paper. Everyone has a function.

And yet.

When a team I’m on needs something from another department — a data clarification, system access, a decision that crosses departmental lines — something interesting happens. Sometimes we get an instant, generous response. Someone says: “Let me check. I’ll get back to you in an hour.” They help not because the request was perfectly formatted, but because they understand that helping us helps the company.

Other times, we get this: “Where were you three weeks ago? We can’t just drop everything. Please describe precisely what you need in a formal request.”

Same company. Same tools. Same Slack. Completely different responses.

It’s tempting to call the first response healthy and the second broken. That’s what I thought at first. The person who helps quickly is “a good colleague.” The person who asks for a formal request is “a bureaucrat protecting their turf.”

But the longer I looked, the more I realized I had it backwards.

The helpful response is the one that breaks the rules.

Here’s why. A department is not a loose collection of people who happen to share a Slack channel. It’s a system — with its own goals, its own priorities, its own internal state, its own picture of what’s urgent this week. Another department, next to it on the org chart, is a different system, with a different internal state. These two systems sit at the same hierarchical level and run in parallel. Neither is inside the other, and neither controls the other.

There’s a rule about how two systems at the same hierarchical level are supposed to communicate. It’s not a rule anyone wrote down in a company policy, but it’s as real as gravity: two separate systems don’t communicate element-to-element. They communicate through the level that contains them both.

In a company, that level has a name — it’s wherever the two systems actually meet. If the systems are two teams inside one department, the meeting level is the department lead together with the team leads. If they’re two departments, it’s the management environment that spans both — the heads of those departments and whoever routinely coordinates between them. The request has to travel up one system, meet at the level that sees both systems at once, and travel back down the other. That’s not bureaucracy. That’s the only path that gives you both the context and the authority to say yes, this is worth doing, worth interrupting the other team for, and the priorities on both sides can absorb it.

Now look at what the “helpful” response actually did. An engineer in Department A messaged an engineer in Department B, and the second engineer said “let me check, I’ll get back to you in an hour.” The help was real. The work got done. But the two systems just connected element-to-element, bypassing the level that should have mediated them. Department A’s lead doesn’t know the team is now effectively borrowing capacity from Department B. Department B’s lead doesn’t know her engineer just took on work that isn’t in her plan. Two systems are now interacting in a way nobody above them can see or account for.

Do this once, and nothing breaks. Do it as the default way cross-system work gets done, and every plan in the company starts describing work that isn’t actually happening — while the real work happens in a shadow network of informal agreements. Leads lose sight of load. Prioritization becomes fiction. And when the engineer who was quietly helping everyone burns out or quits, nobody can explain what’s suddenly slower, because the load was never formalized anywhere.

Now look at the “bureaucratic” response again. “Please describe precisely what you need in a formal request.” What that person is actually saying — whether they could articulate it or not — is: this request has to go through the level where our two systems meet. That’s the only place it can be weighed honestly against everything else my system is committed to. They are defending system-to-system communication on behalf of the whole company, not just their own attention. In systems terms, they are correct.

And yet — here’s where it gets uncomfortable — the first response is the one we want. The intent was right. Value was created. A problem got solved. Nobody sat in a queue for a week waiting for a cross-departmental ticket to travel up and back down the org chart.

So now the real question is the one this whole site is about:

Is there a way to preserve that intent — direct, fast, cross-system value flow — while still respecting the law that says separate systems have to communicate through the level that contains them?

Can we let engineers solve problems directly without the structures losing sight of what is actually happening?

The answer is yes. It requires a specific kind of team — one the org chart doesn’t have a name for yet, one that is constituted at the level where the systems meet, so that the interactions inside it are legitimate by design. That’s what the next pages are about.

(There’s a second, related problem — how information moves vertically, between a senior and a junior in different parts of the company. That one has the same root cause and the same kind of answer. We’ll get to it in Chapter 7, once we’re sharing the same vocabulary.)

Before we move on, two more things are worth noticing about what happens in a company where every cross-system request is forced through formal channels — because that’s the other failure mode, and it’s just as expensive.

The invisible people

There’s another thing I notice. In every cross-functional effort I’ve been part of, there are people who are visible — who drive things, respond fast, connect others — and people who are invisible. Not absent. Not unproductive in their own domain. Just… not present in the value flow between teams.

I used to think this was about skill or motivation. Some people are naturally collaborative; others prefer to keep their heads down.

But then I started looking more carefully, and I realized: the invisible people aren’t invisible because of who they are. They’re invisible because the structure doesn’t give them a place to show up. Nobody asked them. Nobody connected their skills to the problem. Nobody showed them that their particular quality — maybe it’s deep domain knowledge, or a specific technical skill, or even just the ability to translate between engineering and business language — was exactly what the group needed. The usual name for this in English is “throwing a person at the problem” — plugging a hole with a body, without ever asking what quality the hole actually needs.

The connector problem

The people who make cross-functional work happen — the ones who bridge departments, who translate between teams, who respond fast and connect others — are incredibly valuable. And almost nobody knows who they are.

They don’t show up on the org chart. Their contribution isn’t captured in any performance review. Their manager might not even know they’re doing it. They’re holding the organization together through informal networks that nobody designed and nobody measures.

When one of these connectors leaves, everyone feels it. But nobody can explain exactly what was lost, because it was never named.

What this costs

I don’t have a number for what structural friction costs. I don’t have a methodology for measuring it either. Nobody does — that’s part of the problem. But I can see it in cycle times. I can see it in duplicated work. I can see it when two teams build similar solutions because they didn’t know the other existed. I can see it when a good idea dies because it landed in the wrong department and nobody carried it across.

The larger a company grows, the worse this gets. More departments means more borders. More borders means more friction. More friction means less value comes out for every unit of resource going in.

This is the problem that no single department can solve, because it lives between departments. It’s not an HR problem. It’s not an IT problem. It’s not a management problem. It’s a structural problem.

And it has a solution. Not “tear down the hierarchy and let everyone talk to everyone” — that’s the first response at scale, and it ends in chaos. Not “add more process” either — that’s the second response at scale, and it ends in paralysis.

Some companies already feel this problem and are looking for solutions. They flatten their hierarchies. They copy something that worked somewhere else. But these are tactical reactions without understanding — cargo cult. Copying the shape of what worked, without understanding why it worked.

The real solution is a different kind of team: one that sits between levels by design, so that fast cross-system help is no longer a violation of the rules but a manifestation of them.

That team has a name. The next page is about where I found it.