The chair: Why organizations build the wrong thing

Every organization has a translation problem.

Engineers understand what can be built. Clients understand what they need. Between those two realities sits a gap many teams never close — not because they lack talent, but because no one in the room has the authority, vocabulary and judgment to name the solution.

I encountered this framework because my youngest daughter — a college freshman studying data science and computer science with a business minor — was struggling with a version of the same problem.

She had the raw materials: robotics, aerospace engineering, Mandarin, AI training and leadership experience. What she lacked was a way to see how those pieces connected.

A leader I respect runs a large engineering firm. His clients are major companies, his projects are complex, and his hiring needs are specific.

When I asked him what role he struggles most to fill, he answered immediately.

"We have plenty of technologists," he said. "What we struggle to find is someone who can sit in the room with a client, listen carefully, have a real conversation, understand what they need, and then go back to our engineering team and say: this is what we need to build."

Then he simplified it.

"We need someone who sits between the client and the engineers and says: we need this chair, right here."

That line carries more organizational truth than most strategy decks contain.

Before that conversation, my daughter — now a college freshman majoring in data and computer science with a minor in business — had been evaluating her future through the standard filters: majors, credentials and job titles.

The engineering leader's framing changed the question entirely. The focus moved from selecting a role to identifying problems worth defining and solving.

The framing replaced pressure with coherence.

Her résumé, which had seemed scattered on the surface, suddenly made sense. Robotics, engineering, Mandarin, AI training and leadership experience all pointed toward the same capability: moving between disciplines and translating across them.

She did not need a detailed career plan. She needed a permission structure — a way of seeing that her range was the qualification rather than a liability.

Consider how the failure typically works inside organizations.

A client describes a problem — an inefficient process, a confusing product experience or a data system that produces reports nobody trusts. The engineering team possesses deep technical skill. The client understands the business environment. Each group approaches the problem from its own vantage point.

Someone must translate between those worlds. Without that translation layer, teams build technically sound systems that fail to solve the underlying problem.

This is not a strategy failure; it is a clarity failure.

In high-stakes environments, clarity failures are a primary source of decision risk.

The critical role belongs to the person who can hold both realities simultaneously — the technical possibilities and the operational need — and make a clear call about what should be built.

Build this.

Right here.

A single clear solution.

In the technology industry, that role often carries the title product manager. The title understates the responsibility. The role involves diagnosis, interpretation and alignment — the same capabilities that define effective governance in any institution.

That person names the chair.

This pattern — the absence of a clear translation layer — shows up far beyond engineering firms.

Municipal governments approve initiatives without clearly defining the problem they intend to solve. Nonprofits build programs around grant requirements rather than constituent needs. Corporations launch products that satisfy internal stakeholders while confusing the market.

In each case the organization possesses the talent to execute. What it lacks is the person — or the permission structure — to say plainly: this is the problem, and this is what we build to solve it.

When that clarity is missing, organizations default to building what is familiar rather than what is needed.

Talented teams execute well on the wrong thing.

Leaders can test for this problem quickly.

When a complex issue surfaces, ask a simple question:

Who in the room is responsible for defining what gets built?

Not who approves the budget. Not who manages the timeline.

Who translates the need into a clear, buildable direction?

If the answer is unclear — or if that responsibility gets distributed so broadly that no one actually owns it — the organization has a translation gap.

Translation gaps create clarity failures. Teams move forward confidently, resources get committed, and the result still misses the mark because the original problem was never named precisely.

The remedy rarely requires more talent.

It requires someone willing to name the chair.