How to Build a Gyrator Team

Everything so far has been about understanding. This page is about doing.

You have a challenge. Something that lives between departments, between levels, between the way things are and the way they need to be. No single team owns it. No existing process solves it. The current structure can’t turn resources into a solution at the rate you need.

How do you build a team that can?

Start with the baseline

Before you define the goal, you need to define the perspective.

In Malyuta’s theory, every observation happens from a position — a basis point. The same system looks fundamentally different depending on where you stand. Distances change. Priorities change. What’s visible changes. What’s invisible changes.

This isn’t a theoretical abstraction. It’s what happens every day in companies.

A customer support bottleneck looks like a staffing problem from the support department’s perspective. From the product team, it looks like a UX failure. From the CEO, it’s a retention risk. From the customer, it’s simply broken.

Same reality. Four different baselines. Four different goals would emerge if each perspective defined the challenge alone.

This is why most cross-functional initiatives fail before they start. Someone — usually a senior leader — defines the problem from their baseline and assembles a team to solve that version of it. The team contains people from different departments, but they’re all optimizing for a goal that was framed from a single point of view. The other perspectives were never consulted. The challenge was never seen in its full dimensionality.

A gyrator team does something different. It starts by composing the baseline.

Composing the baseline

Bring three to six people who see the challenge from genuinely different positions. Not different functions only — different levels, different proximities to the problem, different relationships to the outcome.

The person who feels the pain daily. The person who sees the systemic cause. The person who controls the resources. The person who understands the constraints. The person who will use the solution.

Sit them together. Not to brainstorm solutions — that comes later. First, let each person describe what they see from their position. What the challenge looks like from where they stand. What’s broken. What’s missing. What they know that others in the room probably don’t.

This is uncomfortable. People from different organizational levels are not used to sharing a perspective space as equals. A developer describing a systemic issue to a C-level executive feels like overstepping. An executive admitting they don’t understand the technical constraint feels like vulnerability.

This discomfort is the signal that the process is working. The perspectives are genuinely different. If everyone agrees immediately, you haven’t composed a baseline — you’ve just gathered people who see the same thing from the same angle.

When the different perspectives are heard, something emerges that wasn’t available before: a composed view of the challenge. Not a compromise between viewpoints — a multi-dimensional picture that each individual baseline could only partially see. The goal that comes from this composed view will be richer, more accurate, and more actionable than anything a single perspective could produce.

Defining the goal

The goal should be concrete, time-bound, and stated in terms of the delta between the current state (as seen from the composed baseline) and the desired state.

Not “improve cross-departmental collaboration” — that’s a direction, not a goal.

More like: “Reduce the cycle from customer request to delivered integration from six weeks to two weeks within three months.” Or: “Build a working prototype of the sales-production data bridge by end of quarter, tested with real users from both departments.”

The specificity matters because it shapes everything that follows. It determines which spectrums the team needs (who has the qualities required to close this specific gap). It determines how to evaluate progress (did we move from baseline toward the goal, and by how much). And it gives every member of the group a shared reference point for peer evaluation — not “did you work hard?” but “did you contribute to closing this specific gap?”

Selecting by spectrum, not by title

Once the baseline is composed and the goal is defined, you can see which qualities the team needs. Not which departments — which qualities.

Maybe you need someone who understands the data architecture. Someone who knows how the end users actually work (not how the documentation says they work). Someone who can make decisions about resource allocation without escalating to a committee. Someone who translates between technical and business language.

These are spectrum requirements, not job title requirements. The person who understands the data architecture might be a junior developer who built the original integration. The person who knows end-user reality might be a support agent, not a product manager. The decision-maker might be someone two levels below the executive who normally “owns” that domain — but who, within this group, has the mandate to act.

This is where the hierarchy flattening happens naturally. You’re not selecting people by rank. You’re selecting them by the quality they bring to this specific challenge. Inside the group, the developer’s technical depth and the executive’s strategic vision have equal weight — because both are necessary parts of the spectrum that produces the solution.

How the group operates

A gyrator team is temporary by design. It exists to solve a specific challenge. When the challenge is resolved — or when it becomes clear that the challenge has transformed into something different — the group dissolves or restructures.

During its life, the group needs:

A clear mandate. Everyone in the group — and their managers — must understand that participation is legitimate, resourced, and expected. This isn’t a side project. This is a recognized structure with a defined purpose.

Regular rhythm. Not daily standups (unless the challenge demands it). But a consistent cadence — weekly or biweekly — where the group checks progress against the goal, surfaces blockers, and adjusts.

Peer evaluation. Periodically, each member evaluates every other member’s contribution. Not numerically — through the simple questions described on page 6. This keeps the group honest and makes the invisible visible.

A lifecycle awareness. The group monitors its own state. Is it still turning resources into value? Is the challenge evolving? Has the spectrum changed — do we need different qualities now than we did at the start? Is the group approaching saturation — have we done everything this configuration can do?

When a group reaches its goal, celebrate and dissolve. When it reaches saturation without reaching the goal, restructure — change the composition, redefine the baseline, or acknowledge that the challenge is bigger than this group can handle and escalate it.

What others have discovered

This pattern — small, cross-functional, purpose-built teams with clear goals and high autonomy — has been reinvented independently by companies around the world.

Haier, the Chinese manufacturer, dismantled its entire hierarchy and replaced it with four thousand micro-enterprises of ten to fifteen people, each with its own P&L. They eliminated twelve thousand middle managers. The result: sustained double-digit growth for over a decade.

ING Netherlands put thirty-five hundred people “on mobility” — effectively without a job — and asked them to reapply for positions in cross-functional squads organized around customer journeys. Product development cycles dropped from eighteen months to three.

W.L. Gore, the materials company, has operated for decades without job titles or chains of command. Teams self-organize. Compensation is determined by peer evaluation.

None of them copied each other. None of them used the same language or the same theory. But all of them arrived at the same structural insight: teams turn resources into value far more effectively when you move from siloed departments to cross-functional groups with clear goals, complementary spectrums, and internal accountability.

The gyrator framework gives this insight a formal foundation — a theory that explains why it works, not just that it works. And a measurement approach that lets you see it in action, not just hope for it.