Assembling the Reactor

Everything so far has been about understanding. This chapter 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 person who decides about resources might not be a department head at all — it could be someone lower in rank whom the group has given a mandate to act without additional escalation.

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.

At this point the group is assembled. It has a baseline, a goal, and a spectrum. But this is not yet a gyrator — it’s only the potential of one. How the group lives day to day, how it reads itself, how it makes decisions — that’s the next two chapters. Here I’ll close with what others have already rediscovered.

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.