Why Customer-Centric Coordination Breaks as You Grow

The organizational condition that emerges when complexity outpaces coordination.

Think back to when the company was smaller, and coordinating around the customer simply happened. Nobody scheduled it. The person who ran Product sat near the person who ran Support, heard the same complaints, and adjusted. A customer problem could go from noticed to fixed in a hallway conversation, because the whole company could fit in the hallway.

You didn't have a process for keeping everyone pointed at the customer. You had proximity. And proximity did the work that process does in a larger company, invisibly and for free.

Then you grew. You added functions, layers, locations, products, segments. And here's the part that's easy to miss: each of those functions probably got more capable while that happened. Product built a real roadmap process. Support built a real escalation playbook. Sales built real pipeline discipline. None of that structure went away, and none of it was wasted. What was not built alongside it was the connective tissue between those functions: the mechanism that turns four separately mature teams into one coordinated response to the same customer. The head of Support no longer sits near the head of Product. The hallway conversation now needs a meeting, an invite list, and a reason to exist. The context that used to move by default now has to cross that distance on purpose, and nobody built the mechanism to carry it across.

Here's what makes this so hard to catch in the moment. Nothing broke, in the sense of an outage or a single bad call anyone could point to. Everyone kept working. Each function kept getting better at its own part. And still, what the customer actually received depended more and more on which team happened to touch it, not because anyone stopped caring, but because the functions were maturing on separate tracks while the connection between them stayed exactly as informal as it was when the company was a tenth of the size. By the time the symptoms are obvious, there is no single moment you can point to. The condition simply emerged, gradually, alongside the growth that caused it.

Growth doesn't create coordination problems. It exposes the ones informal ways of working could no longer hide.

That coordination mechanism was never actually built the way the functions around it were. It was improvised, and improvisation has a ceiling.

Alignment Is Not the Same as Coordination

When a leadership team senses this problem, the word they almost always reach for is alignment. We need better alignment! Get everyone aligned! Align the org around the customer.

It's worth being precise here, because these two words get used as if they mean the same thing, and the difference between them is the whole problem.

Alignment is agreement. It's everyone in a room deciding that customer retention is the priority this year, nodding, and meaning it. Alignment happens in conversations, and a good leadership team can reach it in an afternoon.

Coordination is what happens after the room empties. It's the five functions who agreed on retention going back to their own teams, their own roadmaps, their own targets, and actually acting in a way that adds up. Coordination happens in execution, over months, across boundaries, under pressure, when the agreement from the meeting collides with a deadline that was set before the meeting.

You can have complete alignment and still fail entirely at coordination. Everyone agrees. Everyone goes back to their desk. And the shared priority quietly dissolves into five reasonable local interpretations, competing for the same budget and the same quarter, with no mechanism to reconcile them when they conflict. Nobody defected. Nobody stopped caring. The agreement was real. It just had no machinery underneath it.

Alignment is agreement. Coordination is execution.

It's easy to invest heavily in reaching alignment and mistake it for the harder work building coordination actually requires. Agreement about what matters is not a method for acting on it together.

The Condition Has a Name

If you recognize your own company in this, it helps to know that what you're looking at is not a flaw specific to your organization. It's a recognizable stage, distinct enough to deserve a name of its own.

I call it a Pre-Standards Organization™.

The name points at what's missing, and it's worth being precise about what that is not. A Pre-Standards Organization is not short on standards generally. Sales may run a genuinely rigorous qualification process. Product may run a disciplined roadmap cadence. Support may have a mature ticketing and escalation system. Any of those can be real and well-built, refined over years of practice inside that one function.

The condition is broader than any single missing piece. It's that the organization has grown past the point where informal coordination, proximity, tenure, and a handful of relationships, can reliably connect those mature functions around one customer outcome, and nothing deliberate has been built to take its place. Shared agreements are part of what a replacement looks like: the words everyone uses for the same customer problem, who owns which part of the experience once it crosses a boundary, how a decision gets made when it touches two teams at once. But agreements alone are not the whole of it. What's missing is the broader capability to act as one organization around the customer, not a single document or a set of definitions.

A Pre-Standards Organization has the customer data. It has capable, often genuinely mature, functions. What it does not yet have is a deliberate way of connecting those functions around a shared customer outcome, so it runs on whatever gets improvised in the moment instead. Each function's local standard is strong. The organization has simply not built the capability that turns those strong local standards into one coherent result.

This is not a diagnosis of dysfunction. It's a diagnosis of a stage. You did not skip this because you were careless. You skipped it because when you were small, proximity did this work for you, and building anything more deliberate at that size would have been overhead you were right to avoid. The problem is that the company outgrew what proximity could carry, each function kept maturing on its own, and nobody went back to build what was supposed to connect them.

What It Looks Like From the Inside

The condition stays abstract until you watch it play out around one genuinely shared priority.

Say the leadership team agrees, in the same meeting, that the company needs to reduce how long it takes a new customer to reach real value. Everyone nods. Nobody disagrees. It's the kind of priority that sounds unambiguous from the front of the room.

Then it goes back to four functions, and each one does something reasonable with it.

Marketing hears "faster time to value" and tightens the message: simpler positioning, a lower-friction signup, more qualified self-serve trials. A sound marketing decision.

Sales hears the same priority and leans into it competitively, promising fast setup to close larger deals against slower competitors. A sound sales decision, and the kind that wins a quarter.

Product hears the same priority and interprets "time to value" as time to the capability that actually differentiates the product: the configuration and control its most successful customers rely on to get real value out of it. So Product ships a more direct path into that deeper functionality, on the reasoning that getting customers to real value means getting them to the powerful part faster, not just through a simpler signup. Also a sound decision, tested against the customers already expanding fastest.

Support and Customer Success are the ones who feel what happens next. New customers arrive expecting the fast, simple setup Sales described, into a product that just became more configurable and, for a first-time user, more complex. Time to value gets worse for exactly the segment the whole effort was meant to help.

None of the four decisions was wrong on its own. Marketing did its job well. Sales did its job well. Product did its job well, and arguably made the more important call for the business over the long run. The priority was never abandoned. It was interpreted four separate times, by four capable functions, each acting on information the other three could not see, and none of the four interpretations was reconciled with the others before it reached the customer. It is not that no one spoke for the customer in this sequence. Four different people did, fluently, each in their own function's language, and none of the four ever heard how the other three had translated the same priority.

A shared priority can produce four reasonable decisions and one incoherent result, and nobody along the way did anything you'd call wrong.

That's the shape worth learning to recognize. It does not look like a mistake from inside any single function. It only looks like a mistake from where the customer is standing, watching all four decisions arrive at once.

This Is a Stage, Not a Verdict

The reason any of this matters is that a Pre-Standards Organization is not a permanent condition. It's a phase, and companies build their way out of it on purpose.

The way out is not to grow less, care more, or hire a better version of the people you already have. What has to change is deliberate: replacing the informal coordination that used to work for free with something built on purpose, sized to the organization you actually have now rather than the one you started as. That's real work, the kind no single function can do on its own, and it does not happen by asking each function to try harder. But it is buildable, which is the point. You're not fighting human nature or organizational gravity. You're building something that was never there, because for a long time it never had to be.

Organizations don't outgrow customer-centricity. They outgrow informal coordination.

If this is the stage you recognize, the more useful move is not to start listing which standards to install. It's a harder question aimed at your own organization: where, specifically, are you still relying on proximity, tenure, or a handful of well-placed relationships to coordinate work that has outgrown all three? Look at how decisions actually get made today when they cross a function boundary. Notice how much of what still works depends on a small number of people who happen to know each other well, have been there since the company was smaller, or are simply willing to chase down something that is not technically theirs.

You may still be coordinating an organization of this size on assumptions and relationships that belonged to an earlier version of the company.

© 2026 Groundwork CX. All rights reserved. groundworkcx.com