Point of View

The Six-Person Brain and the Seventy-Person Interface

Here is a structure worth sitting with. Inside a large industrial manufacturer, one core engineering product depends on three separate organizations, and only one of them is the company itself.

The actual calculation engine, the logic that determines whether an anchor, bolt, or fastener will hold under real-world structural load, is owned by a specialist vendor with six people on it, organized as a single team. The website and the various structural connection design modules that structural engineers and specifiers at boutique consulting firms actually click through are owned by a second, much larger vendor: seventy people, spread across six teams. And the company's own internal organization for this product, the group that presumably owns the thing, comes in at twenty-five people across three teams, sitting in the middle of both vendor relationships, controlling only a single module themselves, one that had also originally been built by a vendor and handed over.

Six people own the brain. Seventy people own the interface. Twenty-five people, on the inside, make up nearly a quarter of the total headcount touching this product, and yet, counted by what they actually built and control rather than by who's on the payroll, they own something closer to five percent of the total portfolio.

That gap, a quarter of the people, five percent of the ownership, is not a staffing anomaly. It is the visible symptom of a much larger disease, and once you see it in one place, you start noticing it everywhere in the organization.

How You End Up With a Structure Like This

No one designs an organization to look like this on purpose. It accumulates, one reasonable-sounding vendor decision at a time, over fifteen or twenty years.

This particular company is a real industry leader, old-school in the best sense: a direct-to-consumer, engineering-first business that makes the fasteners and anchoring systems that hold up construction sites and heavy engineering projects, and also provides installation and other professional services around them. The core business is sound. The technology underneath it tells a messier story. Every business unit has built its own vendor footprint independently, with no enterprise-wide or even business-unit-wide strategy governing how those relationships should evolve over time. For this particular business unit and this particular product, that history left behind two vendors instead of one: a small specialist who was never going to be displaced, because the specialized engineering knowledge inside that calculation logic represents decades of domain expertise nobody internally has built, and a much larger vendor who was brought in to build and maintain the customer-facing layer, because that work looked, at the time, like something worth handing off rather than owning.

The result is a company that outsourced both ends of the problem. It outsourced the hard, defensible part, the actual engineering logic, to a team of six. Whether it's wise to put a core piece of your business model in the hands of a company that small is a separate discussion entirely, one that belongs in careful vendor assessment and selection, ideally with a buy-out option built in from the start. The company also outsourced the highly visible, customer-facing part, the interface itself, to a team of seventy. What's left internally is twenty-five people whose real job is mostly coordination between the two.

So you end up with an internal org chart that looks like ownership on paper: twenty-five people, three teams, a name attached to the product. But that internal group is structurally incapable of ever absorbing either vendor's role, because it was never built toward doing either. It exists to keep two external relationships functioning, not to reduce dependency on them.

The Tech Debt Program That Treats the Wrong Patient

This same organization has, sensibly, recognized it has a technical debt problem. An aging legacy technology stack and toolchain, a level of bloat that has accumulated across years of incremental feature requests, and enough accumulated risk that leadership approved a two-year modernization program to address it.

Here is the uncomfortable question nobody has fully answered yet: modernize toward what? Tweaking the customer-facing applications without any meaningful business outcome attached, while the actual intellectual property, the thing that makes the product defensible, still lives entirely inside a six-person vendor team's calculation engine, and while the customer-facing experience still lives entirely inside a seventy-person vendor's codebase, is modernizing the one layer that matters least. It is investing serious capital into the sliver of the system the company actually owns, while the two ends that define the product's value and its user experience remain exactly as externally owned as they were a decade ago.

This is not a criticism of the modernization program's intent. Reducing technical debt in an aging stack is legitimate work. But calling it modernization, in the sense of making the organization more resilient or more independent, overstates what it actually accomplishes. It is closer to renovating the hallway between two rooms the company doesn't hold the keys to.

Why the Roles Keep Multiplying

There's a second pattern worth naming, because it compounds the first. Roles in this organization keep getting added, a handful more every year, without any of the older roles being redefined or retired. Nobody can conduct a genuinely effective hiring interview for these positions, because nobody can cleanly articulate what the role is actually responsible for versus what three adjacent roles are also nominally responsible for. Hiring decisions, including offshore hiring, have in practice been driven by cost arbitrage rather than a deliberate strategy to build a genuine captive talent center. The intent was never to build real capability offshore. The intent was to reduce the hourly rate.

By one internal estimate, unclear role definition and overlapping responsibilities alone drive something like 40 percent of the organization's operational friction. Not legacy code. Not vendor contracts. Just: nobody can say cleanly who is supposed to decide what, so more people get added instead of the actual decision-rights problem getting solved. Add in two vendor relationships that each hold their own leverage, a top technology leadership layer that is largely non-technical and somewhat disconnected from the engineering reality underneath them, and teams distributed across geographies with their own political dynamics, and you get an organization where the friction is not really about any single legacy system. It's structural, and it's compounding.

What This Pattern Is Actually Telling You

Score this on the same lens I've used elsewhere: political friction here is severe, driven by two entrenched vendors and internal groups each defending their piece of the arrangement. Mechanical friction is equally severe, the accumulated legacy technical debt sitting in the small sliver of the system the company actually owns, layered on top of total dependency on both vendors for the rest. Structural friction is present but somewhat lower than the other two, mostly because the org chart, on paper, looks orderly even though the actual decision rights underneath it are split three ways.

The lesson generalizes well beyond this one company. When an organization's internal headcount for a product exists mainly to coordinate between vendors rather than to build or own core capability, that is not a staffing problem. It is a sign that modernization investment is being directed at the parts of the technology estate that are visible and politically easy to fund, rather than the parts that actually determine whether the company controls its own core intellectual property or its own customer experience.